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