RE: Review of draft-zorn-radius-keywrap-07.txt

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

Bernard Aboba <> supposedly scribbled:

>> There was a discussion at IETF-63 of whether the key-wrap in the Zorn
>> draft was hop-by-hop or end-to-end.  The answer was that it could be
>> either. The RADEXT session minutes read: "They are passed along the
>> path in the way they are set-up - may be hop-by-hop."
>> 
>> In speaking with Russ Housely on the key-wrap issues, Russ indicated
>> that it would need to be on an end-to-end basis.

Except that that's not how RADIUS works...

>> 
>> BTW, the hop-by-hop key-wrap is also an issue with the key-wrap
>> attributes in the Aboba draft.
> 
> Right.  Russ Housley has indicated that he will work with Sam Hartman
> to 
> provide a clear statement of requirements.
> 
> End-to-end key management support has been something of a "holy
> grail" with the AAA community -- many attempts to find it, but little
> in the way of documented success.  
> 
> AAA WG worked on Diameter CMS for several years before giving up, and
> adopting support for Redirect within Diameter EAP (RFC 4072). 
> However, I don't believe that it would be viable to retrofit Redirect
> functionality within RADIUS. 

I don't think it would be useful, either, in the absence of the elusive "ubiquitous PKI".

> 
> IN terms of other alternatives, there was a Kerberos proposal a while
> back:
> http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt
> 
> There is also work ongoing within Terena on a DNSSEC-based approach:
> http://www.lab.telin.nl/~arjan/pub/tnc05-ea-eertink.pdf
> http://www.lab.telin.nl/~arjan/pub/radius-dnssec.pdf

Unfortunately, the solution proposed by Terena doesn't appear to satisfy the "Housley Criteria" either -- the number of parties that "have access to keying material that is not needed to perform their own role" is reduced but not eliminated (presupposing that one interprets the appropriate role of key-holders as being just to apply security to (for example) the 802.11 traffic).  Under that interpretation, though, I don't think that Kerberos would satisfy the criteria, either: a Kerberos server has knowledge of lots of keys that are used by various parties for to protect things that are none of the server's business (e.g., telnet data).  With Kerberos, we get around that little problem by declaring the Kerberos server to be unconditionally trusted.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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