Subject: Re: Do ipsec vendors care about privacy?

From: Russ Housley <[email-masked]>
Date: Wed, 19 Mar 2003 12:59:46 -0500

Hugo, in my view it is too late to be raising a question that will cause 
major surgery on the document.  It is time to fix things that are broken, 
make the document internally consistent, and publish it.  I do not think it 
is time to raise new requirements.

Russ
Your local, friendly, incoming Security Area Director

At 05:34 AM 3/19/2003 +0200, Hugo Krawczyk wrote:
>The catchy subject is mainly to grab the attention of ipsec vendors in this
>list (but it also reflects the contents of this note).
>
>The question that I want to resurrect is whether leaving the user's identity
>open to active disclosure attacks as done now in the "legacy authentication"
>solution of IKEv2 (described in section 2.16 of ikev2-05) is a reasonable
>decision given that protecting against such attacks can be done at a moderate
>price (see explicit specification below). This decision seems especially
>dubious given that the roaming/remote user scenario is the only case in which
>identity protection clearly makes sense, and constitutes a natural requirement
>for ipsec solutions in the legacy authentication world.
>
>I raised this question some time ago (beginning of Feb) and its resolution
>was mainly based on the fact that protecting the user's identity is a bit
>more complex than not doing it. I remain unconvinced, however, that the WG
>(in particular ipsec vendors) made here an informed decision on this 
>trade-off.
>I got the feeling that no one was really paying attention. (The only
>people to express opinions on this on the list were: Charlie who was
>"genuinely conflicted about this one", Derrell Piper and I that supported
>protecting the user's identity, and Marcus Leech who was against.)
>
>So before we close the ikev2 specification please take a look at what it takes
>to change the legacy authentication protocol in ikev2 to protect the user's
>identity from active attacks. Here are the two main candidate solutions:
>
>(1) Simply defer the sending of the user's identity IDi from message
>3 to message 5 (that is, after message 4 in which the responder authenticates
>itself).  The difficuty here is that the responder does not have IDi to base
>its choice of EAP method in message 4. I do not know how much of a practical
>problem this is (it was never pointed as such in the case of PIC in the ipsra
>wg), but others will know better.
>
>p
>(2) Let the responder authenticate itself already  in message 2.  This can
>be achieved by moving the AUTH and IDr payloads from message 4 to message 2.
>If we do not require encrypting these fields then the change is simple.
>Adding encryption is possible but requires applying SK{} from the middle of
>message 2 which is more complex. I suggest doing it simple, i.e. without
>encryptioni (also integrity protection is not needed here). This leaves
>the identity of R in the plain but this is ONLY for
>the legacy authentication scenario in which protecting the responder
>(server/gateway) identity is of little (or no) importance.
>
>Either change requires minimal change to the current specification,
>and none has major implementation complexity. They do not change at all the
>main protocol, and are relevant only to implementations that support legacy
>authentication (where user's privacy is a real issue).
>It seems to me that in this case the "complexity vs security trade-off"
>is easily resolved in favor of the user's identity protection.
>
>What others think?
>(If this time no one cares then we can easily forget about this issue; at
>least this will help to document that this was a conscious decision of the 
>WG.)
>
>Hugo
>
>PS: I'd have liked to raise this in the meeting in San Francisco but I
>couldn't make it. Hopefully there may still be some discussion on this there,
>or in the list in the nexy week.
>
>
>Lacking clear support for either way, Charlie
>decided to go with the simplest solution that is now in 05. This is
>certainly the right way to go if people do not really care about this
>privacy issue. In this case, however, I think that this decision needs
>to be documented in Radia's "rationale" draft (since this issue will be, I
>bet, something critiques of ikev2 will like to highlight).
>However, , before doing so I'd like to really sense if this is a thoughtful
>decision, or something that no one really cares about
>This note is intended to explicitl;y raise this issue before the closure
>of ikev2 specification. If people still support the current solution (or
>just shut up) then we will have a clear documentation that this decision
>reflects the WG view (if not strong consensus).
>
>
>On the other hand, I can bet
>that the future
>papers criticizing IKEv2 (there will be such papers no matter what we do)
>
>of the
>type written about IKEv1) will critically point
>to this issue. After all, they will say, a protocol that provides identity
>protection  with me IF
>
> >
> > Hugo Krawczyk <[email-masked]>  wrote:
> > > The one thing that I definitely dislike in the appended proposal is
>that
> > > it opens IDi (sent in message 3) to active attacks.  If there is one
> > > application where identity protection really makes sense is in hiding
> > > identities and locations of mobile users, which will be among the main
> > > users of SLA. I suggest to make IDi optional in message 3, and make it
> > > clear that implementations should NOT assume that this IDi value is
> > > available, certainly not in a way that compromises the user's
>identity.
> >
> > I am genuinely conflicted about this one - like the donkey between the
> > two bales of hay. I see equally good arguments on both sides, and I
>
>
>This WG has a long tradition of making decisions that become controversial
>later (see the paper by Kaufman and Perlman, ,Ferguson and Scneier, etc).

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 19 Mar 2003 23:57:19 +0200 (IST)

