Re: [eap] Re-review of draft-ietf-hokey-erx-13.txt

[<Bernard_Aboba@hotmail.com>]

> Note that since the DSRK is only handed out as part of an EAP or
> ERP exchange in which the peer is involved, there is no question of a
> random local ER server receiving a DSRK and generating bogus accounting
> records.  

[BA] I'm going to post a message to the HOKEY WG list trying to provide
more detail so that we can discuss this whether there is a problem here,
and if so, why. 

> The domain name is communicated in an authenticated ERP
> bootstrapping exchange to the peer, so that the peer and the home AAA
> server have the same idea about the domain. 

[BA] Would the same security properties be provided in the EAP 
bootstrapping case?  

> This is a reference just saying that in cases like IEEE 802.1x, where
> the peer may send an EAPoL-Start message to start EAP, there is no need
> for the authenticator to wait to receive a response for ERP - when it
> receives the EAPoL-Start, it knows that the peer is interested in
> starting EAP.  

[BA] Sure.  But given the current state of ERP compatibility with IEEE 802,
the reference is confusing. 

> Also, ERP may be network initiated and so, while the
> peer-initiated mode does not work for 802.1x as written, the network
> initiated mode will work fine, as long as codes greater than 4 are
> allowed. 

[BA] The problem is that IEEE 802.1X (2001, at least) doesn't support
that. 

> We seem to have different directions on this - Jari seems to want to
> place MUSTs on lower layers, while you seem to not want that.  

[BA] I'm just asking what "break the connection" means, especially
for a connectionless link layer. 

> > [BA] Do you really mean that the authenticator is using the 
> > realm to determine the IP address of the ER server?  Or is 
> > the keyname-NAI field just copied into the User-Name 
> > attribute so that routing happens normally?  
> >  
>
> The latter. 

[BA] Can you clarify that in the document?

> > [BA] Since the local ER server does not determine whether it 
> > is on the path how is "path pinning" to be achieved? How does 
> > the AAA server know whether an ER server is on the path or not? 
> > What does it do if it is not on the path?  In other words, 
> > what does the MUST imply?  
> >  
> Deployments that wish to run ERP must place the local ER server in the
> path.  Those that do not cannot run this protocol in the local domain.
> So, there is no behavior to define when the server is not in the path. 

[BA] If the MUST doesn't imply anything in terms of behavior, can we
drop it? 

> This is part of the ERP exchange and hence, carried in a AAA attribute.
> The domain name is used to route the message just like any other regular
> AAA routed message.  

[BA] The issue is that AAA routing is typically not implemented on the
authenticator, only in the AAA infrastructure.   Is ERX requiring that the
authenticator implement a realm routing table?
 
> > [BA] Which "original NAI" are we talking about?  The NAI used 
> > in the EAP-Response/Identity in the original EAP 
> > conversation?  The NAI in the Peer-Id?  The NAI in the ERX 
> > conversation?
> >   
> The first one. 

[BA] Can you state that in the draft? 

> > [BA] Transport of the MSK is already specified in existing 
> > AAA documents, such as RFC 4072 (Diameter EAP).  Why is 
> > reference 12 being given here rather than those existing 
> > documents?  This document does not update those specifications. 
> >  
> Reference [12] is an example from the RADIUS side.  For Diameter, we do
> reuse RFC4072.  There still needs to be a document that describes
> encapsulation of ERP messages - that is what reference 15 does, for
> instance.

[BA] The problem is that reference [12] is not used by existing RADIUS/
EAP implementations, and the ERP document should not be updating
or obsoleting legacy EAP or RADIUS/EAP behavior. 

> > [BA] I think you mean "ERX" not "EAP re-authentication" or 
> > ERP, right? 
> > One thing that is left out here is authentication between the 
> > ERX local server and the ERX home server.  This exists if 
> > they are one hop apart, but otherwise not.  So I think there 
> > is an assumption that the ERX server is only willing to 
> > provide keys to domains that it is explicitly authorized to 
> > deal with. 
>
> The authorization text that I pointed out earlier covers this. 

[BA] OK.  I'll take a look at this. 

> I thought that the intent was clear, but, if you prefer this wording, we
> can change it as you suggest. 

[BA] I prefer the suggested text since RADIUS application layer security is
also being considered. 

> > [BA] The rest of the spec does not talk about use of the 
> > Peer-Id.  Since not all EAP method deriving keys have a 
> > Peer-Id, do you really want this mentioned here? 
> >  
> The peer-id is a remnant that should be deleted.  We will delete that in
> the next revision. 

[BA] Great. 
  
> This is a note to lower layers and is obviously not binding.  It is
> ultimately the lower layer that will define the authorization state. 

[BA] You might say that in the document.  

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