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

From: <[email-masked]>
Date: Mon, 15 Apr 2002 13:01:05 +0300

Hi All,

I support this change, however, we should go about proposing a 
solution for this.  Any takers?

John

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 11 April, 2002 06:13
> To: [email-masked]
> Subject: [AAA-WG]: [Issue 330]: Diameter should not require 
> separate TLS
> port
> 
> 
> Issue 330:  Diameter should not require separate TLS port
> Submitter name: Allison Mankin
> Submitter email address: [email-masked]
> Date first submitted: 04-10-2002
> Reference:
> Document: draft-base-10
> Comment type: Technical
> Priority: S
> Section: 2.1 (contradicts section 13.3)
> 
> Justification: The IESG is encouraging WGs to enable their 
> applications to negotiate an upgrade to TLS rather than requiring 
> a separate port. Diameter cannot yet handle this "startTLS" 
> up-negotiation. Do not assume that Diameter will be granted 
> an addition port for use with TLS. 
> 
> Change: 
> Need support for TLS up-negotiation in Diameter.
> 
> 
>

---

From: David Frascone <[email-masked]>
Date: Mon, 15 Apr 2002 09:45:49 -0500

Ok, here is my first cut at it.  I'm sure I've missed a bit.  Adding TLS
handshaking is a pretty huge change.  

I did *not* modify the state machine, but added a cry for help (see the
changes below)

-Dave

------------snip----------------

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

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

Section 5.2, item 3 & 3.x

	[snip]

        3.1 The services relevant for the task of transport protocol
            selection are those with NAPTR service fields with values
***            "AAA+D2x", where x is a letter that
            corresponds to a transport protocol supported by the domain.

	[snip]

****        delete section 3.2

        3.2[was 3.3] If no NAPTR records are found, the requester queries for
            those address records for the destination address,
*****        '_diameter._sctp'.realm or '_diameter._tcp'.realm. Addressrecords
            include A RR's, AAAA RR's or other similar records, chosen
            according to the requestor's network protocol capabilities.
            If the DNS server returns no address records, the requestor
            gives up.

*****         If the server is
         using a site certificate, the domain name in the query and the
         domain name in the replacement field MUST both be valid based
         on the site certificate handed out by the server in the TLS
         exchange. Similarly, the domain name in the SRV query and the
         domain name in the target in the SRV record MUST both be valid
         based on the same site certificate. Otherwise, an attacker
         could modify the DNS records to contain replacement values in a
         different domain, and the client could not validate that this
         was the desired behavior, or the result of an attack.

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.)

   [snip]

   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.

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 ]

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?

New Section 6.10 (bump the others)

6.10 Inband-Security-Id

   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].

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

-- 
David Frascone

    (C) 1992 Wild Bill's Machine Gun Shop and House of Wax.