> Your local, friendly, incoming Security Area Director

Hi Russ, first congratulations for the new poisition. Good luck.

This response really sounds as coming from the area director :) 
ANyway, I'd agree with you that this is too late if the change I proposed
required "major surgery on the document". But it doesn't.
Any of the proposed solutions takes a 1 minute editorial work,
just moving one or two fields from one message to the other in section
2.16 (and has no influence on other partts of the document).

The question is not specification complexity which is null for this
changes. ALso, it is not a performance issue. None of the proposed changes
add round trips or computation (a message to the list from
Antonio Forzieri might have given that impression but his
modification of my proposal was unnecessary as he later stated himself).  

The only question is operational: can the responder (server) send the
first EAP message before getting IDi? If this is the case (as it was in
PIC and seems tobe agreed in some responses to my message) then we are
done at no cost at all (solution 1). If not, we may need to go to 
solution 2 (in which the responder authenticates in message 2). Here the
main operational issue, pointed out by Antonio, is that you need to have a
way for the initiator to signal that he is requiring legacy
authentication.

So all we need is some feedback on the above operational issues, and then
make a definitive decision about the right design/privacy trade-off.
It should not put any delay on the closure of ikev2.

Hugo

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 19 Mar 2003 13:58:37 -0800

Hi Russ,

I think Hugo may have something here. Lots of us implementers get so
busy sometimes that we overlook things which are important, and I think
this is one of them (at least in my case). This problem becomes much
more immediate when you consider that wireless lan access is in some
cases indistinguishable from remote access, and that exposing the user
identity on a public network is an issue under such circumstances. I
think we should consider this before ruling out the change.

Scott

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Mar 2003 17:02:45 -0500

Hugo:

>It should not put any delay on the closure of ikev2.

The working group co-chairs in combination with the document editor need to 
make a decision concerning the magnitude of the changes.  If it is the 
least bit onerous, then this should not be done.  It is not a requirement, 
and we are already overdue on delivery.

It is time to warp this effort up.  Fix anything that fails to meet the 
requirements that have already been set by the working group. then make the 
document internally consistent.  Additional stuff can be dealt with by a 
subsequent working group.

Ted got it right at the beginning of the meeting.  He said, "It is time to 
shoot the engineers and ship the product."

Russ

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 21 Mar 2003 09:10:38 +0200 (IST)

> >is time to raise new requirements.

I agree: no time for major surgery on the document.
But not too late for a change that takes 1-5 minutes editorial work
On the other hand, I admit that there are some operational issues 
that are not fully resolved in my proposals and need more input from 
people that care and know better. If this does not come on time
to make the document before being closed then we will not have it.

On the other hand, user's id protection in the remote access protocol of
ikev2 IS A NATURAL REQUIREMENT according to anything I heard from ipsec
developers (on the list and outside the list). So giving the opprtunity to
this substantial improvement if it comes at little cost and on time is a
reasonable thing to do. 

In any case, ,I raised the issue and two possible solutions, but I am not
the one that needs to decide if the WG is to adopt this or not. THOSE THAT
CARE (in one way or another) SHOULD SPEAK UP.

If there is not enough interest, then nothing needs to be done.
At least it will be documented that this was a conscious decision rather
than an overlook or the result of simple rushing.
(This will help against future criticizers of the protocol that wil
raise these issues in their papers...)
  
I will be glad to see some technical discussion in the coming days
if people care about having such discussions. Beyond that I am not going
to insist (this is not an area of "correct cryptographic design" for
which I personally care but rather one of engineering trade-offs that
other understand better than me).

