Subject: [Ipsec] FW: Remaining issues for IKEv2

From: "Charlie Kaufman" <[email-masked]>
Date: Mon, 10 May 2004 16:02:13 -0700

Resend... this apparently got lost

-----Original Message-----
From: Charlie Kaufman 
Sent: Sunday, May 09, 2004 10:44 PM
To: [email-masked]
Subject: Remaining issues for IKEv2

There are currently 14 open issues in the issue tracker database re:
IKEv2. I believe four others have been raised on the list but are not in
the issue tracker.

Of the 18, six (#101, #102, #104, #105, #106, and #107) are requested
changes to the IANA initial database I-D, six (#94, #97, #99, #100, #103
and one unnumbered) contained proposed text or were specific enough that
I have updated the IKEv2 I-D, three (#95 and two unnumbered) I believe
should be rejected, and for the remaining three (#96, #97, and one
unnumbered) I need guidance.

Possible sources of controversy:

Done:

The unnumbered one that I've updated is from Ted Ts'o's message of
4/6/04 proposing that the phrase "to pass an account name or" be removed
from the definition of ID_KEY_ID.

Not done, recommend reject:

#95 involved having an optional variation of the EAP authentication
exchange that is two messages shorter. There was limited discussion on
the list, but most of that was negative.

Proposal by Yoav Nir 4/14/04 to support periodic reauthentication. This
proposal came after the end of IETF Last Call and would add complexity
to the protocol. Recommend this be considered as an optional extension
if anyone is motivated enough to pursue it.

Apparent inconsistency pointed out by Peter Brubmair on 4/30/04 that
Appendix B talks about five Diffie-Hellman groups but only defines four.
The fifth was removed in revision -09 because it is defined in
[ADDGROUP]. The wording could be clearer, but it wasn't obvious how (to
me), and I don't believe it is technically wrong. Recommend no change.

Need Guidance:

Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to change
the computation of the AUTH payload. This is yet another "gilding the
lily" crypto modification. I am confident it adds no cryptographic
strength to the protocol and it breaks compatibility with anyone who has
implemented this stuff already, but it adds only trivial complexity to
the protocol and a trivial computational overhead. In the past, it's
been easier to just accept these proposals than to argue. One last
time??

Handling of OPAQUE. (#96 and #98). An agreement has been reached on the
handling of fragments in RFC2401bis, but it's not obvious how to reflect
that agreement in IKEv2. My (perhaps oversimplified) understanding is as
follows:

The problem arises because IPsec SAs can be limited to specific ports of
TCP and UDP and a single pair of endpoints can have different SAs for
different classes of traffic. If the sending endpoint needs to forward
an IP fragment other than the first, it may not be able to determine
what port the reassembled packet will contain and therefore may not know
which SA to forward it on (or whether to forward it at all). In some
cases, the sending endpoint will know to which port the fragment is
destined (either because it did the fragmentation or because it has
already forwarded the first fragment and kept state to recognize
subsequent ones). In that case, it would be most natural to send the
fragment on the "correct" SA. In some cases, the sending endpoint will
not know to which port the fragment is destined. In that case, it must
either discard the fragment, guess the correct SA, or have an SA
designated as carrying non-initial fragments.

The receiving endpoint faces a corresponding decision. When it receives
a non-initial fragment on an SA willing to accept traffic for some ports
but not others, it can either forward the packet or discard it. It may
have kept enough state to know whether this fragment is destined for an
allowed port or it may not.

The question for IKEv2 is: what indication (if any) of fragment handling
policies should be included in the IKEv2 negotiation. The choices are:

1) None. If the sending endpoint forwards a fragment on an SA
unacceptable to the receiving endpoint, the receiving endpoint discards
it and the connection with fragmentation likely fails. This behavior can
be avoided either by having the endpoints use the same scheme for
directing fragments or by having the receiving endpoint generously
accept fragments on any SA that accepts any ports of the protocol.

2) Explicitly negotiate a fragment carrying SA. Add some syntax to
traffic selectors that allows an SA to negotiate the ability to send and
receive fragments with unknown port (OPAQUE). This might be supplemented
with some ability to negotiate whether non-initial fragments can
alternatively be sent on the same SA as the initial fragment. One
proposed encoding is a (previously invalid) port range of 65535 - 0 as
indicating acceptance of non-initial fragments.

