Subject: RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"

From: "David B. Nelson" <[email-masked]>
Date: Mon, 13 Oct 2008 13:21:12 -0400

> > [Joe] There is some confusion.
> 
> I think an example packet exchange, showing how the client and server
> "negotiate" the algorithm they will mutually use would be helpful.
> 
> > [Joe] I'll try to provide some text by the end of the week.
> 
> Thanks.

PING!  :-)

--
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: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 15 Oct 2008 09:12:21 -0700

Here is text for section 4.6:

"[RFC 4107] provides guidelines for when automated key management is
necessary.  At the IETF-70 meeting, and leading up to that meeting, the
RADEXT WG debated whether or not RFC 4107 would require a RADIUS
Crypto-Agility solution to feature Automated Key Management (AKM).  The
working group determined that AKM was not inherently required for RADIUS
based on the following points:

o RFC 4107 requires AKM for protocols that involve O(n^2) keys.  This
does not apply to RADIUS deployments, which require O(n) keys

o RADIUS does not require he encryption of large amounts of data in a
short time

o Organizations already have operational practices to manage existing
RADIUS shared secrets to address key changes required through personnel
changes

o The crypto agility solution can avoid use cryptographic modes of
operation such as a counter mode cipher that require frequent key
changes

Automated key management is required for RADIUS crypto agility solutions
that use cryptographic modes of operation that require frequent key
changes."

I'm not sure what to provide for text for negotiation, because RADIUS
does not support capability negotiation.  

> -----Original Message-----
> From: David B. Nelson [mailto:[email-masked]] 
> Sent: Monday, October 13, 2008 10:21 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility 
> Requirements for RADIUS"
>

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 15 Oct 2008 13:28:56 -0400

Joseph Salowey writes...
 
> Here is text for section 4.6:

Thanks!  If no one objects, I'll incorporate that text into the next draft
version.

> I'm not sure what to provide for text for negotiation, because
> RADIUS does not support capability negotiation.

Right.  It comes down to the RADIUS client advertising what it can support,
by means of hint attributes included in the Access-Request packet, and the
RADIUS server picking at most one of the options.  The client doesn't get to
exercise its "preferences" here, but that's the basic nature of RADIUS, is
it not?  An Access-Reject packet means that either (a) the offered
cipher-suites were not acceptable or (b) something else about the
Access-Request was unacceptable / invalid.  In either case, you're not
getting access, at least without first contacting the system administrator.

The end user gets no indication of this, other than the fact that access is
denied.  Does it make a whole lot of difference to the user as to why?  If
it involves a Help Desk call in any event, and the system administrator can
determine the failure reason from the server logs, isn't that enough for a
simple solution?

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 15 Oct 2008 13:43:45 -0400

Following up...

> It comes down to the RADIUS client advertising what it can
> support, by means of hint attributes included in the 
> Access-Request packet, and the RADIUS server picking at most
> one of the options. 

So, it is apparent that use of encrypted packet payloads (either the entire
PDU or per attribute) cannot succeed until the cipher-suite is selected and
the client and server find that they share the required keys.  Without
getting into *design* of a solution, it seems feasible to me that the client
could "discover" the existence a cipher-suite and keys shared in common with
the server, without exposing any sensitive information using "classic"
RADIUS exchanges, by simply using a device such as the Call-Check mechanism,
to complete an Access-Request / Access-Accept (or Access-Reject) sequence
without disclosing any end user credentials.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 15 Oct 2008 11:13:52 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: Wednesday, October 15, 2008 10:44 AM
> To: [email-masked]
> support, by 
> > means of hint attributes included in the Access-Request packet, and 
> > the RADIUS server picking at most one of the options.
> 
> So, it is apparent that use of encrypted packet payloads 
> (either the entire PDU or per attribute) cannot succeed until 
> the cipher-suite is selected and the client and server find 
> that they share the required keys.  Without getting into 
> *design* of a solution, it seems feasible to me that the 
> client could "discover" the existence a cipher-suite and keys 
> shared in common with the server, without exposing any 
> sensitive information using "classic"
> RADIUS exchanges, by simply using a device such as the 
> Call-Check mechanism, to complete an Access-Request / 
> Access-Accept (or Access-Reject) sequence without disclosing 
> any end user credentials.
> 
[Joe] Yes, this would be possible, I think it would involve defining the
behavior in this type of error condition and the associated signaling.
It wouldn't necessarily be too hard, but it would be additional
messaging.  

> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 15 Oct 2008 14:24:38 -0400

Joseph Salowey writes...

