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

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

<snip>

> > 
> > The requesting entity might be a DSRK server.
> 
> What is a "DSRK server"?  Is it the same as a hokey server?  
> 

In my mind, that is practically the case.  I guess in theory, one could
say that the entity that holds the DSRK doesn't need to also be the
HOKEY server.  I can't make a practical case for that though. 

> > 
> >> 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
> > 
> > The DSRK server can provide its identity via the lower layer to the 
> > peer
> 
> One of the things that bothers me a lot about the proposals 
> we're seeing is the tendency to rely upon unspecified and 
> possibly non-existent "lower layer" mechanisms.  I think that 
> this is unnecessary.
> 

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.
Also, ERP bootstrapping is capable of providing this identity to the
peer - so, a lower layer capability here is not a MUST.  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.  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/>