Subject: IKE V2 Open Issues

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 09 Apr 2003 17:14:46 -0400

After the San Francisco IETF meeting, we left with a couple of issues
that were settled at the meeting, and which need to be confirmed on
the list.  Those issues are:

	1.  Revisiting the decision reached in Atlanta concerning
		suites vs. ala carte negotiation to use an ala carte
		style negotiation

	2.  Keeping the Me Tarzan, You Jane feature

	3.  Identity handling (although the conensus on this issue was
		somewhat rough.  Please see the expanded discussion in
		a follow on message.)

I will be sending out separate messages for each of these issues to
make it easier to manage the thread of discussion on these items.

Left open at San Francisco was the disposition of Configuration
Payload versus DHCP over IKE.  Tero has last week posted to the list
three documents which document DHCP over IKE.  We invite people to
read these documents and to comment on them.

Finally, there has also been a number of new (or re-opened) issues
that have bubbled up on the list since the San Francisco.  These are:

1) Hugo's proposal to change legacy authentication to protect the
initiator's identity against active attacks.  After looking at the
discussion, Barbara and I have concluded that the impacts of moving
around various protocol elements introduces numerous additional
complexities which will be hard to address at this late date.  Russ
with his AD hat on set as the bar, "if the changes are the least bit
onerous, then this should not be done".  We believe these changes meet
that test.

2) Tero's proposal for a new source-address-changed notification
payload.  We proposed in San Francisco that issues regarding address
management be considered out of scope, and deferred to another working
group.  Tero's proposal is short and self-contained, hopefully
non-controversial.  If so, it seems reasonable to the wg chairs that
it be included in ikev2.  If there are any questions or debate over
this item, however, we feel it should be defered to another working
group.

3) Uri's AES PRF proposal.  The cryptographers are arguing amongst
themselves; we don't want to get involved.  We suggest that the Crypto
group in the IRTF review it, and if they give us their blessing we can
standardize it in a separate standalone document.

4) Michael Richardson's proposal to define separate payload numbers
for IDi and IDr.  Seems simple enough, and not controversial; let's
just do it.

5) Lack of definition of the COOKIE_REQUIRED notify payload.
Charlie's suggestion to delete the COOKIE_REQUIRED payload and simply
to use the COOKIE payload is simple, and non-controversial.

After reviewing the open issues, we believe that we are really close to
finishing IKEv2.  We had originally targetted WG last call for April
15th.  That's only a week away, but if we can come to closure quickly on
the DHCP/IKE vs. CP issue, we belive we should be able to close the
other issues in time to meet that deadline.

						Ted and Barbara

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 10 Apr 2003 02:55:18 +0300 (IDT)

> onerous, then this should not be done".  We believe these changes meet

objection! the above presentation of the complexity incurred by
the changes needed to suport  user's identity privacy (against
active attackers)  is inaccurate and misleading. The required changes are
purely local to the EAP extension of ikev2 and do not touch global
elements in the protocol nor they impact performance or any
other aspect of an application/implementation not running the
EAP extension (for example, if all we do is to move IDi to 5th message).

Why misrepresents the facts when you have a much better reason to 
back your decision? As I wrote in a mesage yesterday, the right decision
is indeed NOT to make these changes since (unfortunately) there were not
enough supporters for them (in spite of these changes being non-onerous).

> standardize it in a separate standalone document.

