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

["Glen Zorn" <[e-mail]>]

[e-mail] <mailto:[e-mail]> scribbled
on Wednesday, March 12, 2008 10:47 AM:

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

_______________________________________________
HOKEY mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/hokey