Subject: The remaining IKEv2 issues

From: "Theodore Ts'o" <[email-masked]>
Date: Mon, 18 Aug 2003 13:18:33 -0400

Last week on August 12, Angelos posted a status of the remaining issues
reamining open on the IKEv2 document at the end of wg last call, and
thos that were closed as of the -09 document.  The only comments made to
Angelos' issues were some editorial nits raised by Abraham Shacham,
which were recorded in the issue tracker as issue #66.

Of the remaining issues left open per Angelos' message of August 12:

 1: (Rekeyed SA use)
 7: (Fragmentation negotiation (before/after IPsec processing)
 10: (NAT Traversal support)
 16: (Negotiate ToS in IKEv2)
 41: (NAT traversal missing text)
 55: (ICMP fields as selectors ?)
 64: (Use the SPI of SA being rekeyed in a notify payload during rekey)
 65: (EAP)

Issues 1, 10, 41, 55, and 64 were actually addressed in the -09, but had
not been marked as closed.

Of the remaining three issues:

 7: (Fragmentation negotiation (before/after IPsec processing)
 16: (Negotiate ToS in IKEv2)
 65: (EAP)

There does not seem to be consensus for issue #7, and this is something
which can be added later as an extension to IKE if and when there is
consensus.  Nor does it seem that the lack the ability to do red side
fragmentation (and the ability to forbid black side fragmentation) to be
a fundemental lack in the IKEv2 specification.  (Indeed, it has been
pointed out that the transmitter can not guarantee that other gateways
might fragmented encrypted packets, and that this situation might change
dynamically as routing changes.)

Issue #16 is something which has yet to be discussed as part of the RFC
2401-bis discussion.  As we discussed earlier, if we came to consensus
before this document exited IETF last call, subject to AD approval, we
could add the necessary text to support TOS selectors to the IKE
specification.  (The IKEv2 specification has a dependency on RFC
2401-bis, so it can't be published by the RFC editor until we finish RFC
2401-bis anyway.)  Alternatively, if we do not come to consensus,
support for TOS selectors can be added in a subsequent document easily
enough.

The final issue #65, concerns whether or not non key-generating EAP
methods should be supported, in order to avoid a Man-in-the-middle
attack (MITM) attack.  However, as Charlie has pointed out, as used in
IKEv2, the server is authenticated with a certificate before the
authentication code is passed.  In addition, given the requirement to
support one-time password and Generic Token cards, we can not forbid the
use of non-kg EAP schemes.  Hence, given that the MITM attack which was
the concern raised by issue #65 is not an issue for IKEv2, we believe
that this is not something that should hold back the publication of
IKEv2 as a Proposed Standard.

Charlie has just put out the -10 version of the IKEv2 document, which
addresses the editorial nits which were raised by Abraham Shacham and
others after -09 was released.  With these issues closed (or as closed
as they are going to be), we believe that the -10 version is ready for
IETF last call, once it the -10 version has been processed by the IETF
secretariat.

					- Ted and Barbara

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 18 Aug 2003 16:23:43 -0400

I must have missed the resolution on issue 64, can someone remind me of 
the resolution
and rationale?

Thanks,
Jeff

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Aug 2003 17:04:36 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Theodore" == Theodore Ts'o <[email-masked]> writes:
    Theodore> The final issue #65, concerns whether or not non key-generating
    Theodore> EAP methods should be supported, in order to avoid a
    Theodore> Man-in-the-middle attack (MITM) attack.  However, as Charlie
    Theodore> has pointed out, as used in IKEv2, the server is authenticated
    Theodore> with a certificate before the authentication code is passed.

  My understanding of the MITM attack on non key-generating EAP methods is
that nothing we do in IKEv2 prevents this. This is because the attack is
not between two IPsec devices, but between different kinds of devices.

  I.e. you do key-less EAP with a web server as part of HTTPS, and the
*web server* then does key-less EAP IKE2, acting a kind of nefarious
algorithm proxy.

  We demand that each end know the generated EAP key so that we can bind the
key to the authenticator used. The above web server wouldn't know the
generated key, so the attack is defeated.

    Theodore> In addition, given the requirement to support one-time password
    Theodore> and Generic Token cards, we can not forbid the use of non-kg
    Theodore> EAP schemes.  Hence, given that the MITM attack which was the
    Theodore> concern raised by issue #65 is not an issue for IKEv2, we
    Theodore> believe that this is not something that should hold back the
    Theodore> publication of IKEv2 as a Proposed Standard.

  So, the only way to support these kind of things is by using EAP?
  I'm not complaining, I'm just asking for confirmation.

    Theodore> closed (or as closed as they are going to be), we believe that
    Theodore> the -10 version is ready for IETF last call, once it the -10
    Theodore> version has been processed by the IETF secretariat.

  wow.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: Uri Blumenthal <[email-masked]>
Date: Mon, 18 Aug 2003 18:01:04 -0400

> My understanding of the MITM attack on non key-generating EAP
> methods is that nothing we do in IKEv2 prevents this. This is
> because the attack is not between two IPsec devices, but between
> different kinds of devices...

I concur.

> We demand that each end know the generated EAP key so that we can
> bind the key to the authenticator used. The above web server
> wouldn't know the generated key, so the attack is defeated.

I strongly believe that non key-generating methods must not
be allowed, period. Regarding "special auth" methods - see
below.

>     Theodore> EAP schemes....
>

Probably - but these methods don't have to be non-kg. They
may contribute, even though not much - to the kg procedure.

Why not?

---

From: "Theodore Ts'o" <[email-masked]>
Date: Mon, 18 Aug 2003 23:23:06 -0400

> not between two IPsec devices, but between different kinds of devices.

OK, my bad.  I didn't recognize issue #65 as being related to the
desire to thwart the tunnel/protocol composition problem, as
documented Asokan, Niemi, and Nyberg:

	http://eprint.iacr.org/2002/163.pdf

I'm embarassed didn't make the connection from going over the mail
messages and the issue tracker.  I suppose I can take some small
comfort (but only a little) in that Charlie and Angelos didn't notice
it either when we discussed things last week.  Thanks for bringing
that to our attention.

OK, so, how do we resolve this?

It's certainly true that in the general case, the EAP tunnelling
attack can be a real problem.  And if only to make ourselves feel
better about not leaving behind what might considered an attractive
nuisance, perhaps we should mark it as a MUST NOT.  With my working
group chair hat off and my security hat on, I think I would have to
agree with that sentiment.

On the other hand, in order to be realistic, we should at least take a
moment to recognize that there is going to be a very strong market
demand for this support, given the assumption by many corporations
that everything behind the firewire is goodness and light and is fully
secure.  In those environments, if the only use of EAP outside of the
firewall is in protected tunnels (such as IKEv2) used to gain access
to the protected intravent via a VPN solution, then this is in fact no
worse than making the original assumption that everything behind the
firewall is safe.  (After all, if the attacker has access to
unprotected EAP transactions happening behind the firewall, then s/he
has no need to try to use this to break a VPN solution trying to gain
access behind the firewall.)

Of course, this is a very silly, stupid assumption, and with my
security directorate hat on, I deplore it as being bad and horrible
and everyone who does this sort of thing ought to be ashamed of
themselves.  Tsk, tsk, tsk.  Taking that hat off for a moment, though,
I can think of a very large number of companies (including cough,
cough, my current employer, and probably many other complanies who
employ members of this working group), who make precisely this
assumption regarding firewalls and the relative security inside
vs. outside the firewall, and who make use of VPN solutions today.

Hence, I suspect that even if we were to very strongly forbid the use
of non-kg EAP mechanisms, the market pressure for vendors to implement
them for in VPN solutions, for applications such as SecureID and even
simple username/password passed to a Radius server (where more
advanced forms of CHAP-like authentication schemese are not an option
thanks to the customer's antiquated legacy infrastructure), will be
very strong indeed.  Of course, with all of this being said, we still
don't necessary have to condone this outcome (even if some of our
employers will either be building, buying, or deploying such
solutions).

So given this, I propose that we open a 48-hour discussion on this
issue.  Should we (a) say nothing about non-kg types, thus implicitly
allowing them, (b) specify that vendors SHOULD NOT use non-kg EAP
types, or (c) specify that vendors MUST NOT use non-kg EAP types?

Arguments in favor include the originally stated requirement that we
support legacy password authentication schemes; arguments against are
that given some operating environments, there may be an EAP tunnelling
attack, which we shouldn't encourage.  And then of course there's the
pragmatic observation that no matter whether we say MUST NOT or not,
it may in the end have little effect on what VPN vendors actually
choose to ship.

Have I missed any of the arguments either against or for?  If so,
please speak up, but otherwise, let's just take a straw poll and then
just decide this one way or another.

					- Ted

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Aug 2003 21:59:55 -0700

For challenge/response token EAPs one could define a challenge based on
some derivative of the key exchange.  Thus the client could verify that
the challenge corresponds to the KE and the server could verify that the
response corresponds to the challenge and if both check out then the KE
is authenticated.

Obviously NOT a general solution for non-kg EAPs and probably not very
strong either, but for at least one class of non-kg EAPs it is a
possible solution.

I have an ulterior motive for proposing such a thing - see my post today
with subject "IKEv2 SA rekeying - naming an initial SA."

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 18 Aug 2003 22:29:31 -0700

> OK, so, how do we resolve this?
[...]
> it may in the end have little effect on what VPN vendors actually

IMO, any non-kg EAPs that also cannot somehow be bound to the IKE_SA KE
should not be allowed ("MUST NOT"), but in a pinch (i.e., no consensus)
"SHOULD NOT," accompanied by LOUD warnings of dire, dire consequences
could do.

> just decide this one way or another.

Well, I have a use for "anonymous IPsec," that is, unauthenticated IKE
key exchanges.  Anonymous KEs can be rather useful, at least if we
define a "session ID" like SSHv2's[*], then we can bind authentication
at higher network layers (e.g., Secure NFS) to anonymous IPsec
"sessions," thus proving that there is no MITM.

Of course, this is not a solution to the non-kg EAP problem, though it
is related to the solution I offered for [some] challenge/response EAPs.

[*]  Derived from, and thus bound to DH and other KE material of an
initial IKE_SA, and which remains unchanged through subsequent re-keys.

Cheers,

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Tue, 19 Aug 2003 10:23:06 +0300

As many times as I read that article, I can't see how this is a 
problem.  It makes a very strong assumption, that EAP methods are used 
outside of secure tunnels.  IMO this is not true:

- The easiest case is the user/password.  This could be handled using 
EAP-MD5 or EAP-GTC.  In an average company, the user/password 
combination is used to log in to your workstation, to log in to 
servers, or to connect from home or while on the road.  You do not use 
it from home to do things that are not related to IKE.  When at work, 
you log on to the Windows domain controller or to some RADIUS server, 
but you do not use EAP.  The only cases where you actually use EAP is 
when connecting to a wireless LAN equipped with 802.1x or when 
connecting to a relatively new RAS.  These RAS usually also use 
L2TP/IPsec, so that's not snoopable either.  In short, I don't see the 
case where the user will pass their password through unprotected GTC.  
Since both GTC and MD5 are not good protection for passwords, it is up 
to the administrator to prevent these methods from being used in 
unprotected tunnels.

- Another case is the one-time password.  Here, the danger is real, 
although the user will notice that the authentication failed.

- An other case is the SecurID.  This will be done either by GTC or by 
SecurID's own EAP methods.  Both are non-kg.  Again I have to ask, why 
would anyone do GTC in an open channel?  You authenticate either inside 
your corporate network, or else at home for IPsec.  The case of a 
university where a lot of students have access to the network simply 
says that you should use IPsec or at least some kind of tunneled EAP 
such as PEAP or TTLS.  The administrator should not allow users to use 
non-kg methods outside tunnels.

To sum it up, I believe that it should be left to administrators to use 
EAP methods appropriately, i.e. not use the same non-kg method both in 
tunnels and in the clear.  That responsibility should not fall on IKE 
implementors.  They SHOULD, however, warn their customers about the 
dangers.

On Tuesday, August 19, 2003, at 06:23 AM, Theodore Ts'o wrote:
<snip>

---

From: Tylor Allison <[email-masked]>
Date: Tue, 19 Aug 2003 08:17:42 -0500 (CDT)

So the MITM attack on non-kg methods is possible for EAP messages being
transmitted outside of IKEv2 (e.g. not between IPsec peers), and occurs
because either the EAP messages are being passed in the clear, or the
server in a protected EAP protocol (e.g. PEAP) is not being authenticated
properly.

Why not make doing this a MUST NOT?  Aren't there many ways to make non-kg
EAP methods protected from MITM?  How about:

    o   Securing the EAP with another protocol (PEAP, others).

    o   Securing the network that the auth server is on (e.g. dedicated
        network for the server)

    o   Having IKEv2 peers consume the EAP messages directly ... e.g for
        small scale deployments, the IKEv2 firewall could locally manage a
        small set of user/passwords.

        Another example is that the firewall consumes the EAP messages and
        translates to other (proprietary) security protocols to communicate
        to the authentication servers.

Unless I'm misunderstanding the vulnerability, I think any of these may be
viable, and, as Ted points out, many IKEv2 vendors may be forced to provide
one or more of these solutions to customers with existing legacy auth servers.

My vote... I'm not sure I like the choices.  I would like to see a warning
in the draft regarding the use of EAP outside of IKEv2 (transmissions to
auth server), stating that this transmission needs to be secured.  But
perhaps that should be obvious to implementors and isn't needed?  I don't
want either of the "SHOULD NOT" or "MUST NOT" options.  I think there's
valid reasons why these legacy auth methods need to be supported, and there
are ways to make them secure.

Regards,

Tylor Allison

---

From: Yoav Nir <[email-masked]>
Date: Tue, 19 Aug 2003 17:17:27 +0300

Hi Tylor,

The reason we can't make doing this a MUST NOT is that the IKEv2 
document is designed to be used by implementors, not administrators and 
definitely not users.  We can say "GTC is OK" or "MUST NOT use GTC".  
We can even say "GTC MUST NOT be used unless the passwords are local to 
the VPN endpoint".  We can't mandate user behavior like "you can't use 
the GTC server for IKE if you can also do GTC over unencrypted PPTP or 
over unauthenticated PEAP".  We can definitely not say "you should only 
authenticate with GTC if you verify the server's certificate correctly 
in PEAP"

In short, you can mandate things about IKE, but not about other users 
of the legacy authentication.  It would be up to the implementor to 
tell the user not to use insecure methods, perhaps by displaying a 
warning message in the GUI.  For the RFC, it's either in or out.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Aug 2003 10:58:08 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Theodore" == Theodore Ts'o <[email-masked]> writes:
    Theodore> OK, so, how do we resolve this?

    Theodore> On the other hand, in order to be realistic, we should at least
    Theodore> take a moment to recognize that there is going to be a very
    Theodore> strong market demand for this support, given the assumption by
    Theodore> many corporations that everything behind the firewire is
    Theodore> goodness and light and is fully secure.  In those environments,

  One simple answer is that we do not accept non-kg EAP as the way to do
X9.9/SecureID/token based authentication. We accept do, instead XAUTH or
something.

  {I say all of this, still prefering SMB's original proposal...}

  If we accept non-kg EAP methods, then we must make a strong statement to
the effect that the credentials MUST not be used to authenticate to parties
of differing trust. 
  I.e. maybe it is okay for the corporate "extranet" web server to use the
employees EAP credentials to form an IPsec tunnel to the employee's desktop
to retrieve that file. It just isn't okay for company A's web server to
use credentials from company B for things they weren't intended for. (noting
that B's web server must already have some radius-like relationship with A's
authentication server in order to perform the legitimate authentication)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Aug 2003 11:18:33 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
    Nicolas> For challenge/response token EAPs one could define a challenge
    Nicolas> based on some derivative of the key exchange.  Thus the client
    Nicolas> could verify that the challenge corresponds to the KE and the
    Nicolas> server could verify that the response corresponds to the
    Nicolas> challenge and if both check out then the KE is authenticated.

  There is a key thing that you should realize: in general, the responder
(aka "gateway") won't be able to derive the appropriate response itself.

     i.e. we can't do something like CHAP.

  The reason is that the gateway will likely have to provide the literal
reply via EAP/Radius to another machine for checking.

  I'm not certain what systems your proposal would work for.
  Not SecureID, not X9.9, not passwords-over-radius.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Aug 2003 10:31:18 -0700

>   Not SecureID, not X9.9, not passwords-over-radius.

The challenge function would have to be modified in those systems - it's
not applicable only at the responder.  This means that the responder
would have to be able to pass the "session ID" to the token system that
generates the challenge, so not only would existing systems have to
change, existing interfaces would have to change.  And initators would
have to be able to verify that the challenge is derived from or bound to
the "session ID."  Large changes indeed.

That's why I said "[some]" in one post - I couldn't say that this
applies easily to any one challenge/response token system, not with any
useful degree of certainty.

(I did have a challenge/response system like SafeWord's in mind though.)

The situation could change in the future though (that is, implementors
could follow the spec in this case, rather than the spec follow the
implementors).

I did also own up to my ulterior motive for offering this :)

Cheers,

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Aug 2003 14:03:54 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:
    Yoav> As many times as I read that article, I can't see how this is a
    Yoav> problem.  It makes a very strong assumption, that EAP methods are
    Yoav> used outside of secure tunnels.  IMO this is not true:

  Sure it is, because the problem is not just with non-private uses, but
with the end points as well.

  The point of having that radius-backed token system is that you are using
it for multiple system. The extranet web site would apply. Your assumption
is that every system that is authenticating users is equally trusted.

  You are assuming that the end point of the "secure tunnels" are trusted.
That is, if you are using EAP to authenticate to your "extranet" as well
as your IPsec, then a compromise of *either* system will compromise both
if you are using non-kg EAP.

  This is worse if you have some kind of non-kg EAP system that has multiple
mutually distrusting parties involved. I can easily imagine roaming dialup
ISP stuff, which is all based upon radius proxy that would be involved.

    Yoav> servers, or to connect from home or while on the road.  You do not
    Yoav> use it from home to do things that are not related to IKE.  When at

  Might be true for username/password, but it isn't true about physical
tokens, which are expensive, and the point of "legacy auth" is that people
want to amortize that token across more uses.

    Yoav> work, you log on to the Windows domain controller or to some RADIUS
    Yoav> server, but you do not use EAP.  The only cases where you actually

  How do you know that the domain controller isn't using EAP?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Aug 2003 16:11:19 -0400

-----BEGIN PGP SIGNED MESSAGE-----

    >> I'm not certain what systems your proposal would work for.  Not
    >> SecureID, not X9.9, not passwords-over-radius.

    Nicolas> The challenge function would have to be modified in those
    Nicolas> systems - it's not applicable only at the responder.  This means

  I wish it were that simple, but the tokens and servers are out of our
control.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Aug 2003 23:07:00 +0300

I'd like to turn your attention to a document we are
developing in the EAP WG. "The Compound Authentication Binding
Problem" discusses the MITM problem which affects IKEv2 as
well as a number of other protocols such as PIC, PEAP, or
even HTTP Digest inside TLS. The document includes alternative
solutions and a discussion of their properties. It may be useful
reading in terms of the the IKEv2 EAP MITM discussion. The
document is work in progress; the authors feel that its more
or less done, but it has not been very widely reviewed. So,
we'd be very happy if some members of this WG could review the
document, particularly in the context of IKEv2. Here's the URL:

   http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt

Thanks,

Jari Arkko
(Co-chair of the EAP WG)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Aug 2003 17:45:11 -0400

-----BEGIN PGP SIGNED MESSAGE-----

Matt, go back a couple of messages.

http://www.sandelman.ca/ipsec/2003/08/msg00077.html

and:
http://www.sandelman.ca/ipsec/2003/05/msg00003.html

specifically: 

http://www.sandelman.ca/ipsec/2003/05/msg00074.html

I can't find the scenario that was proposed. I think it is in the
original paper?

---

From: Michael Thomas <[email-masked]>
Date: Tue, 19 Aug 2003 14:19:44 -0700 (PDT)

Sorry if I've lamely missed this, but can somebody
in a nutshell describe the attack here? I'm not
quite groking what's being discussed here...

	      Mike

Michael Richardson writes:
 > -----BEGIN PGP SIGNATURE-----
 > Version: GnuPG v1.2.2 (GNU/Linux)
 > Comment: Finger me for keys - custom hacks make this fully PGP2 compat
 > 
 > iQCVAwUBP0JmiIqHRg3pndX9AQGBQAQAmwheLXX1W73QKMuV448vhTdeDkEqUHD2
 > u1TzXFYpvGA0blfoAB6aNVnQuqJcm5V5ZKSYJjb1hxM4NIlAoaePTvRAXz8Kb2GD
 > ncYT6vMLqDPK6q1gFX0L7iwKC5hCQjbiKcQvnhxVe4GBCHUQMNqM8dlwGRaXLAcg
 > tGWGjCuW9Ys=
 > =3twK
 > -----END PGP SIGNATURE-----

---

From: Jari Arkko <[email-masked]>
Date: Wed, 20 Aug 2003 02:18:30 +0300

Yoav Nir wrote:
> combination is used to log in to your workstation, to log in to servers, 
> or to connect from home or while on the road.  You do not use it from 
> home to do things that are not related to IKE.  When at work, you log on 
> to the Windows domain controller or to some RADIUS server, but you do 
> not use EAP.  The only cases where you actually use EAP is when 
> connecting to a wireless LAN equipped with 802.1x or when connecting to 
> a relatively new RAS.  These RAS usually also use L2TP/IPsec, so that's 
> not snoopable either.  In short, I don't see the case where the user 

1) Its snoopable/mitmable from the client to the RAS. Sure, it may
not be an IP network, but nevertheless...

2) Its snoopable/mitmable in the wireless LAN. New wireless LAN
standards require kg methods, but I'm not sure if this holds true
of all previous standards and products.