The only part of the spec that raises any issues with providing a
sufficiently long key to the prf is when using passwords as preshared
keys. I respect the intent of Charlie not to outlaw the use of 
passwords in the protocol (especially that as Paul pointed out an
implementation cannot verify the entropy of a key). Yet, let's not leave
the protocol unspecified (e.g. when using prf's based on block ciphers)
just because we cannot prevent this (bad) use by applications.
The solution is (as I wrote in a note to charlie a few days ago):

(1) require nonces to be long enough (at least half the length of the prf key)
(2) require the preshared key to be of the length of the prf key.

In particular, This is trivial to comply by the sharers (is there such a
word?) of a pre-shared key as this pre-sharing is done off-line. 
In case of a password, the people responsible for this wrong use, should
at least be able to convert the password (either if shorter or longer)  
into a string of the prf-key length (e.g., by hashing). 
Remember, that we are not talking here about legacy systems that have
automated interface constraints. Legacy authentication is given a
beautiful solution (up to user's id privacy of course :) in the EAP
extension of ikev2!

Hugo

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Apr 2003 11:22:45 +0200

In your previous mail you wrote:

   payload.

=> note there is an older proposal. IMHO as the peer address can be
changed using rekeying, there is no immediate need for a new payload
(but if it can be done in time there is no need to wait).
Unfortunately there is an immediate need to protect peer addresses,
I propose to introduce two notifications modelled after NAT detection
which will be included into all messages when NAT traversal is not
active (a very simple way to solve the issue).

   We proposed in San Francisco that issues regarding address
   
=> Tero's and my proposals provide roughly the same thing. IMHO it
will be more useful to use our free time to fix the NAT traversal
text in the current draft (Tero sent some text but it was not
included).

=> I agree this is the simplest way to fix it!

Thanks

[email-masked]

PS: I'll send for Friday morning a complete set of little details to
fix in the current draft. I believe the only controversial one could be
about NAT traversal.

---

From: Derek Atkins <[email-masked]>
Date: 10 Apr 2003 14:54:21 -0400

> EAP extension (for example, if all we do is to move IDi to 5th message).

Note that the responder cannot start the EAP authentication system
until it has an identity from the initiator (or it needs to send an
"EAP Identity Request" which adds yet another round trip).  This is
because the server needs to use the identity to determine what kind of
EAP session to initiate.  This is usually accomplished via an
encapsulation within RADIUS to some AAA server in order to
authenticate the supplicant (using EAP terminology).

Basically, this means that moving IDi to message 5 implies you cannot
start send the EAP Challenge until message 6, which means you're not
done with IKE until at least message 8 (assuming a one-round-trip EAP
protocol).  Are you SURE you want an 8-message protocol?  I'm not sure
this is what we want.

Also, what happens when you turn the protocol around?  I see you're
initiating IKE with server X, so I initiate IKE with you to determine
your identity -- how do you protect your identity there?

Or are you saying that you're putting the identity in different places
based on whether EAP is being used?  Well, how do you know if EAP is
being used if you don't know who your peer is?  I can certainly posit
a server that is configured to use EAP with some subset of peers and
RSA authenticatation with some other subset of peers.  How does the
server (acting as IKE responder) know which sub-protocol to use?

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Derek Atkins <[email-masked]>
Date: 10 Apr 2003 14:46:20 -0400

> to use the COOKIE payload is simple, and non-controversial.

Actually, I (and at least two others who have voiced opinions on the
topic) prefer Radia's suggestion of putting the cookie into the
COOKIE_REQUIRED notify payload and sending that.  So Bob would send a
N(COOKIE_REQUIRED{cookie}) message to Alice, and Alice would add
N(COOKIE{cookie}) to message-3.  I think this is clearer than
Charlie's suggestion of just using N(COOKIE{cookie}) in both
directions.

Radia?  Charlie?  Others?

-derek

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 10 Apr 2003 14:25:36 -0700

There is another big open issue that Ted didn't list, but we need to 
resolve, namely the splitting out of the crypto algorithms and MUSTs 
and SHOULDs.

What we have in this moment is -06 which lists the crypto algorithms 
and discusses the mandatory algorithms (without actually specifying 
them). Jeff Schiller volunteered to write the second document, which 
would define the mandatory algorithms and the UI suites that we would 
use.

After talking with Charlie, we realized that we had different views 
of what was agreed to at the San Francisco meeting, and unfortunately 
the minutes don't help clarify it. There seemed to be general 
agreement that the main IKEv2 document should not need to be revised 
if the we change algorithms or change how or why we want 
implementations to use them. The second document would be easier to 
update, specifically when we wanted to mandate AES and associated 
algorithms. This split has been used successfully in other IETF WGs.

There also seemed to be agreement that we should have a small number 
of UI suites that cover the mandatory algorithms, and that the UI 
suites should have justifying text.

Based on that, I propose the following:

- The list of crypto algorithms should be in Jeff's document. Leave 
the transform IDs in section 3.3.2 of IKEv2, but move everything 
starting with "For Transform Type 1..." to Jeff's document.

- Leave section 3.3.3 (the mandatory transform types, not algorithms) 
in the IKEv2 document.

- Move the discussion of mandatory transform IDs to Jeff's document. 
Section 3.3.4 should not be in the IKEv2 document, and Jeff can use 
as much of it as he wants in his document, depending on how he is 
arranging it.

- Jeff's document also has a short list of UI suites and some 
discussion of them. The list could be shorter than the one Charlie 
had in the -05 draft, and might only encompass the mandatory 
algorithms, or it might be longer. We need to discuss the list after 
we see it.

The result will bring us more in line with current IETF practice, and 
will let us give the VPN industry some clear guidance on how they can 
make their future IKEv2 systems more interoperable.

--Paul Hoffman, Director
--VPN Consortium

---

From: Uri Blumenthal <[email-masked]>
Date: Thu, 10 Apr 2003 15:38:14 -0400

> Charlie's suggestion of just using N(COOKIE{cookie}) in both

Yes, your way it's clearer. However Charlie's way is simpler,
and one less payload type to worry about...

I'll be happy with either choice - but lean towards N(COOKIE{cookie})...

---

From: Derek Atkins <[email-masked]>
Date: 10 Apr 2003 21:51:18 -0400

> and one less payload type to worry about...

IMHO payload types are cheap.

> I'll be happy with either choice - but lean towards N(COOKIE{cookie})...

I can go either way.  I don't feel extremely vetted to one way or the
other.

However, another benefit for using two payload types: it makes it
easier for protocol analyzers like tcpdump or ethereal.  They can
differentiate the cookie request N(COOKIE_REQUIRED{cookie}) from a
cookie response N(COOKIE{cookie}) to aid in analysis and debugging...
A small benefit indeed, but a tangible one for, IMHO, little
additional coding.  You have to have the code to parse the packet
either way -- whether you look for IKEV2_NOTIFY_COOKIE or
..._COOKIE_REQUIRED is a one-line change.

-derek

---

From: Uri Blumenthal <[email-masked]>
Date: Fri, 11 Apr 2003 10:16:13 -0400

> IMHO payload types are cheap.

Hm, OK.

> ..._COOKIE_REQUIRED is a one-line change.

OK, sold. I'm convinced in the value of COOKIE_REQUIRED and
support it.

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 11 Apr 2003 19:44:41 +0300 (IDT)

Derek, 

the questions you raise below were discussed in this thread.
Take a look at past messages on it. They should , hopefully, ,clear some
misunderstandings. Here are some brief answers to your questions.

First let me make a clarification that is important to keep in mind
(and relates to an objection that you raised in another message in this
thread). The proposal to protect IDi from active attacks applies ONLY
to the EAP extension of ikev2. All other runs of the protocol (in
particular peer-to-peer runs) will have the same protection that the WG
decided long ago (that is, IDr has full protection while IDi has only
protection against active attacks).

Also, important to keep in mind is that in the current EAP solution 
BOTH initiator and responder's identities are vulnerable to active
attacks. What I was proposing for the EAP exchange does not make it worse
for the responder in the EAP context (that is, it still has protection
against passive attacks) while it improves substantially the privacy
guarantee for the initiator.

See more below:

> protocol).  Are you SURE you want an 8-message protocol?  I'm not sure

This additional RT is the price for one of the solutions (moving IDi to
5th message). The other solution (moving R's authentication to msg 2 as
SLA proposed) does not have this problem though it has some complexity by
itself (again these trade-offs were discussed already in this thread).

As for the question "Are you SURE you want an 8-message protocol?" I have
to say that its formulation is a bit unfair. It makes it sound as a
horrible thing. And may be it is. The question, however, is "Are you
willing to pay an increase from 6-mesages to 8 messages for user's id
privacy?". I am. But apparently most people are not.
And again, there are solutions that do not require the extra RT

> your identity -- how do you protect your identity there?

I am assuming that the user's machine (or policy) will be configured such
that it will never respond to IKE-EAP initiations, but will only act as
initiator of EAP methods. That's how the user's id is  protected from
probe attacks.

BTW, note that anyone that requires protection of its own identity from
probing attacks has to make sure that it does not act as responder in a
EAP exchange. If a machine is configured to allow for such responses then
the protection promised by IKEv2 is gone.
(I ACTUALLY THINK THAT THIS NEEDS TO BE SPELLED EXPLICITLY IN THE DRAFT)

> server (acting as IKE responder) know which sub-protocol to use?

the server knows that the iniitiator requests EAP by the lack of signature
in message 3. All machines should be configured to reject such requests
except for those specific machines that will work as EAP-supporting
gateways.

In any case, this discussion is over. The decision on the EAP protocol for
IKEv2 has been made.

(And I will be travelling for a while now so do not expect a response 
from here)

Hugo

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 11 Apr 2003 15:24:04 -0400

Paul,

Most of what you suggest sounds reasonable, although I have one

> starting with "For Transform Type 1..." to Jeff's document.

Barbara and I believe that the list of algorithms and numbers which is
used to seed the IANA registry should stay in the ikv2 document:

   For Transform Type 1 (Encryption Algorithm), defined Transform IDs
   are:

          Name                     Number           Defined In
          RESERVED                    0
          ENCR_DES_IV64               1              (RFC1827)
          ENCR_DES                    2              (RFC2405)
          ENCR_3DES                   3              (RFC2451)
          ENCR_RC5                    4              (RFC2451)
          ENCR_IDEA                   5              (RFC2451)
		...

The reasoning is that there are other assigned numbers in the ikev2
document, and keeping the initial list in the ikev2 specs will be more
convenient for implementors.  As with all of the other initial
assigned number lists, the list kept by the IANA can be extended in
the future without needing to revise the ikev2 document.

						- Ted

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 11 Apr 2003 15:31:35 -0400

> OK, sold. I'm convinced in the value of COOKIE_REQUIRED and

There hasn't been much other discussion on the list, but in the
absence of other comments, it seems to make sense to go with this
proposal, although it does require defining a new number for
COOKIE_REQUIRED.

						- Ted

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 11 Apr 2003 17:02:40 -0400

> protection against active attacks).