Hugo

PS: shoot the engineers but not the scientists :)

---

From: Derrell Piper <[email-masked]>
Date: Fri, 21 Mar 2003 07:12:40 -0800

Hugo,

I continue to agree with this sentiment.  I think it's important to 
protect IDi for remote client access.

I prefer the second choice outlined: having the responder authenticate 
itself in message 2.

I do not think this change is too radical to adopt at this late time.  
It just needs some tender loving consensus.

Derrell

---

From: Hugo Krawczyk <[email-masked]>
Date: Sat, 22 Mar 2003 00:20:01 +0200 (IST)

Tero, it seems to me that your presentation of issues below provides
a sense of complexity and cost well beyond what is really involved in these 
solutions. Yet, the issues you raise are valid concerns and they will help
deciding whether protecting user's identity in IKEv2's EAP methods is worth
the pain or not. 

I will re-write your concerns, and analyze their effect (editorial,
security and implementation). I cannot qualify this as MAJOR SURGERY.
Let me know what I am missing.

To avoid an even longer message I will focus here in the solution in which the
server authenticates using its signature in message 2 (which at this point
seems to me as the preferred alternative). 
To make this self-contained recall that this solution calls for:

  (1) adding to message 1 an indication that the initiator asks to use an
      EAP-based exchange. 
  It seems to me that the best way to do it is by means of a new exchange
  type. If there is any problem with this then you can add such an 
  indication to the SA payload.

(2) moving IDr, [CERT,] AUTH from msg 4 to msg 2.
    Namely, message 2 from R to I (in section 2.16) will look as:
                           <--  HDR, SAr1, KEr, Nr, IDr, [CERT,] AUTH
    and message 4 will simply be:
                           <--   HDR, SK {EAP}

Now to your objections as they apply to this solution.

>
>       - This open one more DoS attack. The responder must sign the
>           auth message before it actually knows if there is anybody
>           there on the other end. Currently the resourses used from
>           the responder for the first packet is very cheap (policy
>           lookup, take precalculated Diffie-Hellman (or reuse old
>           one), make some state, and send packet). In this model we
>           would need to add do RSA/DSA sign operation during that,
>           which is much more expensive operations than any of the
>           above. That would most likely mean that the responder would
>           always require the return routability check before doing
>           anything, having an effect that we added one more round
>           trip to the exchange in normal case.

I do not agree with this assesment.
First there is NO reason to go to the routability check if you are NOT under
attack (this is true for the regular protocol, for the current EAP-based
protocol, and for the modification I suggest).
The question is whether this modification opens a signifcant new DoS 
opportunity.  Not really.
Already now the responder needs to compute the DH key (something that CANNOT
be done off-line) AND verify I's signature (relatively cheap for RSA and
very expensive in the case of DSA) BEFORE it has authenticated the initiator.
The fact that this computation cost happens at the reception of message 3
rather than after message 1 (in the modified solution) does not make the
attack significantly harder to mount. Certainly not in a way that such 
attacks were hard to mount (or ineffective) before  and are realistic now due
to the modified protocol.  DoS attacks are possible in all cases and the only
mitigation we provide is the optional cookie in message 2. (This option
remains unchanged in the suggested solution.)

BTW, I do not envision EVERY ikev2 machine to be configured to run the
EAP variant of ikev2 (section 2.16) but only those machines acting as
gateway/servers for support of remote access users. Thus for most machines all
this issue is irrelevant.

>
>       - Also the generation of the signature is little bit harder,
>           as we are signing the packet we are also adding the
>           signature to.

Indeed a litttle bit harder. Still nothing major.
A possible specification using the current text would say something like:

   Payloads SAr1 and KEr are included as the first and second payload in
   message 2 (immediately after HDR), and the responder signs the octets 
   starting with the first octet of the first SPI in the header of
   the second message and end with the last octet of the KEr payload in
   the second message.  Appended to this (for purposes of computing the
   signature) is the initiator's nonce Ni (just the value, not the
   payload containing it) and the value prf(SK_ar, IDr).

  [Note: the last sentence is modified from ikev2-05 but this is pending
   revision by Charlie anyway]