> will pass their password through unprotected GTC.  Since both GTC and 

3) If the <whatever> box that runs EAP talks RADIUS, it is not
certain that the RADIUS communication is encrypted. For PAP/CHAP
there's a lame encryption scheme, but for EAP there isn't since
EAP methods are expected to be secure by themselves. A recent
update of the RADIUS RFCs upgraded IPsec support to a SHOULD,
but common industry practise appears to be (like it or not)
that the lame scheme is enough.

> MD5 are not good protection for passwords, it is up to the administrator 
> to prevent these methods from being used in unprotected tunnels.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 20 Aug 2003 02:09:35 +0300

> access behind the firewall.)

I'm not sure compound authentication has the same kind of situation
as the protected "hard outside, soft inside" intranets have.

If the inside was safe, why would there be authentication?
I'd say its very likely that the same credentials are primarily
used for coming in to the intranet from the outside, using dial-in
or something like that. Or used for on-site WLAN access using
802.1X. Either way, its possible to that outsiders can see the
authentication message sequence, or act as MITMs and grab the
packets somewhere else.

> types, or (c) specify that vendors MUST NOT use non-kg EAP types?

I'd prefer very much (c), but can live with (b).

I think (c) is the best match to IKEv2's secure design.
We know the MITM problem exists, and we know how to avoid
it. According to the Bernard's method and RADIUS server
information, we don't appear to have to suffer too much
from choosing the secure approach...

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 20 Aug 2003 01:40:42 +0300

