Re: review of draft-ietf-ipsecme-eap-mutual

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dan,

Thanks for reviewing this document. Responding to your main point:

The need to correlate the client's EAP and IKE identity is not new to this protocol. It has to be done in exactly the same manner, for exactly the same reasons, in today's IKEv2. This is what IKEv2-bis says about it:

   When the initiator authentication uses EAP, it is possible that the
   contents of the IDi payload is used only for AAA routing purposes and
   selecting which EAP method to use.  This value may be different from
   the identity authenticated by the EAP method.  It is important that
   policy lookups and access control decisions use the actual
   authenticated identity.  Often the EAP server is implemented in a
   separate AAA server that communicates with the IKEv2 responder.  In
   this case, the authenticated identity, if different from that in the
   IDi payload, has to be sent from the AAA server to the IKEv2
   responder.

I don't see a reason to add a lengthy RFC 4301-analysis for a problem that already exists in the base protocol.

As to the equivalent problem for the server's identity, this is the "lying NAS" issue. I agree that it is not solved well today, and the draft says so quite clearly:

   This third, optional property of the method provides protection
   against certain types of attacks (see Section 6.2), and therefore in
   some scenarios, methods that allow for channel binding are to be
   preferred.  It is noted that at the time of writing, even when such
   capabilities are provided, they are not fully specified in an
   interoperable manner.

The last sentence of this paragraph says that we *do not* have a workable solution yet. Perhaps we should have worded it more strongly.

Please let me know if you still request additional clarifications in the draft.

Thanks,
	Yaron

On 05/27/2010 12:22 AM, Dan Harkins wrote:

   Hello,

   Here are some comments on this draft for IETF LC. There are some
editorial nits, some errors that might be considered editorial but
there is a serious issue with the Security Considerations that I think
needs addressing.

   I'll start with the security issue since it's the most serious (and
some may stop reading after getting to the editorial complaints).

   Issue in Security Considerations:

     In IKEv2 both sides present identities in the form of an ID payload.
     EAP also has an identity exchange that is not useful for authentication
     so EAP methods typically include their own, separate, identity
     exchange. In many cases that identity is in a protected channel from
     the EAP peer to the EAP server. When the EAP server is not co-located
     with the IKEv2 implementation (i.e. EAP is offloaded to a separate
     server) the identities that are actually authenticated are unknown
     and/or unverified.

     Section 6.2 mentions this from the client's point-of-view-- "after
     the client has verified the AUTH payload sent by the IKEv2 gateway,
     it knows that it is talking to SOME gateway trusted by the home AAA
     server, but not which one." This is used as a segue to the "lying
     NAS problem", which I have note below is not really solved so this
     problem isn't really addressed properly.

     But the problem is worse. The point-of-view of the gateway is never
     mentioned. The gateway may know some anonymous identity, or an
     identity that is colored or obfuscated that is useful only by the
     EAP server to determine which EAP method to offer. It does not know
     what the real client identity is. The identity that gets authenticated
     is unknown to the gateway!

     Unfortunately, it is the authenticated identity that the gateway must
     use to look up an entry in the IPsec Security Policy Datbase (see
     RFC 4301) that says what kind of security (bypass, drop, protect
     rules, etc) to apply to the client's packets. It is therefore not
     possible to properly support RFC 4301 when using this EAP-only
     method of authentication.

     Furthermore, the only identity available to the gateway can be
     forged so the client can achieve more favorable access to the
     protected network (a more "generous" security policy) than the
     gateway would have given it had it known its _real_ identity.

     I think there has to be a top-down analysis of RFC 4301 and how this
     scheme impacts it. Each part of RFC 4301 that cannot be supported
     or can only be supported in a limited manner must be spelled out and
     the impact of the lack, or limit, of support has to be presented in
     this draft's Security Considerations so a reader/implementer knows
     what he's getting into if he decides to implement this scheme.

     I would advise a DISCUSS on this draft until this has been worked out.

   Errors:

   - the draft states "IEEE 802.11i uses EAP without any PKI for
     authenticating the WLAN access points." That is just plain wrong.

     IEEE 802.11 is agnostic about particular EAP methods but requires
     they provide mutual authentication and key generation. The Wi-Fi
     Alliance certifies IEEE 802.11 implementations (and the EAP methods
     they use). Of the EAP methods certified for use in IEEE 802.11--
     EAP-TLS, EAP-TTLS w/MSCHAPv2, PEAPv0 w/MSCHAPv2, PEAPv1 w/GTC,
     and EAP-SIM-- only EAP-SIM does not require a PKI. Having been
     involved in that particular industry for most of the past decade
     I can assure the authors that PKIs of some sort are used in most
     every deployment of IEEE 802.11i. I have yet to see a pure EAP-SIM
     deployment anywhere.

   - in section 6.2 the draft mentions the "lying NAS problem" and says
     that "EAP methods that provide what is called 'connection binding'
     or 'channel binding' transport some identity or identities of the
     gateway (or WLAN access point/NAS)." The table in section 4 lists
     EAP methods that supposedly support "channel binding" but none of
     methods with a "yes" in that column do what section 6.2 says.

     The closest is EAP-SAKE (RFC 4763) which includes identities in a
     MIC but that won't solve the "lying NAS problem" and RFC 4763 even
     says, "EAP-SAKE does not claim channel binding" (so the table in
     section 4 is wrong). The others provide a protected channel but don't
     say how this can be used to actually solve the "lying NAS problem".
     The draft really needs to say that this problem has not been solved
     yet and remains an issue that must be taken into account if someone
     decides to implement this scheme.

   Editorial nits:

   - this draft really does not justify its existence well at all. I
     know the WG decided to pursue this work item but the reasoning
     around that decision does not come through in this draft.

     The introduction says that "[P]ublic key signatures and shared
     secrets are not flexible enough to meet the requirements of
     many deployment scenarios." OK, so there's some unnamed credential
     needed (probably a token card or some such). This is handled using
     the existing EAP support in IKEv2 so why is this scheme being defined?

     Then the draft mentions as justification that "deployment of a PKI
     is required" and "in many cases this is not realistic." If that's
     the case then why are EAP methods that require a PKI listed in
     the table of acceptable EAP methods for this technique?

     In section 2 the draft says "Offering EAP based authentication has
     the advantage that multiple different authentication and key
     exchange protocols are available with EAP with different security
     properties (such as strong password based protocols, protocols
     offering user identity confidentiality and many more)." OK, fine
     but all that is easily satisfied with the existing EAP support in
     IKEv2 so why is this scheme being defined?


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]