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

From: "Dan Harkins" <[email-masked]>
Date: Wed, 26 May 2010 14:22:04 -0700 (PDT)

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?

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 May 2010 15:39:03 -0700

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

Can you say more about what you mean by "worked out"? More text in the Security Considerations? If so, at least an outline would be helpful. Or maybe you mean one or more changes to the protocol? If so, some specific suggestions would be helpful. Specifically, are you asking for this document to solve the lying NAS problem?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 26 May 2010 17:41:27 -0700 (PDT)

Hi Paul,

  What I said was:

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

That's really what's needed, an enumeration of the issues and impacts.
The gateway cannot learn the authenticated identity and therefore the
assumptions RFC 4301 is making about that identity (viz, that it be
authenticated) no longer apply. The client can't learn the authenticated
identity but it does know that the entity asserting the unauthenticated
identity is trusted in some capacity (it got the key after all) by the
server it just authenticated. I think the ramifications of all that has
to be stated in the Security Considerations and I'd expect it to not be
a perfunctory statement.

  I don't expect this draft to solve the "lying NAS" problem. But it
should not say it's solved by EAP methods with a "yes" in the table in
section 4. Such a statement is not true. It should say something to the
effect that "some EAP methods have the capability to pass blobs of data
and at some time in the future there may be a use of this capability to
solve the 'lying NAS' problem but until that time the following
considerations must be taken into account by people who implement this
scheme: blah blah blah." What is the impact of a client having this
transitively authenticated, but not really authenticated, identity of
the NAS even if the NAS is not lying? Does this impact change if
there's a human behind the "client" (who just wants network access)
or if it's a device protecting some of its own resources? The draft
doesn't say.

  Basically, the Security Consideration section doesn't take into
consideration the full impact on security that will be caused by
implementation of this protocol; it should.

  regards,

  Dan.

On Wed, May 26, 2010 3:39 pm, Paul Hoffman wrote:
> Can you say more about what you mean by "worked out"? More text in the
> Security Considerations? If so, at least an outline would be helpful. Or
> maybe you mean one or more changes to the protocol? If so, some specific
> suggestions would be helpful. Specifically, are you asking for this
> document to solve the lying NAS problem?
>
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 27 May 2010 23:43:37 +0300

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

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 28 May 2010 14:36:53 -0700 (PDT)

Hi Yaron,

  I see your point. IKEv2-bis completely punts the issue and so you
want to too. If that's your tact you might want to mention _how_ an
implementation is supposed to interoperate with a AAA server, like
an RFC that defines this behavior. If there is no RFC to define the
behavior you want to refer to then I think you (and IKEv2-bis!!!)
still have a problem. At the absolute minimum I'd at least like to see
some text that describes how to deal with this problem in the draft,
something along the lines of, "if you implement this scheme then,
in lieu of some external indication of the authenticated identity of
the client, the security policy and access control provided to the
client MUST be based that afforded by the lowest ordered entry in the
SPD (see RFC 4301)." That way the lowest common denominator rule will
apply to what is, effectively, an unknown entity.

  You also seem to be treating the authentication issues with gateway
identity identically. You treat the IKEv2-with-EAP case and the EAP-only
case as the "lying NAS" problem. But that isn't true. In the former the
client gets an authenticated identity. It _might_ be different than the
identity the gateway presents to the AAA server, and hence the "lying
NAS" issue, but it's an authenticated identity. In the EAP-only scheme
the identity is completely unauthenticated and can be anything the
gateway decides to make it. This becomes the "lying NAS" problem on
stilts. I'd be happy with text along the lines as that I supplied above
that talks about this problem but from the client point-of-view.

  Regarding "channel bindings". It's not just that this capability
hasn't been defined in an interoperable manner across the many EAP
methods with a "y" in that table. It hasn't been defined at all
anywhere! What your draft says is:

  "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) inside the EAP method. Then the
  AAA server can check that it is indeed sending the key to the gateway
  expected by the client."

And that just is not true. EAP methods that support "channel binding"
as indicated by the table do not transport anything anywhere. And
EAP-SAKE says it doesn't support channel bindings so you might want
to fix that table. The paragraph you quote says, "the method provides
protection against certain types of attacks" but it does no such thing.
All the method might provide is a way to negotiate an encryption and
integrity algorithm and that's a far cry from providing protection
against this specific attack.

  This draft has security issues. Some you don't mention because another
RFC that has the same issues doesn't mention anything, some you
conflate, and some you infer that the problem has been solved by some
other protocol capability when it hasn't. If the problems can't be solved
in this draft, or you think they shouldn't be solved here, then at least
say what those problems are so a casual reader or implementer knows what
he's getting into if he decides to implement this.

  regards,

  Dan.