A few days before this thread on the mailing list, we had an
off-line discussion about the IKEv2 problem with Charlie, Bernard
Aboba, and myself. I thought I'd summarize what was said in
that discussion:

* The primary discussion is whether the non-kg methods should
   be allowed. See NON-KG METHODS below.

   We did not come to a specific conclusion in this discussion,
   but Bernard and myself felt that non-kg methods should not
   be allowed, kg variants of "legacy" methods exist and that
   sufficient support already exists in common RADIUS servers
   etc so that there's no real reason to support non-kg methods.

   We also felt that the primary requirement for support of legacy
   is to avoid redistributing new credentials for users. This can be
   avoided, new kg methods can use old non-kg credentials.

   Charlie felt that it is more important to ensure support
   for legacy authentication infrastructure, and in his opinion
   this is more widespread than what we believed.

   It seems that the primary disagreement is about the
   extent legacy authentication infrastructure really
   exists vs. the threat posed by the MITM attacks.

* A related issue is what exactly is the IKEv2 requirement
   for "username and password" authentication, and whether
   the currently planned use of such authentication is
   proper for EAP. See USERNAME AND PASSWORD AUTH below.

   This partly a debate of what requirements there are for
   EAP methods, and how existing methods satisfy those
   requirements.

   Bernard argues that EAP should not be used for cleartext
   passwords, and that EAP OTP or GTC should not be used in
   this manner. One of the problems with this is that if a
   RADIUS backend were to be used, the passwords might be
   exposed since common RADIUS implementations may not use
   encryption for sending the messages to the server. (Recently
   approved RFC 2869bis upgrades IPsec support in RADIUS
   to a SHOULD, but its still not a MUST.)

   Charlie argues that the requirement is a username/password
   authentication, in its simple form. He felt that if this
   can't be done in EAP, it needs to be added to IKEv2
   explicitly.

