RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Bernard Aboba <> allegedly scribbled on Sunday, July 29, 2007 10:08 AM:

>> [Joe]  The proposal requires the use of new RADIUS attributes.  All
>> other aspects of the RADIUS protocol can remain the same, so backward
>> compatibility is possible.  However it is important to note that if
>> stronger that current security algorithms are required then backwards
>> compatibility is not possible.
> 
> [BA] Can you expand on this?  Couldn't a RADIUS packet sent by a NAS
> include both existing and new security attributes for backward
> compatibility?  

Yes.  However, section 3.3 says "Any packet that contains an instance of
the Message-Authentication-Code Attribute SHOULD NOT contain an instance
of the Message-Authenticator Attribute [RFC3579]."  This implies that
any message that contains an EAP-Message attribute must also include an
instance of the Message-Authentication-Code attribute (though I don't
think that that is spelled out).  So, for EAP exchanges over RADIUS at
least, there would be no problem determining whether or not the client
is "legacy" because it would include an instance of the
Message-Authenticator attribute in the Access-Request(s).

> 
>> 6. Crypto-agility solutions MUST avoid security compromise, even in
>> situations where the existing cryptographic algorithms utilized by
>> RADIUS implementations are shown to be weak enough to provide little
>> or no security (e.g. in event of compromise of the "legacy" RADIUS
>> shared secret). Included in this would be protection against bidding
>> down attacks. 
>> 
>> [Joe] Depending upon the selection of the key the new protection can
>> be completely separate from the existing protection.  The selection
>> of the key is currently a deployment choice.
> 
> [BA] If the existing RADIUS security mechanism is compromised, how
> does this affect the security of the negotiation?  For example, if
> both existing and new attributes are sent, couldn't an attacker strip
> off the new attributes and recalculate the Message-Authenticator
> attribute? 

As an aside, AFAIK the fact that a secret key algorithm 'provide(s)
little or no security' if the key is compromised has nothing to do with
the strength or weakness of the algorithm itself (as is implied above).
Be that as it may, however, you are correct, I think.  That's why the
"SHOULD NOT" referenced above was included; in fact, it was a MUST NOT
in early versions of the draft (up to -07, I think) & I'd be happy to
return to that usage.  I don't really think that that would affect
backwards compatibility too much (if at all).

...

>> 10. Proposals MUST include a Diameter compatibility section, although
>> it is expected that the work will occur purely within RADIUS or in
>> the transport, and therefore does not affect message data that is
>> exchanged with Diameter. 
>> 
>> [Joe] A Diameter compatibility section will need to be added.
> 
> [BA] In terms of processing wouldn't a RADIUS/Diameter gateway just
> strip off the new attributes? 

Probably, yes.  Unfortunately: our drafts offer at least the possibility
of end-to-end cryptographic protection of both complete and partial
messages & the standard Diameter gateway processing would defeat that.

> Or are changes to RFC 4072 implementations required?

--
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/>