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

[Bernard Aboba <aboba@internaut.com>]

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

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

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