RE: comments on draft-gaonkar-radext-erp-attrs-00

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

Narayanan, Vidya <mailto:vidyan@qualcomm.com> allegedly scribbled on
Tuesday, July 17, 2007 4:18 PM:

...

> Not sure I understand.  It is very much feasible to provide the
> identity (of the domain or the HOKEY server) to the peer via the
> lower layer.

OK, cool.  Please provide a list of 1) all target lower layers and b)
how, precisely this identity is provided to the peer _now_.
  
> Also, ERP bootstrapping is capable of providing this identity to the
> peer - so, a lower layer capability here is not a MUST.  

OK, if it's not necessary let's not talk about it any more & simply say
that, shall we?

> More below
> on why the peer needs this identity.  
> 
>>> and via RADIUS protocol to the RADIUS server.
>> 
>> In the case where the DSRK server is separated from the home RADIUS
>> server by one or more proxies, why should the home server believe
>> the identity it receives? 
>> 
>>> The peer can
>>> communicate the identity in an end-to-end protected manner to the
>>> server, thus forcing the DSRK server to present the same identity to
>>> the peer and the server.
>> 
>> I still have problems understanding the utility of this.
>> Leaving aside the "lying proxy" problem, let's take an example from
>> real life: suppose that someone introduces himself to a young woman
>> as "Ted Bundy" and she checks with a trusted friend who confirms this
>> claimed identity.  If neither the young woman nor her friend knows
>> that "Ted Bundy" is a vicious serial killer, what good does this
>> confirmation do?  If you assume that the DSRK server cannot be
>> trusted (otherwise why force it to do anything?), then why does the
>> fact that it's not lying about its _name_ magically make it
>> trustworthy? 
>> 
> 
> I agree with you that channel bindings does not provide for
> correctness in identity, it only provides a consistency check.  In
> this case, however, I don't think channel bindings is the reason for
> the identity being sent.  The DSRK derivation takes the requesting
> entity's domain name or server ID as input to the PRF. Both parties
> deriving the key (the Home AAA/EAP server and the peer) need to know
> this identity so that the DSRK can be derived.  I believe that is the
> reason the identity needs to be provided along with a request for
> DSRK.  

OK, but that's not what was said above...it seems to me that for the
purpose you mention the name of the local DSRK server could as or more
easily be supplied by the home server to the peer, rather than relying
upon a lower layer (maybe you've noticed that I don't care for that ;-).

> Unless the peer and the server are given the same value, the
> DSRK cannot be derived correctly at both ends - so, the property of
> channel bindings may be inherently provided for the DSRK by virtue of
> that.           
> 
> Vidya

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