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

["Narayanan, Vidya" <vidyan@qualcomm.com>]

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:gwz@cisco.com] 
> Sent: Tuesday, July 17, 2007 4:33 PM
> To: Narayanan, Vidya; Dondeti, Lakshminath
> Cc: kgaonkar3@gatech.edu; radiusext@ops.ietf.org; hokey@ietf.org
> Subject: RE: comments on draft-gaonkar-radext-erp-attrs-00
> 
> 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_.
>   

The point I was making was that evolving link layers can certainly
include this functionality.  But, as indicated below, the protocol
doesn't rely on this possibility and hence, for this discussion, we can
avoid focusing on that. 

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

That's fine :) 

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

Yes, this capability is already in the protocol, as part of
bootstrapping. 

> rather than relying upon a lower layer (maybe you've 
> noticed that I don't care for that ;-).
> 

That seems established :) The point is that we don't need to mandate
that the peer go through the bootstrapping process, IF it happened to
know the identity by means outside the protocol. There's always the
choice that it gets it from the home server as part of bootstrapping, if
the lower layer cannot provide such information. 

Vidya

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