RE: [HOKEY] comments on draft-gaonkar-radext-erp-attrs-00

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

Yoshihiro Ohba <mailto:yohba@tari.toshiba.com> allegedly scribbled on
Sunday, July 15, 2007 7:27 PM:

> I agree with Glen's analysis (except that the entity that requests a
> DSRK from home domain server is a visited domain server, not a NAS in
> my reading of the draft).  Security property of a key management
> mechanism that relies on a particular AAA protocol deployment can
> easily be lost when the AAA protocol is deployed in a wrong way
> (e.g., placing a AAA proxy that can read the key on the key
> distribution path).  The problem with such an approach is there is no
> protocol-level mechanism to prevent mis-deployment of AAA protocol. I
> don't think such a mechanism should survive in the long run.  

Whether or not it should is a theoretical question: the fact is that it
has & most likely will for the foreseeable future.
     
> 
> A securer and cleaner way to avoid dependency on AAA protocol
> deployment is to use a 3-party key distribution protocol that does
> not rely on underlying transport security.  HOKEY WG is already
> taking that approach: draft-ietf-hokey-key-mgm-00.txt.   

I'd just like to reiterate (as co-chair) that if this document is to
survive, it needs to become a lot more protocol specification & a lot
less term paper rather quickly.  There is far too much handwaving going
on for it to be taken seriously: the document needs to clearly &
precisely state how it will work in _existing networks_ (hint: "we
assume green-field deployments" is _not_ acceptable as far as I'm
concerned).  In addition, if a three-party protocol is actually required
from a practical point of view, there need to be very good reasons why
an existing standard (i.e., Kerberos) is not usable.

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