Subject: Re: [radext] Adrian Farrel's No Objection on draft-ietf-radext-radsec-11:(with COMMENT)

From: Bernard Aboba <[email-masked]>
Date: Sat, 4 Feb 2012 10:49:29 -0800

The proposed text conflates manual keying with use of a shared secret.   TLS-PSK provides automated key
management as well as protected ciphersuite negotiation and is a big step forward from RFC 2865 manual 
keying with deprecated algorithms.  Given the discussion of RFC 4107 within RFC 6421, I'd suggest that the
context provided by RFC 6421 is important for understanding how RFC 4107 would apply to RADIUS, 
particularly given the RADEXT WG's concerns about the relevance of RFC 4107. 

Here is are some proposed changes: 

 "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 (described in Section 4), as well
   as to provide support for crypto-agility as described in "RADIUS Crypto-Agility
   Requirements" [RFC6421].  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.

   If this specification is indeed selected for advancement to standards
   track, the process described in [RFC6421] will need to be followed and
   in particular, certificate verification options (section 2.3.2) will need to be
   refined.

   Another experimental characteristic of this specification is the
   question of key management between RADIUS/TLS peers.  RADIUS/UDP only
   allowed for manual key management, i.e. distribution of a shared
   secret between a client and a server.  RADIUS/TLS allows manual
   distribution of long-term proofs of peer identity as well (by using
   TLS-PSK cipher suites, or identifying clients by a certificate
   fingerprint), but as a new feature enables use of X.509 certificates 
   in a PKIX infrastructure.  It remains to be seen if one of these methods 
   prevail, or if both will find their place in real-life deployments.  The authors can imagine
   pre-shared keys to be popular in small-scale deployments
   (SOHO or isolated enterprise deployments) where scalability is not an
   issue and the deployment of a CA is considered too much a hassle; but
   can also imagine large roaming consortia to make use of PKIX.
   Readers of this specification are encouraged to read the discussion
   of key management issues within [RFC6421] as well as [RFC4107]. 

   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.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Winter
Sent: Friday, February 03, 2012 1:59 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]; [email-masked]; The IESG; [email-masked]
Subject: Re: Adrian Farrel's No Objection on draft-ietf-radext-radsec-11:(with COMMENT)

Hello all,

> Yes, I was going to ask this during the telechat should this answer have not come. Editors, please add some text in the revised version after the telechat that shows that the issue was considered and what key management methods were taken into consideration at the time of the publication of the document. This would also provide reference for experimentation. 

Okay... how about the following text in "Document Status" (third para is
new):

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.

   If this specification is indeed selected for advancement to standards
   track, certificate verification options (section 2.3.2) need to be
   refined.

   Another experimental characteristic of this specification is the
   question of key management between RADIUS/TLS peers.  RADIUS/UDP only
   allowed for manual key management, i.e. distribution of a shared
   secret between a client and a server.  RADIUS/TLS allows manual
   distribution of long-term proofs of peer identity as well (by using
   TLS-PSK cipher suites, or identifying clients by a certificate
   fingerprint), but as a new feature also allows automatic key
   management using X.509 certificates in a PKIX infrastructure.  It
   remains to be seen if one of these methods prevail, or if both will
   find their place in real-life deployments.  The authors can imagine
   manual key distribution to be popular in small-scale deployments
   (SOHO or isolated enterprise deployments) where scalability is not an
   issue and the deployment of a CA is considered too much a hassle; but
   can also imagine large roaming consortia to make use of PKIX.
   Readers of this specification are encouraged to read [RFC4107].

   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.

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

If that text is sufficient to address the COMMENT (please let me know), I would issue -12 with it (this is the last pending comment).

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: Bernard Aboba <[email-masked]>
Date: Sat, 4 Feb 2012 10:49:29 -0800

"1.3.  Document Status

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Winter
Sent: Friday, February 03, 2012 1:59 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]; [email-masked]; The IESG; [email-masked]
Subject: Re: Adrian Farrel's No Objection on draft-ietf-radext-radsec-11:(with COMMENT)

Hello all,

1.3.  Document Status

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

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

---

From: Stefan Winter <[email-masked]>
Date: Fri, 10 Feb 2012 11:22:45 +0100

Hello,

> particularly given the RADEXT WG's concerns about the relevance of RFC 4107.

Thanks for the text suggestions - I have updated my working copy 
accordingly.

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: Fri, 10 Feb 2012 11:22:45 +0100

Hello,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473