Subject: RE: RADEXT WG Last Call on "TLS Encryption for RADIUS" (Experimental)

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 25 Apr 2010 15:49:28 -0700

I am starting work on a PROTO writeup for this document, on the assumption
that "lack of response implies consent".  If any issues become apparent 
in the course of that review, I'll post them to the list. 

While that's in progress,  WG participants are encouraged to:

a. Read the document, and post any thoughts to the list (even if that is
only
"the document appears ready"); 
b. Continue to make progress on closing issues within dependency documents 
(e.g. RADIUS over TCP, Status-Server); 
c. Post updates on implementation progress; 

Thanks for your efforts on this document!

-----Original Message-----
From: Stefan Winter [mailto:[email-masked]] 
Sent: Tuesday, April 20, 2010 4:45 AM
To: Bernard Aboba
Subject: Re: RADEXT WG Last Call on "TLS Encryption for RADIUS"
(Experimental)

Hi,

so...? Is the absence of comments enough to justify going on to IETF LC?
Would be much appreciated :-)

Stefan

Am 19.03.2010 20:59, schrieb Bernard Aboba:
> This is an announcement of RADEXT WG last call on "TLS Encryption for
> RADIUS", prior to sending the document to the IESG for publication as
> an Experimental RFC.
>
> The document is available for inspection here:
> http://tools.ietf.org/html/draft-ietf-radext-radsec
>
> The RADEXT WG last call will last until April 19, 2010.   If you have
> comments on the document, please send them to the RADEXT WG mailing
> list ([email-masked]) in the format described on the RADEXT
> Issues list (http://www.drizzle.com/~aboba/RADEXT/ ). 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Apr 2010 22:46:43 +0200

> c. Post updates on implementation progress; 

  My comments are editorial only.

>...
>  There are multiple known attacks on the MD5 algorithm
>...

  Adding reference(s) would be good.  These can be lifted from RFC 3579,
among others.

>...
>      These middleboxes may learn privacy-
>   relevant data while forwarding requests.
>...

  RADIUS over TLS doesn't solve this problem.  It's still "hop by hop",
and doesn't create "end to end" security.  The use of proxies is still
useful in many environments, and those proxies still have access to all
of the privacy-relevant data.

>...
>   1.  establish TCP connections as per ...
>
>   2.  negotiate TLS sessions according to [RFC5246] or its predecessor
>       TLS 1.1.
>...

  It would be good to note that there is no RADIUS equivalent of
"starttls".  A client and server is marked either as "supporting TLS",
or "not supporting TLS".  So the client/server just "starts TLS" if TLS
is supported.

  i.e. the above text could be understood as "negotiate TLS version and
features", and not "negotiate whether or not to use TLS".

  It may be sufficient to note that step (1) MUST be immediately
followed by step (2), and "bare TCP" on port 2083 MUST NOT be used.

>...
>   In RADIUS/UDP, clients are uniquely identified by their IP address.
>   This does not permit to determine when
>...

  English: This *what* ..

  And elsewhere in the document.  The word "this" should usually be
followed by a specifier, e.g. noun.

  and: Does not permit *who* to determine...?

>...
>3.2.  Ciphersuites and Compression Negotiation Considerations
>
>   Not all TLS ciphersuites in [RFC5246] are supported by available TLS
>   tool kits, and licenses may be required in some cases.  The existing
>   implementations of RADIUS/TLS use OpenSSL as cryptographic backend,
>   which supports all of the ciphersuites listed in the rules in the
>   normative section.
>..

  The implementation text could be put into an "implementation notes"
section.  But it's not serious.

>...
>   (1) After the TLS session is established, RADIUS packet payloads are
>   exchanged over the encrypted TLS tunnel.  In RADIUS/UDP, the packet
>   size can be determined by evaluating the size of the datagram that
>   arrived.  Due to the stream nature of TCP and TLS, this does not >hold
>   true for RADIUS/TLS packet exchange.  Instead, packet boundaries of
>   RADIUS packets that arrive in the stream are calculated by >evaluating
>   the packet's Length field.  Special care needs to be taken on the
>   packet sender side that the value of the Length field is indeed
>   correct before sending it over the TLS tunnel, because incorrect
>   packet lengths can no longer be detected by a differing datagram
>   boundary.
>...

  Adding a reference to RADIUS over TCP, Section 2.6.4 may be good.  It
outlines these issues in more detail.

>...
>   If a given IP device is able to receive RADIUS payloads on multiple
>   transports, this may or may not be the same instance of software,
>and
>   it may or may not serve the same purposes.  It is not safe to assume
>   that both ports are interchangeable.  In particular, it can not be
>   assumed that state is maintained for the packet payloads between the
>   transports.  Two such instances MUST be considered separate RADIUS
>   server entities.
>...

  Ideally, this text should be similar between this doc, the TCP doc,
and the DTLS doc.  I'll take a look at regularizing some of it.

>...
>   If peer communication between two devices is configured for both
>   RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic
>   RADIUS security opens the way for a down-bidding attack if an
>   adversary can maliciously close the TCP connection, or prevent it
>   from being established.  In this case, security of the packet
> payload
>   is reduced from the selected TLS cipher suite packet encryption to
>   the classic MD5 per-attribute encryption.
>...

  It may be worth discussing how to address that issue.  i.e. both
transports SHOULD be configured only temporarily, as part of a migration
strategy.  Once a secure transport is available, the RADIUS/UDP method
SHOULD be deprecated.  This issue is easier for the TCP document, where
no security means bidding-down isn't an issue.  It's also the subject of
much discussion in the DTLS draft, which re-uses the same server port &&
transport, so bidding-down needs to be handled very carefully.

Nits: the document uses the terms RADIUS/UDP, RADIUS/TCP, and
RADIUS/TLS.  These are not consistent with the TCP or DTLS documents.
It would be good to make all of these consistent across the documents.

  Does the WG have a preference for *which* terminology to use?

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 26 Apr 2010 22:57:58 -0700

2.  negotiate TLS sessions according to [RFC5246] or its predecessor
       TLS 1.1.  The following restrictions apply:

       *  The authentication MUST be mutual, i.e. both the RADIUS/TLS
          server and the RADIUS/TLS client authenticate each other.

       *  The client MUST NOT negotiate cipher suites which only provide
          integrity protection.

       *  The TLS session MAY use mutual PSKs for connection setup.

       *  Negotiation of compression for the TLS session is OPTIONAL.

       *  RADIUS/TLS implementations MUST support the mandatory to
          implement cipher suites specified in TLS (i.e.
          TLS_RSA_WITH_3DES_EDE_CBC_SHA).  For purposes of compatibility
          with some current deployments implementations SHOULD support
          TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as
          well (see Section 3.2 (1) ).

[BA] Several issues with this:

a.  There is no statement about mandatory to implement TLS version (e.g. MUST
support TLS 1.0 and later).  

b. There is no statement about mandatory to implement authentication mechanism
(e.g. mutual TLS with certificates).  

Recommend re-writing as follows:

"  2.  negotiate TLS sessions.  The following restrictions apply:

       *  Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 [RFC5246]) is REQUIRED. 

       *  Support for compression is OPTIONAL. 

       *  Support for certificate-based mutual authentication is REQUIRED. 

       *  Support for TLS-PSK mutual authentication [RFC4279] is OPTIONAL.  

       *  Negotiation of mutual authentication is REQUIRED. 

       *  Negotiation of a ciphersuite providing for confidentiality as well
          as integrity protection is REQUIRED.  

       *  RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL encryption (e.g. [RFC4785]).  

       *  Negotiation of compression is OPTIONAL.

       *  RADIUS/TLS implementations MUST at a minimum support negotiation
          of the TLS_RSA_WITH_3DES_EDED_CBC_SHA ciphersuite, and SHOULD
          support TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as
          well (see Section 3.2 (1) ).

       *  In addition, RADIUS/TLS implementations MUST support negotiation of
          the mandatory-to-implement ciphersuites required by the versions of TLS
          that they support."  

       *  Certificate validation MUST include the verification rules as
          per [RFC5280], using information from trusted sources only
          (e.g. locally configured names).  If service names as per
          [RFC4985] are present in the certificate and dynamic discovery
          utilizing SRVs in DNS is used (see
          [I-D.winter-dynamic-discovery]) and the TLS implementation
          supports evaluation of the extensions in [RFC4985], the SRV
          entry MUST be validated.  In cases where no DNS SRV resolution
          took place to arrive at the TLS peer, subjectAltName:SRV
          entries can be ignored.

