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

[Yoshihiro Ohba <yohba@tari.toshiba.com>]

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.

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.

Regards,
Yoshihiro Ohba



On Sun, Jul 15, 2007 at 03:05:20PM -0700, Glen Zorn (gwz) wrote:
> I would like to note that there is pre-existing work in this area
> (http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-07.txt,
> http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt).
> Be that as it may, however, it's difficult to understand what the
> purpose of the Requesting Entity's Identity in the express environment
> that is implied by the draft (i.e., a request from a visited network to
> a home network).  If, as I assume (please correct me if my assumption is
> incorrect), the requesting entity is a NAS it doesn't seem reasonable to
> believe that the RADIUS server in a remote network would have any
> knowledge of it, even less so in the case where the visited and home
> networks are separated by one or more proxies & thus lack any direct
> trust relationship.  If this identity is meant to be used for key
> binding purposes, I think that this is incredibly dangerous, imputing
> trust as it does between the home RADIUS server and an entity of which
> it possesses no knowledge.  OTOH, suppose that there _is_ a direct trust
> relationship between the home & visited network, intervening proxies
> notwithstanding (perhaps by means of an OOB WRT RADIUS key exchange);
> further, suppose that this trust is so strong that the home RADIUS
> server is willing to take the visited domain at its word as to the
> identity of the requesting NAS.  In this case, the security of the
> protocol is defeated by the use of IPsec on a hop-by-hop basis since the
> message and key are available in plaintext form at each (less trusted)
> hop.

> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey


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