Hugo, 

The proposal that we do things such as "moving IDr, [CERT,] AUTH from
msg 4 to msg 2", but only in the case of legacy authentication, is by
its very nature complicated.

In essence, instead of legacy authentication being just an extra
optional EAP payload, it becomes a different protocol with payloads
appearing in a different order and information being available at
different times.  Doing this would complicate the job of the spec
writer, the implementor, as well as someone trying to reason about the
security properties of IKE.

						- Ted

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 11 Apr 2003 16:14:27 -0700

At 3:24 PM -0400 4/11/03, Theodore Ts'o wrote:
>convenient for implementors.

None of the "other assigned numbers" are dealt with in Jeff's 
document; these are.

Implementers *have* to read both documents. They cannot implement the 
mandatory algorithms without reading Jeff's document. Thus, having 
the algorithm identifiers in the same document as the explanations of 
what is mandatory makes more sense than putting the numeric values in 
one document and the protocol description of the values (what is 
mandatory and what is not) in a different document.

>   As with all of the other initial

Assuming everything goes cleanly, that's correct. VPN vendors have 
seen this not go cleanly. If we choose to change the mandatory or 
suggested values in Jeff's document to something that is not in the 
base document, we'll then have numbers in *both* documents in the 
future; that's a mess. If we start off with all of initial registries 
in Jeff's document, revising Jeff's document will be cleaner.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Theodore Ts'o" <[email-masked]>
Date: Mon, 14 Apr 2003 08:46:09 -0400

