Subject: Re-review of draft-ietf-hokey-erx-13.txt

From: <[email-masked]>
Date: Wed, 12 Mar 2008 07:47:23 -0700

Re-Review of draft-ietf-hokey-erx-13.txt

I went through the draft again.  Note that these comments only reflect
my own review;  the author still needs to follow up with other reviewers. 

Here are some overall comments:

1.  I think you need to deal with the potential fraud issues in the
document.  This would involve describing the precautions that a AAA
server should take in authorizing domains to receive DSRKs, and 
validating subsequent accounting records. 

2. I think you need to specify the applicability of this specification.
I'm still somewhat uncertain about whether we're talking about
intra-media, inter-media, inter-domain (with some meaning of 
domain), etc.  Please clear this up. 

Some details:

   Note that this may introduce some delay in starting EAP.  In some
   lower layers, the delay can be minimized or even avoided by the peer
   initiating EAP by sending messages such as EAPoL-Start in the IEEE
   802.1X specification [10].

[BA] Since ERX is not compatible with IEEE 802.1X (whose state machine
doesn't support peer-initiated messages) I don't see how this is 
possible.  It might be better to omit the reference. 

   When the EAP-Request/Identity times out, the authenticator
   MUST NOT close connection if an ERP exchange is in progress or has
   already succeeded in establishing a reauthentication MSK.

[BA] What does "close connection" mean?  Is the document making
normative statements about link layers specified outside the IETF? 

   The authenticator uses the realm in the keyName-NAI [4] field to send
   the message to the appropriate ER server.

[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 local ER server SHALL request
   the home AAA server for the DSRK by sending the domain name in the
   AAA message that carries the EAP-Initiate/Reauth bootstrap message.
   The local ER server MUST be in the path from the peer to the home ER
   server.  If it is not, it cannot request the DSRK.

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

Also, how is the mapping from domain name to IP address
to be achieved?  Is this via an A/AAAA RR?  A SRV RR lookup? 

Section 4.3

   In case of ERP with the
   home ER server, the peer uses the realm from its original NAI; in
   case of a local ER server, the peer uses the domain name received at
   the lower layer or through a ERP bootstrapping exchange.

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

Section 5.1

   o  In addition, the rMSK is sent along with the EAP-Finish/Re-auth
      message, in a AAA attribute [12].

[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. 

Section 8

      Authenticate all parties

         The EAP Re-auth protocol provides mutual authentication of the
         peer and the server.  Both parties need to possess the keying
         material that resulted from a previous EAP exchange in order to
         successfully derive the required keys.  Also, both the EAP re-
         authentication Response and the EAP re-authentication
         Information messages are integrity protected so that the peer
         and the server can verify each other.  When the ERP exchange is
         executed with a local ER server, the peer and the local server
         mutually authenticate each other via that exchange in the same
         manner.  The peer and the authenticator authenticate each other
         in the secure association protocol executed by the lower layer
         just as in the case of a regular EAP exchange.

[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. 

         It is RECOMMENDED that the AAA protocol be protected using
         IPsec or TLS so that the keys are protected in transit.  Note
         however that keys may be exposed to AAA proxies along the way
         and compromise of any of those proxies may result in compromise
         of keys being transported through them.

[BA] I think you just want to say "It is RECOMMENDED that the AAA protocol
protect the keys in transit.  This can be accomplished via transmission
layer security (IPsec or TLS), or via an application-layer mechanism."

      Confidentiality of identity

         Deployments where privacy is a concern may find the use of
         rIKname-NAI to route ERP messages serves their privacy
         requirements.  Note that it is plausible to associate multiple
         runs of ERP messages since the rIKname is not changed as part
         of the ERP protocol.  There was no consensus for that
         requirement at the time of development of this specification.
         If the rIKname is not used and the Peer-ID is used instead, the
         ERP exchange will reveal the Peer-ID over the wire.

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

   To prevent such DoS attacks, an ERP failure should not result in
   deletion of any authorization state established by a full EAP
   exchange.  

[BA] Is this purely up to this specification to determine?  Typically
the lower layer defines the authorization state and how it is installed/removed.
This may not necessarily involve EAP (e.g. 802.11 4-way handshake).

---

From: <[email-masked]>
Date: Wed, 12 Mar 2008 14:36:32 -0700

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

>> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>