Subject: RE: [AAA-WG]: [Issue 330]: Diameter should not require separate TLS port

From: <[email-masked]>
Date: Tue, 16 Apr 2002 10:47:05 +0300

Hi David,

Thanks for the changes, comments in-line:

> Section 2.1
>   Remove the sentence:
>    When used with TLS [TLS], the Diameter protocol is run on port TBD of
>    both TCP and SCTP.

Agreed.

> Section 4.4, DiameterURI
> 
>    Since TLS is negotiated, I don't think any references to aaas make sense any more,
>    so, remove the following lines:
> 
>          "aaas://" fqdn [ port ] [ transport ] [ protocol ]
> 	. . .
>          aaas://host.abc.com;transport=tcp
>          aaas://host.abc.com;protocol=diameter

Agreed.

> Section 5.2, item 3 & 3.x

I agree with most of your changes, but I've kept section 3.2, but edited it
to be:

  3.2 A client MUST discard any service fields that identify a resolution 
      service whose value is not "D2X", for values of X that indicate transport 
      protocols supported by the client. The NAPTR processing as described in 
      RFC 2915 will result in discovery of the most preferred transport protocol 
      of the server that is supported by the client, as well as an SRV record for the 
      server. 

      The domain suffixes in the NAPTR replacement field SHOULD match the domain 
      of the original query. It is not necessary for the domain suffixes in the 
      NAPTR replacement field to match the domain of the original query.

> Section 5.3
> 
>    [from first paragraph]
>    state machine (see section 5.6). This message allows the discovery of
>    a peer's identity and its capabilities (protocol version number,
>    supported Diameter applications, security model, etc.)
                                      ^^^^^^^^^^^^^^
The avove is new only new text, correct?

>    A receiver of a Capabilities-Exchange-Req (CER) message  that does not
>    have any applications in common with the sender MUST return a
>    Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to
>    DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport
>    layer connection. Note that receiving a CER or CEA from a peer
>    advertising itself as a Relay (see section 2.4) MUST be interpreted
>    as having common applications with the peer.
> 
> ***   Similarly, a receiver of a Capabilities-Exchange-Req (CER) message
>    that does not have any security model in common with the  sender MUST
>    return a Capabilities-Exchange-Answer (CEA) with the Result-Code AVP
>    set to DIAMETER_NO_COMMON_SECURITY, and SHOULD disconnect the transport
>    layer connection.

I agree with this.

> Section 5.3.1 Capabilities-Exchange-Request
> 
>      <CER> ::= < Diameter Header: 257, REQ >
>                 { Origin-Host }
>                 { Origin-Realm }
>              1* { Host-IP-Address }
>                 { Vendor-Id }
>                 { Product-Name }
>                 [ Origin-State-Id ]
>               * [ Supported-Vendor-Id ]
>               * [ Auth-Application-Id ]
> *****         * [ Inband-Security-Id ]
>               * [ Acct-Application-Id ]
>               * [ Vendor-Specific-Application-Id ]
>                 [ Firmware-Revision ]
>               * [ AVP ]
> 
> Section 5.3.2 Capabilities-Exchange-Answer
> 
>       <CEA> ::= < Diameter Header: 257 >
>                 { Result-Code }
>                 { Origin-Host }
>                 { Origin-Realm }
>              1* { Host-IP-Address }
>                 { Vendor-Id }
>                 { Product-Name }
>                 [ Origin-State-Id ]
>                 [ Error-Message ]
>               * [ Failed-AVP ]
>               * [ Supported-Vendor-Id ]
>               * [ Auth-Application-Id ]
> *****         * [ Inband-Security-Id ]
>               * [ Acct-Application-Id ]
>               * [ Vendor-Specific-Application-Id ]
>                 [ Firmware-Revision ]
>               * [ AVP ]

Those look good.

> Section 5.6
> 
>   Can someone help me here?  Do we really want to complicate the state machine by 
>   adding all the "If both ends support it, we do TLS now" states, or should we
>   just add a section 5.6.5 describing that a TLS handshake will begin when
>   both ends are in the open state, and all further messages will be sent via TLS?

I think that that we just add section 5.6.5.

> New Section 6.10 (bump the others)

Got it, with modifications.  Also bumped all references of 6.10 and on.
 
> 6.10 Inband-Security-Id

Should be:

6.10 Inband-Security-Id AVP

>    The Inband-Security-Id AVP (AVP Code TBD) is of type Unsigned32 and
>    is used in order to advertise support of the Security portion of the
>    application.
> 
>    Currently, the following values are supported, but there is ample room
>    to add new security Ids.
> 
>       NO_SECURITY                       0
>          This peer does not support any security model.  This is the default
>          value, if the AVP is omitted.
> 
>       TLS                               1
>          This node supports TLS security, as defined by [TLS].

A small quibble - I think NO_SECURITY should be NO_TLS_Security.  If IPsec is
running, then there is security.

So I propose:

       NO_TLS_SECURITY                    0
          This peer does not support the TLS security model.  This is the 
          default value, if the AVP is omitted.
 
> Section 11.15
> 
> Delete the following lines:
> 
>    The following values are to be placed into the registry:
> 
>       Services Field               Protocol AAA+D2T
>       TCP AAAS+D2T                      TLS over TCP AAA+D2S
>       SCTP AAAS+D2S                      TLS over SCTP
> 
> Apendix B. NAPTR Example
> 
>    Delete all examples with AAAS.  Result should look like:
> 
>    ;;          order pref flags service           regexp  replacement
>       _diameters._sctp.ex.com.  IN NAPTR 50   50  "s"  "AAA+D2S"
>       ""  _diameters._tcp.ex.com.  IN NAPTR 100  50  "s"  "AAA+D2T"
>       ""  _aaa._tcp.ex.com
> 
>    This indicates that the server supports SCTP and TCP,  in that order.
>    If the client supports SCTP, SCTP will be used, targeted to a host
>    determined by an SRV lookup of _diameters._sctp.ex.com. That lookup
>    would return:
> 
> 
>    ;;          Priority Weight Port   Target
>       IN SRV  0        1      5060   server1.ex.com IN SRV  0        2
>       5060   server2.ex.com

Got it.

Also added this to section 10.1

                    +-----------------------------------------------+
                    |                  Command-Code                 |
                    |---+---+---+---+---+---+---+---+---+---+---+---+
Attribute Name      |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------|---+---+---+---+---+---+---+---+---+---+---+---|
...
Inband-Security-Id  |0+ |0+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |

John

---

From: "Kevin Purser" <[email-masked]>
Date: Tue, 16 Apr 2002 11:36:31 +0200

> running, then there is security.

I believe the idea with this AVP was to allow other potential transport
layer security mechanisms to be used.  Hence, NO_SECURITY.

Kev

---

From: David Frascone <[email-masked]>
Date: Tue, 16 Apr 2002 07:28:10 -0500

Comments inline.

>       NAPTR replacement field to match the domain of the original query.

I like that.

> >    supported Diameter applications, security model, etc.)

Correct.

> 6.10 Inband-Security-Id AVP

Oops.  Correct.

>           default value, if the AVP is omitted.

Ok, then NO_INBAND_SECURITY.  I think in the future someone might define
SSLv2,3 or JOE_BOBS_UNHACKABLE_SECURITY and use it instead of TLS.

> Also added this to section 10.1

Doh.  Missed that one.  Good Catch.

-- 
David Frascone

       Diets are for those who are thick and tired of it.