> mandatory and what is not) in a different document.

Implementors can start implementing IKEv2 without knowing exactly
which algorithms will be mandatory and which will be optional.  In
most implementations which I've seen, the choice of such things is
kept in a modular design, and given that we've already said that what
will be mandatory will be changing over time, a wise implementor will
certainly make their product easy to update with respect to what
crypto algorithms are in use.

Furthermore, I would like to reduce the number of interdependencies on
the ikev2 document, so that we don't end up having to hold up the
ikev2 document based on external dependencies.  The good news is that
Jeff has finished the first cut at the document, so this is not to say
that I don't have faith that the second document won't be immediately
forthcoming.  However, Barbara and I would like to be able to get
ikev2 off our hands and into the IESG's plate as soon as possible, and
so anything where we can remove dependencies is a good thing.  

Due to its complexity ikev2 will probably require extra time for the
IESG to consider, if past experience with IKE is any guide.  So we can
finish polishing the required crypto algorithms document in parallel
with the IESG cogitating over ikev2, and once it's ready, we can ship
that off to the IESG, and given that the required crypto algorithms
document will be much simpler, I imagine that will be able to zip
through the IESG review stage very quickly.

Having seen a first draft of Jeff's document, one compromise which I
think would work well is to have the initial definition of algorithms
and assigned numbers in both documents.  Given that it is the IANA
registry which is authoratative, NOT either of these documents, having
the numbers in both places will be most convenient to the
implementors, and allows us to avoid having a forward dependency from
ikev2 to the "required algorithms" draft.

