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

[<[e-mail]>]

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