* In addition, the IKEv2 document currently disagrees with the
   way the EAP keying framework wants EAP keys to be used,
   when a key-generating method is used. See KEY USAGE below.

   The problem is that the EAP keying framework specifies
   a key hierarchy, and link layers (or IKEv2) are expected
   to use a specific part in this key hierarchy. Currently,
   this is unspecified in IKEv2-10. Specifying it appears easy,
   and this should be done.

Charlie, Bernard, feel free to correct/comment where necessary...

NON-KG METHODS
==============

Jari: We'd like to suggeste that only allow key generating
methods be allowed. Such variants of currently existing non-kg
methods are available, we think, for most or all practically available
methods without requring a change to the already deployed
credentials).

Charlie: I don't believe it is a good idea. Perhaps you can
convince me otherwise. I don't want to rule out EAP methods
because EAP was explicitly added to support current and future
"legacy" authentication methods. I would hate to see yet another method added
to support methods we aren't allowed to use with EAP.

Bernard:  While RFC 2284 did include definition of "legacy" methods such as
MD5-Challenge, OTP, and Generic Token Card, most of the methods created
since then have been considerably more advanced, and most cannot be
classified as "legacy."  In fact, there is even an EAP-IKEv2 method being
proposed!  So overall I don't believe that the above characterization
correclty describes today's uses of EAP.