3) I'm sure there are other possibilities as well.

My recommendation is (1), with a short explanation of the situation and
a pointer to RFC2401bis, but I'm open to other options.

	--Charlie

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 10 May 2004 17:48:38 -0700

>me), and I don't believe it is technically wrong. Recommend no change.

Agree with you that we should not do any of those three. The first 
two are obvious candidates for extensions if people really care about 
them.

>been easier to just accept these proposals than to argue. One last

Yes, just accept the change from the CFRG. No one has even gotten 
close to deploying, so backwards compatibility is a complete 
non-issue.

>a pointer to RFC2401bis, but I'm open to other options.

Agree with you on (1). It is way too late in the process for us to 
think about the security and design issues for (2), although someone 
can add an extension for it later if people really care about it.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 10 May 2004 17:48:38 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 May 2004 22:08:20 -0400

Charlie,

I do not agree with your attempt to provide a concise 
characterization of the fragment handling topic. Its a complex topic, 
as illustrated by the length of my memo, and not easily distilled 
further.

I believe the WG has come to a decision re fragment handling, as 
reflected in message traffic following my memo on the topic. The 
decision calls for IKEv2 to support negotiation of OPAQUE as a value 
for traffic selectors, at least for port fields. Let's not translate 
this into a negotiation of fragment handling policy.

Steve

---

From: "Charlie Kaufman" <[email-masked]>
Date: Tue, 11 May 2004 14:12:33 -0700

Ted TS'o wrote:
>On Mon, May 10, 2004 at 04:02:13PM -0700, Charlie Kaufman wrote:
>> 
>> Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to 
>> change the computation of the AUTH payload. This is yet another 
>> "gilding the lily" crypto modification. I am confident it adds no 
>> cryptographic strength to the protocol and it breaks compatibility 
>> with anyone who has implemented this stuff already, but it adds only 
>> trivial complexity to the protocol and a trivial computational 
>> overhead. In the past, it's been easier to just accept these
proposals 
>> than to argue. One last time??
>> 
>
>I've looked through both archives and the VPNC mailing list, and I
can't >find this proposal.  Was it actually sent to the entire ipsec
mailing list?  >In any case, I tend to agree with previously expressed
sentiments that >absent a very strong, compelling need to make changes
in the crypto core of >IKEv2, it is long past time to shoot the
engineers and ship the product.

