Subject: [radext] AD Review of draft-ietf-radext-radsec-10

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 12 Jan 2012 14:37:25 +0100

Hi,

This is the AD review of draft-ietf-radext-radsec-10. The document is in
good shape and I am sending it to IETF Last Call. Please address the
comments below together with the other IETF Last Call comments. 

Technical comments are marked T and Editorial comments are marked E. 

T1. The Intended status of the document is Experimental. I would suggest
to add some text to clarify: 
- what is the scope of the experiment - any specific features,
behaviors, performance, scalability data that would validate the
experiment and allow for possible migration of the document to Standards
Track in the future
- any restrictions in deployment or other operational considerations
that should be known by operators or implementers? 

T2. In Section 4: 

>  As a consequence, the selection of transports to communicate from a
   client to a server is a manual administrative action.  An automatic
   fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down-
   bidding attacks on the peer communication.

This (non-)recommendation is not clear to me. Actually if no other
transport works for a given RADIUS entity or between a client and a
server a fallback to RADIUS/UDP will always happen because this is the
current standard and mandatory-to-implement transport. What is meant
here - I think - is to RECOMMEND that manual administrative interfaces
be made available for configuration of transport and that these
interfaces be used to select the preferred transport between clients and
servers. 

E1. Section 2.3

> after completing the TCP handshake, immediately negotiate TLS
       sessions.  The following restrictions apply: according to
       [RFC5246] or its predecessor TLS 1.1.  The following restrictions
       apply:

'The following restrictions apply' appears twice - drop one of them

E2. Add reference to RFC 6421 and link to it from Appendix C.

Thanks and Regards,

Dan

_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Stefan Winter <[email-masked]>
Date: Wed, 25 Jan 2012 11:46:03 +0100

Hello Dan,

thanks for these comments. Responses inline...

> that should be known by operators or implementers? 

My working copy now has this new section 1.3:

1.3.  Document Status

   This document is an Experimental RFC.

   It is one out of several approaches to address known cryptographic
   weaknesses of the RADIUS protocol (see also Section 4).  The
   specification does not fulfill all recommendations on a AAA transport
   profile as per [RFC3539]; in particular, by being based on TCP as a
   transport layer, it does not prevent head-of-line blocking issues.

   It has yet to be decided whether this approach is to be chosen for
   standards track.  One key aspect to judge whether the approach is
   usable at large scale is by observing the uptake, usability and
   operational behaviour of the protocol in large-scale, real-life
   deployments.  One of these deployments could be the eduroam roaming
   consortium.

Does that address your comment?

> interfaces be used to select the preferred transport between clients and

The fallback scenario and this warning apply only for transition phases
where the same RADIUS client is moved from RADIUS/UDP to RADIUS/TLS. It
goes like:

RADIUS Server understands both UDP and TLS.
RADIUS client understands only UDP -> client is configured on the server
as the tuple (transport UDP, IP, shared secret).

Now the RADIUS client is scheduled for an upgrade and can from then on
also use RADIUS/TLS. To avoid a flag day, the server is configured to
accept incoming requests from that client both via UDP and TLS prior to
the client upgrade being done
-> RADIUS Server has two tuples:
 (transport UDP, IP, shared secret)
 (transport TLS, IP, TLS credential)

The client can now be upgraded at convenience to speak TLS. It might
also be tempting to configure RADIUS/UDP as a fallback if it cannot
establish a connection via TLS.

This opens up a bidding-down attack by an attacker sitting between
client and server: if it can silently discard TCP SYNs, the (better) TLS
encryption will not be used, and the client will send its requests with
RADIUS/UDP again.

Mitigating this can be done on either side. Either the RADIUS client is
configured not to use RADIUS/UDP as a fallback for its outgoing
connection attempts; or the RADIUS server can be configured to delete
the RADIUS/UDP client from its list of authorized clients.

The text you quoted is to make the client end aware that configuring a
fallback to RADIUS/UDP is a bad idea.

The text for the server side is contained in chapter 6, Security
Recommendations, last-but-one paragraph.

I guess the text you quoted is misplaced in the document. It would
probably be better to consolidate both sides into the Security
Considerations section. Would that be okay with you?

> 'The following restrictions apply' appears twice - drop one of them

Fixed in my working copy, thanks!

> E2. Add reference to RFC 6421 and link to it from Appendix C.

Fixed in my working copy, thanks!

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 25 Jan 2012 11:46:03 +0100

Hello Dan,

1.3.  Document Status

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 25 Jan 2012 15:09:15 +0100

Hi Stefan,

See in-line. 

The LC ends tomorrow, Can you make a new version available immediately after, so that I can place the document on the agenda of the 2/2 IESG telechat? 

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stefan Winter
> Sent: Wednesday, January 25, 2012 12:46 PM
> To: [email-masked]
> Subject: Re: [radext] AD Review of draft-ietf-radext-radsec-10
> 
> Hello Dan,
> 
> > This is the AD review of draft-ietf-radext-radsec-10. The document is
> > in good shape and I am sending it to IETF Last Call. Please address
> > the comments below together with the other IETF Last Call comments.
> >
> > T1. The Intended status of the document is Experimental. I would
> > suggest to add some text to clarify:
> > experiment and allow for possible migration of the document to
> > Standards Track in the future

[[DR]] Yes. My only comment would be that I would keep the mention to the eduroam deployment in a separate paragraph and keep the existing wording about it: 

   An example for a world-wide roaming environment that uses RADIUS over
   TLS to secure communication is "eduroam", see [eduroam].

> > interfaces be used to select the preferred transport between clients
> > and servers.
> 
> RADIUS client understands only UDP -> client is configured on the
> server as the tuple (transport UDP, IP, shared secret).
> 
> client and server: if it can silently discard TCP SYNs, the (better)
> TLS encryption will not be used, and the client will send its requests
> with RADIUS/UDP again.
> 

[[DR]] Yes, this would be easier to follow. 

> de la Recherche 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
> 
> Tel: +352 424409 1
> Fax: +352 422473

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 25 Jan 2012 15:09:15 +0100

Hi Stefan,

See in-line. 

Thanks and Regards,

Dan

---

From: Stefan Winter <[email-masked]>
Date: Thu, 26 Jan 2012 08:02:48 +0100

Hi,

> The LC ends tomorrow, Can you make a new version available immediately after, so that I can place the document on the agenda of the 2/2 IESG telechat? 

Sure thing. If all goes well, -11 should be out tomorrow (Friday).

Two things inline.

>    TLS to secure communication is "eduroam", see [eduroam].

Ok, changed in my working copy.

> [[DR]] Yes, this would be easier to follow. 

Ok. Bernard also raised an issue about this paragraph in the aaa-doctors
review, so I'll change the wording as per his comment and move it all to
Security Considerations.

Thanks,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Thu, 26 Jan 2012 08:02:48 +0100

Hi,

Two things inline.

Thanks,

Stefan

Tel: +352 424409 1
Fax: +352 422473