Russ, Steve --- procedurally, do you think any of the IESG
nit-pickers/process mavens will have a problem with this approach?

						- Ted

---

From: "Theodore Ts'o" <[email-masked]>
Date: Mon, 14 Apr 2003 13:56:38 -0400

There have been distressingly few comments on the final open issues.
It has been suggested that perhaps for those folks in the U.S., they
have been too absorbed in trying to reduce the amount of involuntary
support they have to give to the U.S. Government.  :-)

We have default editing instructions that we can give to Charlie in
the absence of working group feedback, which were listed in the
e-mails we sent last week.  If necessary, we will issue those
instructions to Charlie and then initiate wg last call.  While people
are of course free to wait until then to submit their comments, the
earlier we can get comments from wg members, the better.

So we ask that people try to look through ikev2-06, read through the
discussion of the last few remaining issues, and make comments as soon
as possible, preferably in the next few days.  Even if we can't get
the to wg last call by tomorrow, we'd prefer to only slip the schedule
by a few days.

Many thanks,

						- Ted

---

From: Henry Spencer <[email-masked]>
Date: Mon, 14 Apr 2003 14:30:19 -0400 (EDT)

> support they have to give to the U.S. Government.  :-)

Yes, the choice of schedule clearly violates Natalie's Law. :-)

(The original Natalie's Law -- enunciated by Ron Natalie during the
planning for the Great Renaming of Usenet in 1986 -- is "Never schedule
major software changes on or near major holidays!", with the added
comment that things like Usenix conferences, the World Science Fiction
Convention, and April 15th qualify as holidays for this purpose.)

                                                          Henry Spencer
                                                       [email-masked]

---

From: [email-masked]
Date: Mon, 14 Apr 2003 21:26:25 -0400

> proposal, although it does require defining a new number for

Done!

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 Apr 2003 18:53:15 -0400

>ikev2 to the "required algorithms" draft.

I strongly disagree.  The major motivation for segregating the algorithm 
discussion is to allow the protocol document to progress up the standards 
track hierarchy and not be pulled back down to Proposed Standard when an 
algorithm decision is made.

>nit-pickers/process mavens will have a problem with this approach?

I have a problem.  I consider myself pragmatic, but I guess you can apply 
the other labels if you wish.  In the S/MIME WG we went through this effort 
for CMS.  RFC 2630 became RFC 3369 and 3370.  Similarly, it was done for 
the certificate profile in PKIX.  RFC 2459 became RFC 3279 and 3280.  It 
was not that hard, so I think we should do it right the first time.

Russ