Gak! My error. I didn't notice that the messages of 3/30 were sent only
to me and not posted to the ipsec list. They are included below (without
permission, but they don't appear to contain anything embarrassing).

The proposed change provides a certain consistency of usage of the
various keys, which could simplify some security analysis. But unlike
the previous related change supported by CFRG, this one changes the wire
formats of all exchanges - not just ones using non-recommended EAP
methods.

The current syntax was introduced in March 2003 in response to a
different theoretical objection from Hugo.

	--Charlie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 30, 2004 9:53 PM
To: Charlie Kaufman; [email-masked]
Subject: Key derivation changes in IKEv2

Hi,

I just checked the key derivation changes in IKEv2 -13,
and noticed that one place still used the SK_ar/SK_ai
keys for PRF.

I belive that in Section 2.15, "prf(SK_ar,IDr')" should be now
"prf(SK_pr,IDr')" and "prf(SK_ai,IDi')" should be "prf(SK_pi,IDi')".

Hugo, could you check that this was what you intended?

Best regards,
Pasi

-----Original Message-----
From: Hugo Krawczyk [mailto:[email-masked]] 
Sent: Tuesday, March 30, 2004 10:30 PM
To: [email-masked]
Cc: Charlie Kaufman
Subject: Re: Key derivation changes in IKEv2

you are right.
unfortunately i did not have time to take a look at the new draft;
it's good that someone is paying attention.
Thanks!

Hugo

On Wed, 31 Mar 2004 [email-masked] wrote:

> Hi,
>
> I just checked the key derivation changes in IKEv2 -13,
> and noticed that one place still used the SK_ar/SK_ai
> keys for PRF.
>
> I belive that in Section 2.15, "prf(SK_ar,IDr')" should be now
> "prf(SK_pr,IDr')" and "prf(SK_ai,IDi')" should be "prf(SK_pi,IDi')".
>
> Hugo, could you check that this was what you intended?
>
> Best regards,
> Pasi
>
>

---

From: "Charlie Kaufman" <[email-masked]>
Date: Tue, 11 May 2004 14:12:33 -0700

proposals 

	--Charlie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 30, 2004 9:53 PM
To: Charlie Kaufman; [email-masked]
Subject: Key derivation changes in IKEv2

Hi,

Best regards,
Pasi

-----Original Message-----
From: Hugo Krawczyk [mailto:[email-masked]] 
Sent: Tuesday, March 30, 2004 10:30 PM
To: [email-masked]
Cc: Charlie Kaufman
Subject: Re: Key derivation changes in IKEv2

you are right.

Hugo

---

From: [email-masked]
Date: Wed, 12 May 2004 11:11:30 +0300

Hi,

This is not a new change; it is part of the change originally
proposed by Hugo in January (that was already approved). Hugo's 
proposal was the following (from e-mail sent on January 13th):
  
   Specifically add the pair SK_pi, SK_pr to the key derivation
   formula in 2.14. Change prf(SK_ar,IDr') to prf(SK_pr,IDr')
   and prf(SK_ai,IDr') to prf(SK_pi,IDr') in section
   2.15. Change "SK_ai and SK_ar" in the next to last paragraph
   of section 2.16 with "SK_pi and SK_pr"

Only the first and third changes were made in ikev2-13; the
second sentence was accidentally missed.

Best regards,
Pasi

> From: [email-masked] On Behalf Of ext Charlie Kaufman
> Sent: Wednesday, May 12, 2004 12:13 AM
> To: Theodore Ts'o
> Cc: [email-masked]
> Subject: RE: [Ipsec] FW: Remaining issues for IKEv2
> 
> 
> Ted TS'o wrote:
> >> with anyone who has implemented this stuff already, but it 
> >> adds only trivial complexity to the protocol and a trivial 
> >> computational overhead. In the past, it's been easier to just 
> >> accept these proposals than to argue. One last time??
> >> 
> >
> > can't find this proposal.  Was it actually sent to the entire ipsec
> > mailing list?  In any case, I tend to agree with previously expressed
> > sentiments that absent a very strong, compelling need to make changes
> > in the crypto core of IKEv2, it is long past time to shoot the
> Gak! My error. I didn't notice that the messages of 3/30 were
> sent only to me and not posted to the ipsec list. They are
> included below (without permission, but they don't appear to
> contain anything embarrassing).
> 
> The proposed change provides a certain consistency of usage of
> the various keys, which could simplify some security
> analysis. But unlike the previous related change supported by
> CFRG, this one changes the wire formats of all exchanges - not
> just ones using non-recommended EAP methods.
>

---

From: [email-masked]
Date: Wed, 12 May 2004 11:11:30 +0300

Hi,

Best regards,
Pasi

---

From: "Charlie Kaufman" <[email-masked]>
Date: Wed, 12 May 2004 13:27:52 -0700

Mea culpa! I can't believe I did this.

I somehow missed this when I created revision -13, and then interpreted
the mail correcting it not as a correction but as another request. I
will make the correction and post the diffs to the list before this goes
out again. (I believe this affects a small amount of explanatory text as
well).

	--Charlie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 12, 2004 1:12 AM
To: Charlie Kaufman; [email-masked]
Cc: [email-masked]
Subject: RE: [Ipsec] FW: Remaining issues for IKEv2

Hi,

Best regards,
Pasi

---

From: "Charlie Kaufman" <[email-masked]>
Date: Wed, 12 May 2004 13:27:52 -0700

--Charlie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 12, 2004 1:12 AM
To: Charlie Kaufman; [email-masked]
Cc: [email-masked]
Subject: RE: [Ipsec] FW: Remaining issues for IKEv2

Hi,

Best regards,
Pasi