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

["Dan Harkins" <dharkins@lounge.org>]

  Hi Bernard

On Wed, August 1, 2007 6:16 pm, Bernard Aboba wrote:
[snip]
> I'm not clear why the KEK ID or KM ID is a covert channel any more than
> the
> IPsec SPI is a covert channel in the case where manual keying is used.

  A SPI for IPsec (manual keying or not) uniquely identifies necessary
context (the SA) to process the IPsec packet. It's possible that
different SAs could apply to different selectors and therefore have
different processessing requirements as well as different keys.

  The KEK ID does not identify necessary context to process a RADIUS
message because the draft only defines one addition key for use as a KEK
so that's all the context you need-- you implemented the draft you know
what the KEK is, it's the one you added to implement the draft. No need
to further identify it.

  The KM ID does not identify necessary context because the App ID says
what the particular key is. It's either an EAP-MSK or an EAP-EMSK or
an ERX-rMSK or an 11r-PMK or whatever. Sending multiple EAP-MSKs or
multiple ERX-rMSKs or muultiple 11r-PMKs in a single message to a
single RADIUS client for a single peer does not seem to be a requirement
of any EAP method or any application (HOKEY, 11i, etc) so there's no
need to further identify the key.

  The point being that there is nothing that could take the place of the
SPI to identify an IPsec SA but there is something that could take the
place of a KEK ID to identify a KEK (implicit context) and there is
something that could take the place of a KM ID to identify the keying
material being disclosed (App ID).

> However, two other questions come to mind:
>
> 1. As I understood it, the need for an explicit RADIUS shared secret name
> arises from the potential for key rollover and dynamic key management.
> Given the use of AES as the algorithm, is rollover support really
> necessary?

  I think the number of AES key wraps that can be safely done with a
single KEK is 2^48. I don't think that's a limit we need to worry
about. We could do one per second for 8.9 million years before we reach
the "unsafe" point.

>    Also, is there really a need for dynamic key management?  If not, could
> we get by with the RADIUS shared secret key naming scheme (using the IP
> addresses of the client and server as the key name)?

  Yes, that is the key name of the KEK. And the name of the KM is "<app-id>
for <foo>" where <app-id> is the identity in the App ID field and <foo> is
the username of the peer being authenticated. There is no need for a KEK ID
and a KM ID unless you want to send some information over a covert
channel.

  Dan.




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