>
>       - Also in that case we loose the "You Tarzan, Me Jane" for
>           those cases, because the responder needs to sign the
>           identity it is using in the packet 2, and the initiator is
>           sending the preferred ID to be used in packet 3.

Right. The good news however is that when Jane is in the road she does
not have to reveal her name before she really knows she is talking to 
Tarzan.  (something like "You Tarzan? Me wonder...")

It's all about tradeoffs and here I see privacy as the winner. Don't you?

>
>       - Then again, how does the server know when to do this,
>           because it hasn't yet seen that the other end wants to do
>           EAP. So we either need to add it to the SA payloads, or do
>           it always.

As said above the Exchange Type can indicate that (or some other bit/octet in
SAi)

> 	- The text currently says that if the EAP method creates
>           shared key it MUST be used to generate the AUTH payloads
>           using the shared secret method by both ends. If we move the
>           AUTH payload to point before the EAP finishes (or actually
>           before it starts), then we have to change this. I do not
>           know the actual effects of this change. 

There is no change here. This SECOND AUTH (with the EAP-derived key)
by the responder (its definition and position in the protocol) are not
affected by the changes I suggested.

> 
> 	- All of these cases makes it easy to make polling attack, i.e
>           I start process in the IETF and start IKE negotiation
>           against each IP address. The responder will be very helpfull
>           and send me proof who they actually are. Currently there is
>           no way to get that information, I only can get the IP
>           address, I do not know to whom which ip address is assigned
>           to. Remember that IPsec is actually symmetric, thus the
>           original initiator can be responder later.

As I said, I do not suggest that every ipsec machine is configured
as a server (i.e. responder) for the sake of running IKEv2's EAP support 
protocol. Support for this method should be allowed only on gateways
(or machines) running as EAP servers (or relays).
Thus only such gateways will be open to polling attacks. However, in this
case we do not care about these attacks as we assume the gateway's id to be
public (we do not even encrypt it in message 2).

If you disagree with these views please let us know. This is an important
exercise. It is needed to decide where we establish the trade-offs.
I agree with two basic rules: do not mess with the non-EAP
portions of ikev2 and do not delay finalization of ikev2 as a whole.
Beyond that, I suggest that we consider user's privacy as a REAL issue in
remote access scenatios and be prepared, if needed, to pay some moderate
price for its inclusion.

Hugo

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 23 Mar 2003 19:31:52 +0200

>     and message 4 will simply be:

This will open the responders attack to polling attack. 

> protocol, and for the modification I suggest).

Some vendors refused to implement or use the aggressive mode of the
IKEv1, just because of it required you to do expensive operations
without ever knowing if there is anybody here. I would still guess,
that most implementations would require the return routability check
every time if this kind of protocol is used (at least I would in my
implementation). 

> very expensive in the case of DSA) BEFORE it has authenticated the initiator.

Yes, he needs to do that, but at that point he have seen that the
other end can see the packets sent to him, thus it makes spoofed
attacks impossible. The real attack is when someone sends lots of
spoofed packets each having fake IP address (so you cannot use IP
address to filter them out) and something that causes you to do work.

The current protocol do not allow that. 

> attack significantly harder to mount.

It makes huge difference. So big, that I guess that most of the
implementations will still want to make it message 3, i.e they will do
the cookie exchange before allowing any of those operations. 

>    revision by Charlie anyway]

There might be other payloads than SAr1, and KEr in that packet, which
need to get protection also, so the text needs to be different. I know
it, as I wrote the other draft doing about the same thing for IKEv1...

I didn't say it is impossble, I said it is little bit harder. I also
implemented my draft on IKEv1, and it required again little piece of
interesting code. It is not impossible, but it is not trivial either. 

> Tarzan.  (something like "You Tarzan? Me wonder...")

And this means that security gateway does not know which kind
authentication it really should be using, if he have multiple
identities. 

> It's all about tradeoffs and here I see privacy as the winner. Don't you?

Actually no. I think You Tarzan, Me Jane is important feature
for the remote access cases too. Also I think protection against the
polling attack is more important than protection against active attack
to initiators identity. Also this protection is not available when
doing the normal certificate based authentication, nor it is available
when doing the shared key authentication, why should it be there for
the EAP?