In practice, EAP today is largely focused on meeting the needs of
wireless authentication such as IEEE 802.11, which does not permit use of
"legacy" methods, and the general trend is toward phasing out these
methods.  In fact, I'd go so far as to say that there is no RADIUS server
supporting EAP today that doesn't support at least some "non-legacy"
methods, since that is required for 802.11 compatibility which is a
practical necessity for most implementations.

Token card vendors such as RSA now provide key-deriving EAP
methods for their token cards.  The bottom line is that the need for
"legacy" methods is decreasing and there is no reason to require their
support any more.

Charlie: I think you're missing my point. EAP is expanding in some very
positive ways. EAP with non-key-generating methods produces dramatically
poorer security than EAP with key-generating methods, particular in the
context of IKE. But the reason EAP was integrated into IKEv2 was not for
any of those reasons. It was because IKEv2 had to support "username/password"
authentication for backwards compatibility with deployed authentication
infrastructures in spite of the fact that the security was going to suck.
And some wise person said: "Rather than just supporting username/password,
why don't you support EAP. That way, you get username/password when you have
to and can migrate to better methods when people roll them out without
updating the spec (though they will still have to update their implementations).
It's a little extra work in the spec now to save us a lot later. But I don't
think we can then turn around and tell them that they can't do
username/password authentication. Even though it's not very secure.

USERNAME AND PASSWORD AUTH
===========================

Charlie: I am disappointed that
EAP does not include simple user name and password, but am reassured that
people assure me that you can do it by telling EAP it's a one time password.

I don't believe it's cryptographically possible to do better than EAP in IKEv2
does if you assume the user has a password and the server holds a non-password
equivalent and doesn't either infringe a patent or require periodic reset
(as with OTP). I believe this case is important. Tell me how I'm wrong.

Bernard: I think you're thinking about PPP authentication algorithms,
not EAP.

There are at least four EAP methods defined that fall into this category,
including EAP MD5-Challenge (CHAP equivalent) and EAP LEAP, and two
MS-CHAP variants, both of which do mutual authentication.  There has also
been an EAP SRP proposal that has been worked on off-and-on over the
years. So I'm not clear what is missing.

In practice, most modern RADIUS servers are not limited to a single
non-password equivalent, since they are typically capable of interacting
with an LDAP backend which can either store the password in encrypted
form, or has an extensible schema capable of handling multiple
non-password equivalent forms.  For example, with EAP SRP it is necessary
to store several additional parameters such as the generator and this is
not an issue.

In any case, even where a non-password equivalent is used, it is still
possible to do mutual authentication and key derivation as is done in EAP
LEAP and MS-CHAPv2.

Similarly, token card vendors such as RSA now provide key-deriving EAP
methods for their token cards.  The bottom line is that the need for
"legacy" methods is decreasing and there is no reason to require their
support any more.

Bernard: EAP does not include support for cleartext passwords, by
design.  EAP OTP is not for use with cleartext passwords.

 > I don't believe it's cryptographically possible to do better than EAP in
 > IKEv2 does if you assume the user has a password and the server holds a
 > non-password equivalent and doesn't either infringe a patent or require
 > periodic reset (as with OTP). I believe this case is important. Tell me
 > how I'm wrong.

There is no EAP password-based authentication method that fits these
assumptions. MD5-Challenge requires the server to hold the cleartext password.
MS-CHAPv2 requires the server to hold a non-password equivalent, but does
mutual authentication and generates a key.

Charlie: Oh dear. It's possible that we've added EAP to IKE to support
a case that EAP can't support.

My reading of the spec (and I think I recall someone confirming it, though
I don't remember who) was that a client that implemented authentication
types (5) or (6) would display a server provided string to the user and
then forward whatever the user typed to the server. If true, then a server
could use either of these mechanisms to implement simple username
and password authentication. It would be wrong, and out of the spirit
of EAP, but it would work and people do it today. I didn't explicitly say
so in the spec because it seemed politically incorrect, but that's what
I expected people to do.

I would be wrong about this if either of these mechanisms required
mechanism specific processing in the client - like changing the
wordy form of an OTP into the condensed form. But it didn't look
like that was expected.

If this isn't going to work, we need to know right away because people
are counting on having a username/password authentication
mechanism and if you can't do it with EAP we will have to add it
explicitly.

Jari: What exactly is the requirement? To support username/password
authentication? We got that in the form of EAP MSCHAPv2, for
instance. But it does more than you've been assuming so far,
i.e. it also generates keys which would enable you to avoid
the MitM attack.

Or is the requirement to support token cards? As was mentioned
by Bernard, there are EAP methods to support them as well.

Bernard: You wrote:

 > My reading of the spec (and I think I recall someone confirming it, though
 > I don't remember who) was that a client that implemented authentication
 > types (5) or (6) would display a server provided string to the user and
 > then forward whatever the user typed to the server.

This much is true.

 > If true, then a server
 > could use either of these mechanisms to implement simple username
 > and password authentication.

This is not true.  A compliant EAP-OTP or GTC implementation cannot be
used to implement cleartext passwords.  Since this apparently not
clear to some implementors, we may have to add a MUST NOT to RFC
2284bis to make sure this doesn't happen. This would be a bad idea for
several reasons:

a. EAP is used on wireless media where cleartext passwords would allow an
attacker to capture the password.

b. In the case of RADIUS, whereas PAP passwords are hidden via a (lame)
attribute-hiding scheme, in the case of EAP methods [RFC3579] does not
mandate any encryption, although IPsec is a SHOULD. This means that the
cleartext password would be exposed over the Internet as well.

So even of IKEv2 were to address problem a), it would not address problem
b) -- and would violate the IETF prohibition on use of cleartext
passwords.

 > It would be wrong, and out of the spirit
 > of EAP, but it would work and people do it today.

We did an implementation survey two years ago, and were not aware of any
such usage.  In fact, to date I'm only aware of a single implementation of
EAP OTP, and none of EAP GTC.

For OTP there is certainly processing expected on the server -- and any
server that used it as a cleartext password mechanism would be violating
the spec.  GTC is designed to be "generic" -- usable by any
challenge/response mechanism, but for that reason it's never been entirely
clear why it was needed.  If this opens a huge hole for abuse, then maybe
we should deprecate it.

If the goal is to introduce PAP into EAP (something we went to great pains
to avoid), then it isn't going to work, either in EAP or in RADIUS on the
backend either.