> [Joe] Yes, this would be possible, I think it would involve 
> defining the behavior in this type of error condition and the
> associated signaling.  It wouldn't necessarily be too hard, but
> it would be additional messaging.

That's all I'm really looking for here.  Some assurance that existing RADIUS
mechanisms could be used, albeit in a sub-optimal fashion, to address the
requirement for cipher-suite "negotiation".  Said in other words, we are
creating no requirement to introduce capability negotiation into RADIUS in
order to complete the crypto-agility work.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 15 Oct 2008 19:04:03 -0700

> RADIUS server picking at most one of the options.

The term "offer/answer" model might make sense here.  That is, the RADIUS client offers potential ciphersuites, and the RADIUS server answers by picking one.  

However, there is an issue of how to prevent bidding down attacks on the "offers".  For example, what happens if the MD5 hash is cracked?  In such a circumstance, MD5 couldn't be the only mechanism used to protect the "offer".  Otherwise, an attacker recovering the MD5 key could then spoof an alternative offer, perhaps removing all offers other than MD5.  

It seems to me that the document needs to discuss this issue, as well as some of the transition assumptions/requirements.  

For example,  one might assume that the RADIUS server is initially upgraded so as to support both MD5
as well as an improved ciphersuite.  The RADIUS clients can then be upgraded to support the improved ciphersuite over time.   

In such an environment, the RADIUS server can be configured to REQUIRE the upgraded
ciphersuite on those clients that support it (thereby avoiding the bidding down attack entirely).  
However, in very large deployments, it might be very difficult to maintain a list of which clients
have been upgraded, and which haven't been.  So the server might be configured to support
both MD5 and an alternative for a transition period, before the new ciphersuite can be mandated. 

Alternatively, there might be some legacy RADIUS servers, so that upgraded clients cannot only support the new ciphersuite, but also need to continue to support MD5.  In this scenario, do the clients include both the legacy MD5 support and the new ciphersuite attributes?  Can legacy RADIUS servers be depended on to ignore the new attributes?

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 16 Oct 2008 10:36:56 -0700

> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, October 15, 2008 7:04 PM
> To: David B. Nelson; [email-masked]
> > Right. It comes down to the RADIUS client advertising what it can 
> > support, by means of hint attributes included in the Access-Request 
> > packet, and the RADIUS server picking at most one of the options.
> 
> The term "offer/answer" model might make sense here.  That 
> is, the RADIUS client offers potential ciphersuites, and the 
> RADIUS server answers by picking one.  
> 
[Joe] Does this require a new "offer/answer" exchange?  The client may
need to encrypt data in the request and it needs to authenticate the
request so it will have choose.   The server can either reject or accept
this message.  Its not clear that the client would know why the request
was rejected without new messaging.  

> However, there is an issue of how to prevent bidding down 
> attacks on the "offers".  For example, what happens if the 
> MD5 hash is cracked?  In such a circumstance, MD5 couldn't be 
> the only mechanism used to protect the "offer".  Otherwise, 
> an attacker recovering the MD5 key could then spoof an 
> alternative offer, perhaps removing all offers other than MD5.  
> 
> It seems to me that the document needs to discuss this issue, 
> as well as some of the transition assumptions/requirements.  
> 
[Joe] It sounds like we are heading towards a full feature negotiation
mechanism.  

> For example,  one might assume that the RADIUS server is 
> initially upgraded so as to support both MD5
> as well as an improved ciphersuite.  The RADIUS clients can 
> then be upgraded to support the improved ciphersuite over time.   
> 
> In such an environment, the RADIUS server can be configured 
> to REQUIRE the upgraded ciphersuite on those clients that 
> support it (thereby avoiding the bidding down attack entirely).  
> However, in very large deployments, it might be very 
> difficult to maintain a list of which clients have been 
> upgraded, and which haven't been.  So the server might be 
> configured to support both MD5 and an alternative for a 
> transition period, before the new ciphersuite can be mandated. 
> 
[Joe] Without a policy for which clients support only the legacy scheme,
I'm not sure how you can avoid the problem.  

> Alternatively, there might be some legacy RADIUS servers, so 
> that upgraded clients cannot only support the new 
> ciphersuite, but also need to continue to support MD5.  In 
> this scenario, do the clients include both the legacy MD5 
> support and the new ciphersuite attributes?  Can legacy 
> RADIUS servers be depended on to ignore the new attributes? 
> 
[Joe] This might bad, for example do you really want to send your
password with weak encryption? This would eliminate the benefit of the
stronger encryption.