> As said above the Exchange Type can indicate that (or some other bit/octet in

I do not like having more different exchanges, I would really like to
keep the one exchange model we currently have.

> affected by the changes I suggested.

I didn't notice there was second AUTH before I started looking the EAP
stuff more because of the DHCP-over-IKE text. The current document do
nee more text about the second auth payload. 

> remote access scenatios and be prepared, if needed, to pay some moderate

As an implementator I still think that these changes are not small,
and they do add more complexity to the system (as an toolkit vendor we
do need to support almost all of the features, so I cannot just ignore
this case because it does not concern me :-). 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Antonio Forzieri <[email-masked]>
Date: Mon, 24 Mar 2003 12:48:25 +0100

Tero Kivinen wrote:
[SNIP]
>>                           <--  HDR, SAr1, KEr, Nr, IDr, [CERT,] AUTH
[SNIP]
> This will open the responders attack to polling attack. 
Agreed. I think we *MUST NOT* expose responder ID to polling attack... 
Or expose it as less as possible.

[SNIP]
> every time if this kind of protocol is used (at least I would in my
Agreed.
I was thinking about something like this to "solve" the problem.

      	Alice                                  Bob
        -------                                -----

HDR,SAi,KEi,Ni,EAPC          -->

                              <--    HDR,SAr,KEr,Nr,[CERTREQ],HLC

HDR,SK{[CERTREQ],IDr,SAi2,   -->
        TSi,TSr,HLC}

                              <--    HDR,SK{IDr,[CERT],AUTH, EAP}

HDR,SK{IDi,EAP,[AUTH]}       -->

                              <--    HDR,SK{EAP,[AUTH],SAr2,TSi,TSr}

EAPC is a new payload (EAP Capability) and it contains a list of all 
authetication types supported by Alice: MD5,OTP,GTC,RSA... (for a 
complete list look here: http://www.networksorcery.com/enp/protocol/eap.htm)

This payload let Bob know that Alice is going to use legacy 
authentication in EAP. If Bob doesn't support any auth type in EAPC he 
will send a notification message NO-VALID-EAP-SUPPORTED.

In message 2 I've introduced HLC HIP Like Cookie, its primary scope is 
the same of return routability check plus a DoS protection. I think this 
is a better mechanism than return routability check as made in current 
ikev2 draft, in fact with HLC Alice *MUST solve* the quiz, while with 
the actual mechanism Alice can simply sniff the cookie and respond. Of 
course she has to be able of observe that traffic. The first scenario 
that comes in my mind is that of Alice being on a LAN and using spoofed 
IP address of the LAN she is on.
HLC mechanism is described in draft-ietf-moskowitz-hip-05.txt.

[COPY&PASTE BEGIN]
5.3.1. HIP Cookie Mechanism

    Responder    Generates 2 Random Numbers, I and J
                 Challenge = Ltrunc(SHA1(I|J),K)
                 Send I, K, and Challenge in HIP Cookie in R1
                 Saves I, K, and Challenge for Delta time

    Initiator    Do Until Challenge-response = Challenge
                 Challenge-response = Ltrunc(SHA1(I|Rand),K)
                 EndDo
                 Send I, Rand, and Challenge-response in HIP Cookie
                         in I2

    Responder    Match Response with Challenge based on I
                 Reject if Challenge-response = Challenge
                 Challenge-proof = Ltrunc(SHA1(I|Challenge-response),K)
                 Accept if Challenge-proof = Challenge
[COPY&PASTE END]

Alice MUST also specify a valid IDr, which can't be of type ID_IPV4_ADDR 
                         or ID_IPV6_ADDR, in the case such an ID is 
specified Bob will send Alice  an INVALID-RESPONTER-ID notification 
message. This mechanism ensure a grade of protection on IDr.("You 
Tarzan? Me wonder...")

IDi is in message 5, as Hugo proposed. However what seems to me harder 
to solve is that many EAP methods require a valid Identity before 
sending the first EAP message.
[SNIP]

>>It's all about tradeoffs and here I see privacy as the winner. Don't you?
Agreed.

What do the others think?

-- 
------------------------------------------------
Antonio Forzieri
CEFRIEL - Politecnico di Milano
Tesista Area E-Service Tecnologies
Tel: 02-23954.334 - email: [email-masked]
ICQ# 177683894
------------------------------------------------

---

From: "Yoav Nir" <[email-masked]>
Date: Mon, 24 Mar 2003 14:44:06 +0200

I like the EAPC idea, although I am not sure that it will actually solve a
real problem.  Ususally Alice has only one means of authenticating herself
(she doesn't have a smart card, in addition to a token card and the password
that she remembers).  Still, if two implementations support a user-password
scheme, but one calls it MD5 while the other calls it GTC, it would be nice
to know at the end of the first message.

As for making the IDr in message 3 mandatory for SLA, I think that is a good
idea that solves our polling attack concern.  I think the draft should not
prohibit using an ID_IPV4_ADDR, but it should recommend (at the SHOULD
level) to use some sort of DN or if none exists, and FQDN.  Someone might
want to set up a gateway that anybody can connect to.

You mentioned that "... what seems to me harder to solve is that many EAP
methods require a valid Identity before sending the first EAP message".
What EAP methods are those?  MD5 just sends a random challenge.  It only
needs the identity to check the response.  GTC just expects the password.
It also doesn't need the identity until it's time to check the password.
RSA should not be used as legacy authentication.  I'm not sure about OTP.
It is possible that some authentication servers such as RADIUS need to know
the identity before they send out an MD5 challenge.

That is an implementation problem, which is why I'd rather use GTC for all
legacy authentication methods (RADIUS, LDAP, OS password, etc.)  That way,
the gateway receives the actual password and the ID after message 5.  It can
then do whatever authentication protocol it wishes with an authentication
server.

If somebody does plan to use MD5 with such a RADIUS server, then I guess
they will have to implement the full EAP protocol (including the Identity
messages) and prolong the negotiation to 4 RT.

Yoav

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Antonio Forzieri
Sent: Monday, March 24, 2003 1:48 PM
To: [email-masked]
Subject: Re: Do ipsec vendors care about privacy?

Tero Kivinen wrote:
[SNIP]
[SNIP]

[SNIP]
Agreed.

      	Alice                                  Bob
        -------                                -----

HDR,SAi,KEi,Ni,EAPC          -->

[COPY&PASTE BEGIN]

Agreed.

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 22 Mar 2003 02:28:26 +0800

> But not too late for a change that takes 1-5 minutes editorial work

All the proposal I have seen sent to the list are might be 1-5 minutes
editorial work, but the problem is that they also cause effects to the
other parts of the document, which means that much more analysis of
the actual effect of the change. I.e they actually ARE MAJOR SURGERY.

Lets analyze some of the proposal:

1) Leave out the IDi in the message 2 and move it later.

	- The current EAP mode assumes (and most of the
          implementations do require) that it has user's identity to
          before the EAP start. I.e the current text says that we are
          not supposed to use EAP(identity request / replies), as we
          can get the same information from the ID payload already.
          This adds one more round trip to the exchange.

2) Move the authentication of the server to message 2.

3) Move the server AUTH to place before the EAP has finished.

4) Authenticate the responder first before initiator