Bernard:  It's very hard to argue that support of PAP is a requirement
because RFC 2865 supported CHAP as well as does every RADIUS server I've
ever seen, and MD5-Challenge is mandatory-to-implement in RFC 2284.

If you buy the idea that all legacy RADIUS servers support CHAP or
MD5-Challenge, then this implies that those same servers have access to
cleartext passwords and could be upgraded to support RADIUS/EAP with a
variety of methods.  All the commercial RADIUS servers and several of the
free ones support MS-CHAPv2 in some form, or other password based methods
offering mutual auth and key derivation (Interlink even supports EAP
SKEME).

KEY USAGE
=========

Bernard wrote: For key generating methods, the IKEv2 specification uses
the "key" generated by EAP methods in a manner that is prohibited by the EAP Key
framework.

EAP methods generate two quantities, the MSK (64 octets) and the EMSK (64
octets).  These quantities are used to compute the AAA-Key.  In situations
not involving fast handoff, the MSK is used as the AAA-Key, and the EMSK
is unavailable to the VPN server.  So the specification needs to call out
what particular portion of the "key" is being used.

Also, counter to the IKEv2 specification, the AAA-Key is never used
directly to protect data.  Rather, a PRF expansion is done to generate
authentication and encryption keys which are then used directly.

Please see the following document for details:

http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-07.txt

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 20 Aug 2003 02:37:03 +0300

> quite groking what's being discussed here...

The problem is any type of compound authentication, where
there's one outer and one inner authentication that are not
tied together cryptographically. This problem was first found for
an IETF protocol called PIC, which tried to use EAP to
generate certs for IKE. But it applies to any compound
authentication, such as TLS + HTTP Digest, EAP within EAP,
etc. The "kg EAP method" comes from the ability of newer
EAP authentication methods to produce keys, and the
keys enable you to make the cryptographic binding.

Here's the attack: Lets assume you have the FOO method
to authenticate, a perfect method in all respects. Then
you have the BAR protocol which has the capability to
use FOO inside itself. BAR is also perfect.
Now, you go to Alice, user of FOO (who hasn't perhaps
even heard of BAR). You pretend to be her peer and
ask her to authenticate using FOO. She does so, and you
tunnel all authentication packets via BAR to Bob,
who supports FOO-over-BAR. In the end, Alice believes she
authenticated to Bob, and Bob believes he authenticated
to Alice. In reality the other end of BAR is not Alice,
its the attacker. The attacker then proceeds to do
whatever he can with that fact. In the case of IKEv2,
he'd be able to send and receive packets to Bob as Alice.

The conditions of the attack are

(1) Same credentials used for multiple purposes
(2) No cryptographic binding between the authentications

--Jari

---

From: [email-masked]
Date: Tue, 19 Aug 2003 21:49:22 -0400

Michael Richardson <[email-masked]> wrote on 08/19/2003
> authentication server in order to perform the legitimate authentication)

You can tell people not to write their PIN number on their ATM cards all
you
want. They will do it anyway.

non-kg EAP methods are inherently weak. If they are used carefully, they
may
be acceptably safe in some environments, but users and administrators
*will*
screw it up.

If we want to insert warnings as to the dangers into the IKE spec, I'd
rather
do it by referencing some other document, but if we could agree on text in
less than negative 3 months, I'd be happy with that too.

Our real choice is whether to say non-kg methods MUST NOT be used or not.
If
we say they MUST NOT be used, people will implement them anyway but they
won't
get the same degree of interoperability testing at the bakeoffs. People
want
to use SecureID cards and challenge response cards and they don't want to
depend on some future enhancements to those devices in order to make IPsec
work. There are no kg methods for generic challenge response cards (though
one
could invent them for specific challenge response cards).

The following warning already appears in the Security Considerations
section:

> When using an EAP authentication method that does not generate a shared
> key for protecting a subsequent AUTH payload, certain man-in-the-middle
> and server impersonation attacks are possible. Use of such methods should
> be avoided where possible and where they are used, it is particularly
> important that the initiator validate the responder's certificate before
> initiating the EAP exchange.

We could add a stronger warning. But is there really any point?

      --Charlie

---

From: [email-masked]
Date: Tue, 19 Aug 2003 21:27:41 -0400

Michael Richardson <[email-masked]> wrote on 08/18/2003
>   I'm not complaining, I'm just asking for confirmation.

Yes. IKEv2 natively supports authentication via public key certificate and
by shared secret key. When it was proposed that we add support for OTP and
Token cards, we could see that down that road lay reinventing
authentication
protocols over and over, so we incorporated EAP as the mechanism for any
form of authentication other than public key certificate and shared secret
key.

      --Charlie

---

From: [email-masked]
Date: Tue, 19 Aug 2003 21:21:05 -0400

> I must have missed the resolution on issue 64, can someone remind me of

The issue was that people were concerned about how an implementation could
know which SA was being rekeyed when a rekey request arrived. In the past,
I had assumed that they would know because the traffic selectors would
match the traffic selectors on the replaced SA. But recent discussions have
allowed for the possibility of multiple SAs with the same traffic selectors
for playing games with QOS and such.

The proposed solution was to include the SPI of the rekeyed SA in the
request to create a new SA, so there would be no ambiguity. It might also
help with the race conditions that can produce duplicate SAs and the
"continuity across rekeying" issue raised by Nicolas Williams. I added an
additional field to the Create_Child_SA exchange to carry the SPI.

      --Charlie

---

From: Tylor Allison <[email-masked]>
Date: Wed, 20 Aug 2003 09:48:27 -0500 (CDT)

> authenticate with GTC if you verify the server's certificate correctly

This is all under the assumption that the IKEv2 server is talking to the
AAA server using EAP (GTC or otherwise).  The point I was trying to make is
that it seems that we are trying to force a requirement based on one
potential implementation choice for using non-kg EAP methods.  We needed a
mechanism to transmit user credentials in IKEv2; EAP was chosen.  This
doesn't mean that EAP must be used by the IKEv2 gateway to communicate with
a AAA server.  EAP-GTC in IKEv2 seems like a generic method for performing
various forms of auth, fulfilling customer requirements to allow non-kg to
be used.  If this method is not secure _WITHIN THE IKEv2 PROTOCOL_ (e.g.
susceptable to MITM or other attacks), then I would agree that it MUST NOT
be used.  If it is not secure outside of the IKEv2 protocol, then I think
it is really up to the vendors to choose whether or not to use it.... at
that point it is really outside the scope of IKEv2.

> > EAP methods protected from MITM?  How about:

Tylor

---

From: Tylor Allison <[email-masked]>
Date: Wed, 20 Aug 2003 10:15:06 -0500 (CDT)

On Tue, 19 Aug 2003 [email-masked] wrote:

