Subject: [IPsec] Fwd: I-D Action:draft-hoffman-ikev2bis-02.txt

From: Paul Hoffman <[email-masked]>
Date: Sat, 17 Nov 2007 12:02:08 -0800

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>	Title           : Internet Key Exchange Protocol: IKEv2
>	Author(s)       : C. Kaufman, et al.
>	Filename        : draft-hoffman-ikev2bis-02.txt
>	Pages           : 125
>	Date            : 2007-11-17
>
>This document describes version 2 of the Internet Key Exchange (IKE)
>protocol.  It is a restatement of RFC 4306, and includes all of the
>clarifications from RFC 4718.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hoffman-ikev2bis-02.txt

Almost all of the changes came from Pasi (thanks, Pasi!). The change 
list from the document is:

    Many grammatical fixes.

    In Section 1.2, reworded Clarif-4.3 to be clearer.

    In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove
    redundant text.

    In Section 2.13, replaced text about variable length keys with
    clearer explanation and requirement on non-HMAC PRFs.  Also added
    "preferred" to Section 2.14 for the key length, and removed redundant
    text.

    In Section 2.14, removed the "half and half" description and replaced
    it with exceptions for RFC4434 and RFC4615.

    Removed the now-redundant "All PRFs used with IKEv2 MUST take
    variable-sized keys" from Section 2.15.

    In Section 2.15, added "(IKE_SA_INIT response)" after "of the second
    message" and "(IKE_SA_INIT request)" after "the first message".

    In Section 2.17, simplified because there are no more bundles.  "A
    single CHILD_SA negotiation may result in multiple security
    associations.  ESP and AH SAs exist in pairs (one in each
    direction)." becomes "For ESP and AH, a single CHILD_SA negotiation
    results in two security associations (one in each direction)."

    In section 3.3, made the example of combinations of algorithms and
    the contents of the first proposal clearer.

    Added Clarif-4.4 to the ned of Section 3.3.2.

    Reordered Section 3.3.5 and added Clarif-7.11.

    Clarified Section 3.3.6 about choosing a single proposal.  Also added
    second paragraph about transforms not understood, and clarified third
    paragraph about picking D-H groups.

    Moved 3.10.1-16392 from Section 3.6 to 3.7.

    In Section 3.10, clarified 3.10.1-16394.

    Updated Section 6 to indicate that there is nothing new for IANA in
    this spec.  Also removed the definition of "Expert Review" from
    Section 1.6 for the same reason.

    In Appendix A, removed "and not commit any state to an exchange until
    the initiator can be cryptographically authenticated" because that
    was only true in an earlier version of IKEv2.

--Paul Hoffman, Director
--VPN Consortium

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 24 Nov 2007 17:54:39 -0500

>    variable-sized keys" from Section 2.15.

okay, these clarifications helped me just now, and answer the questions for 
the email that I posted ten minutes ago.

Tero, based upon this, is your SKEYSEED input you sent me correct?

SshIkev2Crypto/ikev2-crypto.c:328/test_ikev2_skeyseed_agree: Key for PRF (Ni 
| Nr)
00000000: b5ce 8419 095c 6e2b 6b62 d305 5305 b3c4  .....\n+kb..S...
00000010: 47e9 f925 8ca2 3858 f675 b166 b02c c292  G..%..8X.u.f.,..

My inputs were:

unsigned char tc2_ni[] = {
  0xb5, 0xce, 0x84, 0x19,  0x09, 0x5c, 0x6e, 0x2b,
  0x6b, 0x62, 0xd3, 0x05,  0x53, 0x05, 0xb3, 0xc4,
};
unsigned char tc2_nr[] = {
  0x47, 0xe9, 0xf9, 0x25,  0x8c, 0xa2, 0x38, 0x58,
  0xf6, 0x75, 0xb1, 0x66,  0xb0, 0x2c, 0xc2, 0x92,
};

and this was md5, so the key size is 16 bytes.
You have an input key size of 32 bytes.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Nov 2007 17:11:17 +0200

> Tero, based upon this, is your SKEYSEED input you sent me correct?