> this substantial improvement if it comes at little cost and on time is a

If you need it you can already do it know, by using the ID_KEY_ID, i.e
simply send random string to the other end as ID_KEY_ID, and made it
so that the server can then find map that to your identity, and update
it to be something different after you have authenticated
successfully. 

> CARE (in one way or another) SHOULD SPEAK UP.

I am strongly AGAINST this modification at this point of the process,
as I do not think it is small change. As I commented above all of the
small changes suggested have all kind of various problems, and I am
pretty much sure my list above is not complete list (they are those
that immediately came to my mind when seeing this discussion). 

> raise these issues in their papers...)

I agree that this decision should be documented. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Russ Housley <[email-masked]>
Date: Fri, 21 Mar 2003 20:35:06 -0500

Hugo:

I repeat:  The working group co-chairs in combination with the document 
editor need to make a decision concerning the magnitude of the changes.  If 
it is the least bit onerous, then this should not be done.  It is not a 
requirement, and we are already overdue on delivery.

We need to hear from the chairs before proceeding with this discussion.  I 
think that we have given them adequate information to make the decision.  I 
hope that they will make it in the next few days.

Russ

---

From: Antonio Forzieri <[email-masked]>
Date: Mon, 24 Mar 2003 16:15:44 +0100

> to know at the end of the first message.
Agreed. We can use EAPC to make Bob possible send the right EAP message 
in IKEv2 Message 4. So if the initiator sends EAPC(MD5), Bob will send 
in message 4 a EAP(Request,MD5).