> You can tell people not to write their PIN number on their ATM cards all you
> non-kg EAP methods are inherently weak. If they are used carefully, they may
> be acceptably safe in some environments, but users and administrators *will*
> screw it up.

As defined and used within IKEv2, these methods are secure, though, aren't
they?  (OK, not as secure as kg methods...) To mount the MITM attack on
IKEv2, you have to have the Initiator not verify the responder/gateway's
identity... that sounds like a broken client implementation.  There's been
quite a bit of discussion about using MITM attacks on the AAA server which
is listening for the EAP-GTC (or otherwise plaintext EAP messages) that
could occur between the IKEv2 server and the AAA server.  But this assumes
that EAP is being used to communicate with the AAA server... other
protocols may be used by the IKEv2 gateway instead.

Administrators can and will screw anything up... it's scary some of the
shared-secret policies or private key distribution methods I've seen
customers actually use.  The question is, is it reasonable to expect that a
security-aware administrator can setup a policy that will be secure?  Or
atleast are they no worse off then if they were setting up any other type
of policy (cert-based, pre-shared key, etc.)?

> If we want to insert warnings as to the dangers into the IKE spec, I'd rather

I think the warning already present is sufficient.

> Our real choice is whether to say non-kg methods MUST NOT be used or not.  If
> we say they MUST NOT be used, people will implement them anyway but they won't
> get the same degree of interoperability testing at the bakeoffs. People want
> work. There are no kg methods for generic challenge response cards (though one

If we are expecting that people are going to implement these methods and
customer are going to make use of these methods, I would much rather see a
standards-based way of doing so, and have this method be tested at bakeoffs.

Tylor Allison

---

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 20 Aug 2003 09:28:33 -0400

> authentication message sequence, or act as MITMs and grab the

[With my wg chair hat off]

I know, I know.  Most companies that I've seen still do very simple
authentication on the intranet just to prevent an entry-level QA
engineer from impersonating the the CEO.  However, the authentication
is often done using cleartext, reusable passwords via unencrypted
http.  Such companies are often running NFS wide open with no
protections as well, behind the firewall.  I also can't count the
number of times that I've been left alone in a conference room when
visiting one of these companies, and had the opportunity to plug my
laptop into the ethernet jack in the conference room table, and then
found myself on the inside of the corporate intranet.

(This is why I've always suspected that firewalls very often make
security worse, not better, because it lulls companies into a very
false sense of security.  Of course, many of these companies also
don't bother doing background checks before they hire temp workers who
are given free run of the building and computer networks, so one could
argue that trying to bolt a vault door onto a paper-mache house is
kind of silly anyway.)

Said companies will also assume that using cleartext, unprotected
access over dial-in access is perfectly safe, because everyone *knows*
it's hard to tap a phone line and figure out a v.90 modem tone, and
the IP path between the dialup servers and rest of the corporate
intranet is considered safe.  This might or might not be true,
depending on the threat model and the architecture of the dialup pool.

And I could be wrong, not being an expert in this area, but I was
fairly sure 802.1X involved the use of TLS, where the client is
supposed to validate the server certificates, so outsiders wouldn't be
able to see the authentication message sequence anyway.  At least,
that's the way Xsupplicant and FreeRadius, the open-source 802.1X
client/server implementations, work.  (One of my free-time projects
which I'm currently engaged in is to secure my home wireless network
using Cisco Aironet 350 access points and wireless cards.  It looks
like all the bits are there, but the documentation about the
FreeRadius configuration files is a bit meager.  If anyone has gotten
this working, let me know...)

In any case, the point is that I can imagine situations where given
the other choices in the convenience vs. security continuum that
various companies have made, using non-kg EAP mechanism wouldn't be
considered totally insane.  It is certainly is a much more fragile
system from a security standpoint, granted, and my personal belief is
that at the very minimum we should say SHOULD NOT, and include a very
long, explicit security considerations write up that explains the
risks very clearly, just to keep our consciences clear.

> from choosing the secure approach...

I am fairly sure that if we say MUST NOT, customers will force vendors
to either (1) simply violate the RFC and support non-kg EAP types
anyway, because they need the functionality, or (2) there will be a
configuration option, "strict RFC conformance", which when turned off,
will allow the further configuration option to allow the use of
plaintext passwords, one time passwords, or token authentication
responses tunnelled over EAP.

However, it is certainly perfectly fair to say that this Isn't Our
Problem (tm), although some VPN vendors might not want to be in the
uncomfortable position of being forced by the market to violate the
RFC.  But if they don't mind, it certainly is the safer, more "secure"
option to say MUST NOT, assuming that people actually implement to the
RFC.

But given the past history where we told people they SHOULD use
certificates with IKE, and they rejected that advice in favor of using
the more insecure XAUTH approach so they could continue using their
legacy authentication systems ---- you'll have to pardon me if I'm a
bit skeptical.  Fool me once, shame on you, fool me twice...

						- Ted

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 Aug 2003 10:13:36 +0300

I found the statement below very interesting.  While it is true that 
there are key-generating methods for most authentication methods, it is 
not always possible to implement them.

Under "PPP EAP REQUEST/RESPONSE TYPES" in 
http://www.iana.org/assignments/ppp-numbers there are 40 authentication 
methods listed.  However, for most of these, there is no published 
draft or RFC.  While it is good to know that #32 SecurID EAP is 
key-generating, there is no published document anywhere that says how 
the protocol works.  While the likes of Microsoft, Cisco, Check Point 
and Netscreen can probably negotiate with RSA to get the specifics of 
this protocol, smaller vendors and open-source developers cannot.  I 
very much dislike the idea of mandating the use of proprietary, 
unpublished methods.  If EAP method owners are forced to publish, I 
might feel differently.

XAUTH gave us generic message passing that the closest thing I see in 
EAP is GTC.  However, GTC seems to be reviled here.  I'd like to know 
what kg method can be used for generic challenge and response, like 
XAUTH allowed.

---

From: Uri Blumenthal <[email-masked]>
Date: Wed, 20 Aug 2003 13:41:12 -0400

In short. I disagree with Charlie wrt. the reasons EAP was
included. In my view it was not to be able to reuse the old
METHODS - but to reuse the old CREDENTIALS.

The exact "grinder" through which those credentials are
run, IMHO doesn't really matter to the users.

Ergo, we can and should use key-generating methods with
"legacy" credentials. Everybody will benefit.

---

From: Uri Blumenthal <[email-masked]>
Date: Wed, 20 Aug 2003 16:54:10 -0400

On 8/20/2003 4:51 PM, Michael Thomas wrote:
> Uri Blumenthal writes:
> Having been through this once before in the SIP
> world, there were really two considerations:
> 
> 1) reuse of credentials as you state

Which is perfectly OK.