The RFC4306 says that SKEYSEED is generated as:

SKEYSEED = prf(Ni | Nr, g^ir)

I.e. the key to the PRF is "Ni | Nr". The only rule that says you
should truncate or modify the key only applies to PRFs which take a
fixed lenght key, but HMAC-MD5 and all other HMACs take variable
length keys, so yes, I think that SKEYSEED key is correct. 

> You have an input key size of 32 bytes.

There is no key size for HMAC-MD5 PRF (Transform type 2). I.e. it
takes variable length of key. On the other hand there is key size for
the HMAC-MD5 authentication algorithm (Transform type 3) (i.e. the key
size needed for the SK_ai and SK_ar is specified in the RFC2403).

The thing that is missing in the RFC4306 which says how long the SK_d
needs to be. The RFC2104 referenced in the HMAC-MD5 PRF definitation
says that:

----------------------------------------------------------------------
3. Keys

   The key for HMAC can be of any length (keys longer than B bytes are
   first hashed using H).  However, less than L bytes is strongly
   discouraged as it would decrease the security strength of the
   function.  Keys longer than L bytes are acceptable but the extra
   length would not significantly increase the function strength. (A
   longer key may be advisable if the randomness of the key is
   considered weak.)
----------------------------------------------------------------------

but even it does not define the "default" or "preferred" key length
for the HMAC-* PRFs. The common use has been to use full data as input
if there is something with length already, and if not (like when
generating SK_d to be used for PRFs later) we have used the output
size of the underlaying hash function of the HMAC (as shorter keys are
strongly discouraged, and longer keys do not significantly increaase
the strength). 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Nov 2007 00:03:53 -0500

> length keys, so yes, I think that SKEYSEED key is correct. 

Paul: I would like this section clarified to include:
   HMAC-MD5 and HMAC-PRF, when used as a PRF, take variable length keys.

(somewhere else, I think you already clarify that they are fixed length
when used as INTEG)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Nov 2007 00:09:25 -0500

>    it with exceptions for RFC4434 and RFC4615.

First, thank you for adding the text:

    The initiator's signed octets can be described as:

    InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
    GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
    RealIKEHDR =  SPIi | SPIr |  . . . | Length
    RealMessage1 = RealIKEHDR | RestOfMessage1
    NonceRPayload = PayloadHeader | NonceRData
    InitiatorIDPayload = PayloadHeader | RestOfIDPayload
    RestOfInitIDPayload = IDType | RESERVED | InitIDData
    MACedIDForI = prf(SK_pi, RestOfInitIDPayload)

I'm pretty sure that "NonceRPayload" is redundant. Why is it shown?
Is it just to show what not to include? Is the same reason for including the 
GENIKEHDR? If that is not the case, then text:

    Appended to this
    (for purposes of computing the signature) are the initiator's nonce
    Ni (just the value, not the payload containing it), and the value

Is wrong?

Can you order things like this:

    InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
    GenIKEHDR = [ four octets 0 if using port 4500 ] | RealMessage1
    RealMessage1 = RealIKEHDR | RestOfMessage1
    RealIKEHDR =  SPIi | SPIr |  . . . | Length
    InitiatorIDPayload = PayloadHeader | RestOfIDPayload
    RestOfInitIDPayload = IDType | RESERVED | InitIDData
    MACedIDForI = prf(SK_pi, RestOfInitIDPayload)

I found this clarification much more confusing.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Nov 2007 00:16:24 -0500

I'm seeking a clarification on the form of the signatures.

Section 2.13 explains what octets to sign.
For the shared key case, it is very clear.

For the RSA case, I'm a little less clear.
RSA signatures are calculated by exponentiating a value.
To keep that value short, a hash is actually what is exponentiated.
MD5 or SHA1 being the common hashes, with SHA1 being preferred now.

I understand that the choice of algorithm is defined by
RSASSA-PKCS1-v1_5, with SHA1 preferred, and this is independant of the PRF or 
  INTEGRITY negotiated.

The inclusion of the PRF() for the shared key confused me for awhile (only 
long enough to decide to write this email) into thinking that I needed to 
sign the PRF() of the message octets.