[BA]  I'm not clear what "using information from trusted sources only"
means, exactly. 

Given the MUST here, the reference to dynamic discovery is probably
normative.  My suggestion is to move this material to the dynamic discovery
draft so as to remove the normative dependency.  

Among other things, moving this to the dynamic discovery document will
provide some additional time to think through the security issues.  

Use of the extensions in [RFC4985] does not necessarily address the
problem of forgery of DNS SRV RRs unless some kind of name constraint is also
applied.  For example, an attacker could forge an SRV RR that indicates that the
RADIUS/TLS server for example.com is hosted with the evilhacker.com domain, and
the fradulent RADIUS/TLS server could provide a valid certificate with a
service extenion indicating its acting as the RADIUS/TLS server for example.com. 
The problem is that the certificate chain will not include a trust anchor within
the example.com domain.  

2.3. Connecting Client Identity

   In RADIUS/UDP, clients are uniquely identified by their IP address.
   This does not permit to determine whether the connecting entity is a
   NAS or a different server which proxies a request.  When NAT is used
   on the path to the server, it also does not permit to determine
   whether there is more than one entity connecting from the same IP
   address.

[BA] The NAS is identified by the NAS-Identifier/NAS-IP-Address/NAS-IPv6-Address
attributes, no?  Since RADIUS identifies entities by IP address, by
definition all packets originating from a given IP address are assumed
to come from the same entity.  Suggest rewriting as follows:

 " In RADIUS/UDP, clients are uniquely identified by their IP address.
   Since the shared secret is associated with the origin IP address, 
   if more than one RADIUS client is associated with the same IP
   address, then those clients also must utilize the same shared secret,
   a practice which is inherently insecure as noted in [RFC5247]."

   RADIUS/TLS makes it possible to preserve this traditional RADIUS
   semantics by identifying a connecting client by the IP address which
   initiated the TLS connection.  In addition, it permits a much more
   fine-grained identification.  The parameters of the TLS connection
   can be attributed to the RADIUS packets inside the TLS connection.
   An implementation of RADIUS/TLS should expose as many details of the
   TLS connection which belongs to an incoming RADIUS packet as possible
   to the application layer to allow the administrator to define the
   identification criteria which are applicable to his desired
   operational model.  In X.509 certificate operation, at least the
   following parameters of the TLS connection should be exposed:

   o  Originating IP address

   o  Certificate Fingerprint

   o  Issuer

   o  Subject

   o  all X509v3 Extended Key Usage

   o  all X509v3 Subject Alternative Name

   o  all X509v3 Certificate Policies

   In TLS-PSK operation, at least the following parameters of the TLS
   connection should be exposed:

   o  Originating IP address

   o  TLS Identifier

