Subject: Re: Charlie has submitted a new version of draft-ietf-ipsec-ikev2

From: Russ Housley <[email-masked]>
Date: Tue, 13 Jan 2004 12:43:29 -0500

I have no problem with two documents, but it needs to be done very 
soon.  It is best for the IESG to ballot the two documents together.

Russ

At 12:38 PM 1/13/2004 -0500, Theodore Ts'o wrote:

>[ This note should have been sent last week, but for some reason it
>   apparently never made it out of my sent mail queue.  My
>   apologies... -- Ted ]
>
>Hi Russ,
>
>Charlie has submitted a new version of the ikev2-bis document:
>
>         draft-ietf-ipsec-ikev2-12.txt
>
>This draft contains fixes to various nits and errors that were raised
>after the wg last call (including the ones which you had found during
>your initial review of the ikev2-11 I-D after we had forwarded it to
>you).  We believe that none of the changes are controversial, and so
>the document should be ready for IETF-wide last call.
>
>One change that in the document dependency structure which is present
>in the -12 document is that the IANA considerations section has been
>moved to a separate document which Michael Richardson has been
>developing.
>
>Do you have an opinion about whether the IANA considerations should be
>kept in a separate document, which would make it easier for the IANA
>to review (and which truly isn't really necessary for implementors to
>see), or whether it should be combined into one document (which is
>already 102 pages and over 250k long)?  It seemed to us that it might
>make more sense for the IANA considerations to be in a separate
>informational RFC, but there are certainly arguments to do things
>either way.  Do you believe the IESG and the IANA would have a strong
>preference to do things one way or the other?
>
>Many thanks!!
>
>                                                 - Ted

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 13 Jan 2004 12:38:32 -0500

Hi Russ,

Many thanks!!

						- Ted

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 13 Jan 2004 10:51:11 -0800

At 12:38 PM -0500 1/13/04, Theodore Ts'o wrote:
>either way.

Why do you want the IANA Considerations document to be an RFC at all? 
It is meant as *one-time* advice to IANA about what to do when the 
IKEv2 document becomes a Proposed Standard. Michael's document should 
remain an Internet Draft until IANA needs it, and it should then 
disappear after IANA uses it.

--Paul Hoffman, Director
--VPN Consortium

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 13 Jan 2004 22:10:50 +0200 (IST)

There is one issue that was subject of discussion in the last weeks and I
believe requires a better resolution. I refer to the problem that ikev2
(including -12) defines two uses of the prf function (in sections 2.15 and
2.16)  where the prf is keyed with SK_a. This is problematic since SK_a is
defined as a key to the "integrity algorithm" which may be different than
the prf. Indeed the integrity algorithm and prf have different transform
types (#3 and #2) respectively, and then are negotiated independetly (in
particular they may use different algorihms).

Why is this a problem?

First, because the two transforms may require keys of different lengths,
in particular SK_a may be too short to key the prf.

Second, it is a wrong cryptographic practice to use the same key with two
different algorithms. This may or may not translate into actual attacks,
but it certainly spoils the otherwise sound design of the protocol.
It will also invite "attacks" from future formal analysts (beyond the
operational issues referred to in the first item).

I believe that the problem is best solved by deriving an additional pair
of keys from SKEYSEED (call them SK_pi and SK_pr) for keying the prf in the
above two cases. It is certainly easy to specify and to implement
(and easier than to justify why this wasn't done).

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"

I suggest that this be solved before the official last call (otherwise you
can see this as a comment provided in the last call phase).

Hugo

---

From: Michael Richardson <[email-masked]>
Date: Tue, 13 Jan 2004 15:42:58 -0500

>>>>> "VPNC" == VPNC  <Paul> writes:
    VPNC> Why do you want the IANA Considerations document to be an RFC at
    VPNC> all? It is meant as *one-time* advice to IANA about what to do when
    VPNC> the IKEv2 document becomes a Proposed Standard. Michael's document
    VPNC> should remain an Internet Draft until IANA needs it, and it should
    VPNC> then disappear after IANA uses it.

  And it was in this spirit that I wrote the document.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [