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

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> 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; 

  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.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>