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.
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 .
[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  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
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?
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?
o In addition, the rMSK is sent along with the EAP-Finish/Re-auth
message, in a AAA attribute .
[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
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
To prevent such DoS attacks, an ERP failure should not result in
deletion of any authorization state established by a full EAP
[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).