Would sample packets, including the private keys used to generate them
be appropriate for an appendix?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Nov 2007 00:24:40 -0500

{sorry for lack of editing of reply to Tero. I thought I cut more out}

> MD5 or SHA1 being the common hashes, with SHA1 being preferred now.

This is, I think, a place where we lack any kind of algorithm agility.
I don't know if SHA256 has been standardized anywhere as a hash for use in 
RSA yet. Or does RFC4231's OID's mean that it could be used?

I think that one could include multiple AUTH payloads. If one did, and
one include SHA256 OIDs in the signature, would it make sense to actually 
make this a new AUTH METHOD?

---

From: <[email-masked]>
Date: Tue, 27 Nov 2007 08:19:35 +0200

Michael Richardson wrote:

> (somewhere else, I think you already clarify that they are 
> fixed length when used as INTEG)

This is one of the things we did clarify in ikev2bis-02,
Section 2.13:

   It is assumed that pseudo-random functions (PRFs) accept keys of
   any length, but have a preferred key size.  The preferred key size
   is used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14).
   For PRFs based on the HMAC construction, the preferred key size is
   equal to the length of the output of the underlying hash function.
   Other types of PRFs MUST specify their preferred key size.

The text in RFC 4306 which talked about "key is truncated or padded
with zeros as necessary" is gone; none of the currently defined
PRFs do that. The one exception is documented in Section 2.14:

   Ni and Nr are the nonces, stripped of any headers.  For historical
   backwards-compatibility reasons, there are two PRFs that are
   treated specially in this calculation.  If the negotiated PRF is
   AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the
   first 64 bits of Ni and the first 64 bits of Nr are used in the
   calculation.

Best regards,
Pasi

---

From: <[email-masked]>
Date: Tue, 27 Nov 2007 08:35:17 +0200

Michael Richardson wrote:
> For the RSA case, I'm a little less clear.  RSA signatures 
> are calculated by exponentiating a value.  To keep that value 
> short, a hash is actually what is exponentiated.  MD5 or SHA1 
> being the common hashes, with SHA1 being preferred now.

The octets-to-be-signed/MAC'd are identical for shared key case and
RSA (if you think of RSA as an algorithm which takes the whole 
message as an input, and computes the hash internally -- this is 
how RSASSA-PKCS1-v1_5 is described in PKCS#1).

> RSASSA-PKCS1-v1_5, with SHA1 preferred, and this is 
> independant of the PRF or INTEGRITY negotiated.

Yes, the hash algorithm is independent of the negotiated PRF or
INTEGRITY transforms (see RFC 4718, Section 3.2 for more
discussion).

> The inclusion of the PRF() for the shared key confused me for awhile
> (only long enough to decide to write this email) into thinking that
> I needed to sign the PRF() of the message octets.

Well... even in the RSA case, the signed data *does* include
the value prf(SK_pi,IDi') or prf(SK_pr,IDr').

> Would sample packets, including the private keys used to generate 
> them be appropriate for an appendix?

Maybe; are you volunteering to write them? :-) I guess test
vectors for SKEYSEED and SK_* calculation wouldn't hurt, either? :-)

In separate message, you wrote:

> This is, I think, a place where we lack any kind of algorithm
> agility.  I don't know if SHA256 has been standardized anywhere 
> as a hash for use in RSA yet. Or does RFC4231's OID's mean that 
> it could be used?

Well, we have *some* kind of algorithm agility; we can move to
newer hash functions, but it probably requires manual configuration,
and isn't automatically negotiated (like most things in IKEv2).

The OIDs for SHA-256/384/512 are standardized in PKCS#1 v2.1. 

> I think that one could include multiple AUTH payloads. If one did,
> and one include SHA256 OIDs in the signature, would it make sense 
> to actually make this a new AUTH METHOD?

Multiple AUTH payloads would be an incompatible extension to 
RFC4306, meaning IKE v2.1. IMHO new AUTH methods are needed
only if we do something else than RSASSA-PKCS1-v1_5.

Best regards,
Pasi