[BA] It seems to me that the above text is somewhat too vague in that it doesn't
precisely define what parameters should be used to differentiate RADIUS clients
and servers from each other. 

2.4. RADIUS Datagrams

   Authentication, Accounting and Authorization packets are sent
   according to the following rules:

   RADIUS/TLS clients handle the following packet types from [RFC2865],
   [RFC2866], [RFC5176] on the connection they initiated (see
   Section 3.3 (3) and (4) ):

   o  send Access-Request

   o  send Accounting-Request

   o  send Status-Server

   o  send Disconnect-ACK

   o  send Disconnect-NAK

   o  send CoA-ACK

   o  send CoA-NAK

   o  receive Access-Challenge

   o  receive Access-Accept

   o  receive Access-Reject

   o  receive Accounting-Response

   o  receive Disconnect-Request

   o  receive CoA-Request

   RADIUS/TLS servers handle the following packet types from [RFC2865],
   [RFC2866], [RFC5176] on the connections they serve to clients:

   o  receive Access-Request

   o  receive Accounting-Request

   o  receive Status-Server

   o  receive Disconnect-ACK

   o  receive Disconnect-NAK

   o  receive CoA-ACK

   o  receive CoA-NAK

   o  send Access-Challenge

   o  send Access-Accept

   o  send Access-Reject

   o  send Accounting-Response

   o  send Disconnect-Request

   o  send CoA-Request

[BA] This assumes that the RADIUS server is also a Dynamic Authorization Client.  This is not 
necessarily the case.   CoA-Request and Disconnect-Request packets can also be sent by a 
DAC that originates its own TLS connection, no? 

My suggestion is that you separate the DAC/DAS roles from the RADIUS client/server roles in this
section.  I'd also note that the RADIUS over TCP document does not recommend that Dynamic
Authorization traffic be sent over TLS.