> want to set up a gateway that anybody can connect to.
It sounds fine for me... What do the others think about?

> What EAP methods are those? 
The right question we have to ask to ourselves is:
*What authentication method we will use in IKEv2_EAP?*
*Which of these methods will require ID before sending an EAP message?*
I don't know all the methods EAP supports, however I know that OTP will 
not work without knowing IDi. MD5 and SecureID should work without any 
problem and GTC (which I don't know) should work. But what about 
Defender Token (AXENT), Arcot Systems EAP, CRYPTOCard, DynamID, 
Sentrinet and all the other methods supported in EAP?
Of course I think that we aren't going to support RSA PKA, or Smartcard, 
we can use them directly in IKEv2, without using EAP!
[SNIP]

If the answer is that there are few authentication method that needs to 
know IDi, than let's leave the things as they are, and for that methods 
use 1RTT more. (EAP(Request,Identity) in message 4).
[SNIP]

---

From: "Yoav Nir" <[email-masked]>
Date: Mon, 24 Mar 2003 17:58:20 +0200

I think the others will tell you that it is too late in the day to add such
new things as EAPC.  Since this is an optional, perhaps you can write a
draft that introduces this new payload.  It could optionally be used to save
the extra RT for EAP challenge -> EAP failure with a suggestion of another
method.

You mentioned a lot of EAP methods, many of which are not documented.  Since
we are talking about interoperability here, I suggest that we best stick
with the methods that are in the EAP rfc, namely GTC, MD5 and OTP.  IMO the
only one that is really useful is GTC, because it delivers the password to
the gateway.  Once the gateway has the password it can participate in
whatever authentication scheme the authentication server supports.  If the
server wants the client to hash the password, (as in CHAP or its
derivatives), the gateway can do it instead.

-----Original Message-----
Sent: Monday, March 24, 2003 5:16 PM

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 25 Mar 2003 05:53:08 +0200 (IST)

Whoever will make the decision here is free to ignore this 
discussion, or use it to make a more informed decision. 
I am sorry for the inconvenience but in my opinion the topic 
is worth the debate.

Hugo

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 25 Mar 2003 05:49:32 +0200 (IST)

> every time if this kind of protocol is used (at least I would in my

There is no reason to do that if the ipsec machine is not responding to
EAP based exchanges. ANd even if the machine does respond to these
exchanges there is no reason to use the cookie before the traffic 
reaches some "abnormality threshold". The comparison with IKEv1 is not
valid since ikev1 did not even give you the option to use a "routability
cookie". 

> The current protocol do not allow that. 

The current protocol allows you to use the routability cookie when
necessary. I agree that the opportunity for DoS seems more concrete in
this variant of the protocol but this is not much more than an ilusion. If
someone wants to DoS-attack a gateway it can do it in the regular protocol
via state exhaustion and DH computation. The solution (or mitigation) is
the same in both cases: the routability cookie.

> the cookie exchange before allowing any of those operations. 

I hope they won't. It is not necessary.
Do the cookie only when under attack (unusually high traffic).
You need this mechanism in place irrespective of the EAP-specialized
exchange

> interesting code. It is not impossible, but it is not trivial either. 

It is nothing major and worth the pay off: user's privacy

> authentication it really should be using, if he have multiple

The initiator will tell the gateway that it expects a EAP exchange,
no need for the "me Jane" mechanism

> when doing the shared key authentication, why should it be there for

Because remote access by users is the main scenario in which identity
protection makes sense. We would be allowing  the polling attack ONLY
against gateways that act as EAP servers. These are fixed address gateways
with no real need (or option) to hide their identities

> keep the one exchange model we currently have.

I do not understand what the problem of having a different exchange type
for EAP is. After all, even now, this is a different exchange (with
different messages and flows)

> this case because it does not concern me :-). 

We are in the trade-off business.
You have valid points about the fact that "nothing is for free".
But weighting all the pro's and con's I see user's identity privacy
in the EAP eachange as a sufficient reason to incur in these
not-really-major costs (I am sure you will manage to offer your toolkits
even in this case, and you may even sell more of these since people will
love to protect the privacy of their identities when in the move...)
Personally, ,I believe that even a possible extra round trip is worth the
added privacy, but we do not even need the extra round.

Hugo