> 2) keeping the AAA clueless that any of this 
>    is going on.

I don't think it's (a) feasible, or (b) desirable. Let's
NOT keep AAA clueless. Especially since in EAP it's the
AAA that will have to actually run the "new" EAP method.

If it means fighting reality as it is - so be it. :-)

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Aug 2003 13:51:55 -0700 (PDT)

> run, IMHO doesn't really matter to the users.

Uri, 

In particular, there was a large desire in SIP to
have CHAP, etc, instead of HTTP-digest so that the
blob delivered to the AAA would be
indistinguishable from, oh say, a PPP-dialin
authentication request. So in that case, the
grinder in fact did figure pretty largely in
people's considerations as CHAP and http-digest
are essentially the same thing except for the bits
on the wire.

This was a few years ago and maybe the AAA servers
have been upgraded to be more accommodating, so
take this with a grain of salt.

	  Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Aug 2003 14:06:40 -0700 (PDT)

> If it means fighting reality as it is - so be it. :-)

   Yes, that's it exactly -- reality. Note that I'm
   not defending this, just stating my experience in 
   the matter. My personal observation is that
   there seems to be a lot of both use for better
   or worse, and reticence to change people's AAA's. 

   Does anybody --  Jari? -- have any idea how the 
   SIP saga ended? Were AAA's eventually upgraded
   to deal with http-digest? My guess is that if
   they weren't willing to deal with it for SIP,
   they're probably not going to be any more
   willing with IKE...

	   Mike

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 21 Aug 2003 12:04:49 -0700

>I think the warning already present is sufficient.

Fully agree. When Bernard et. al.'s document comes out later, it will 
apply to lots of protocols, not just IKEv2. We should not delay IKEv2 
waiting for that document. We already explain the problem in the 
Security Considerations section, which is the proper place to do so.

>standards-based way of doing so, and have this method be tested at bakeoffs.

Fully agree. One of the main goals of IKEv2 was to avoid re-creating 
the XAUTH fiasco. Saying "'MUST NOT' or 'SHOULD NOT' do the things 
that your customers are demanding" is a really good way to cripple 
IKEv2 deployment.

--Paul Hoffman, Director
--VPN Consortium

---

From: Uri Blumenthal <[email-masked]>
Date: Thu, 21 Aug 2003 16:10:59 -0400

On 8/21/2003 3:04 PM, Paul Hoffman / VPNC wrote:
>>customer are going to make use of these methods, I would much rather see
>>a standards-based way of doing so, and have this method be tested at
>>bakeoffs.
> 
> Fully agree.........
> Saying "'MUST NOT' or 'SHOULD NOT' do the things

Well yes, I agree too. What I don't understand if why we
cannot create kg methods using the same credentials? It
seems to be the only way to satisfy both the customers
who need to use devices like SecureID (hey, I'm one
of those), and the security requirements.

> One of the main goals of IKEv2 was to avoid re-creating
> the XAUTH fiasco.

Please educate me - I didn't keep track of XAUTH. Why did
it fail? What was wrong with it?

Thanks!

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 22 Aug 2003 13:29:31 +0300

> that your customers are demanding" is a really good way to cripple 

I agree that "MUST NOT" will be crippling the deployment, but "SHOULD
NOT" is fine. From the RFC-2119:

----------------------------------------------------------------------
4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.
----------------------------------------------------------------------

So I think non-kg EAP methods SHOULD NOT be used. There are cases
where they are acceptable, or even useful, but the full implications
of using them should be understood...
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Yoav Nir <[email-masked]>
Date: Sun, 24 Aug 2003 10:32:09 +0300

Hi Uri,

Re: XAUTH.  There was nothing particularly wrong with XAUTH.  The 
fiasco is that the original IKE proved to be unusable in the 
remote-access scenario, because customers demanded authentication using 
RADIUS servers, OS passwords and SecurID tokens.  This led vendors like 
Cisco and Check Point to develop XAUTH which is not quite standard, so 
that remote-access becomes useable.  With IKEv2, we want to avoid 
making it necessary to develop such an add-on.

Re: not using kg methods.  SecurID belongs to a certain vendor, and 
they can create a kg method that suits them.  In fact, they have, but 
they won't publish the spec, so I can't implement it.  I could install 
their add-on (not yet available) on the client, and then the gateway 
only needs to channel the EAP messages between SecurID server and IKE 
client.  However, if we do that, we lose all the advantages of having a 
kg method, because the gateway does not know the shared secret.  Of 
course, you could implement something like you do in 802.1x where the 
server sends the shared secret to the gateway, but that's bad ( a 
shared secret isn't ).

Now let's take another example.  A customer keeps all his 
username/passwords on the mainframe, because that's the only computer 
they trust.  The only access our IKE gateway has to the mainframe is 
running something called a RACINIT, that allows you to pass the 
username and the password, and get a yes/no response.  How can we get 
this to work, if the gateway never knows what the password is?  Even 
MD5-Challenge won't work here.  Passing the password "in the clear" 
through GTC is the only way to go here.  Now if we could come up with 
some method that generates keys and passes the password from the client 
to the gateway, we'd have a solution, but here we can't use 
challenge-response as in MD5-Challenge or MSCHAPv2.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 27 Aug 2003 14:51:44 -0400

At 14:17 -0400 8/27/03, Uri Blumenthal wrote:
>On 8/24/2003 3:32 AM, Yoav Nir wrote:
>>  Hi Uri,
>
>Hi, and thanks for your response.
>
>>  they won't publish the spec, so I can't implement it.
>
>Yes, but what I had in mind is - at the very worst we can mix the
>data from the exchange into the key generation mechanism input.
>
>Would it not make sense?

We have managed to cleanly separate the key generation function from 
the authentication function in IKE v2 and I think it would be 
preferable to keep them separate.

Steve

---

From: Uri Blumenthal <[email-masked]>
Date: Wed, 27 Aug 2003 14:17:38 -0400

Would it not make sense?

> this to work, if the gateway never knows what the password is?....

Yes I see your point...

Thanks!

Regards,
Uri.

---

From: Uri Blumenthal <[email-masked]>
Date: Wed, 27 Aug 2003 17:26:10 -0400

> preferable to keep them separate.

Well, you can consider SecureID output as one of the nonces,
or append it to the client's nonce... I see your point - but
I'm sure you see mine.

---

From: Uri Blumenthal <[email-masked]>
Date: Wed, 27 Aug 2003 17:26:10 -0400

---

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Aug 2003 16:49:29 -0400

>or append it to the client's nonce... I see your point - but

I fear you are right, i.e., I don't see your point. But, unless other 
folks want to pursue approach this at this late stage in the IKE 
work, let's not devote more time to debating this.

Steve