Subject: [IPsec] test vectors for IKEv2 SKEYSEED derivation

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Nov 2007 00:33:44 -0500

I'm looking for some test vectors for SKEYSEED calculation.  I asked google a 
bit, but I didn't find anything published on the IPsec list. Perhaps there 
are some materials from one of the bakeoffs.  I wish that we had put some 
vectors into rfc4306. I saw that there are some vectors in the SHA256 drafts, 
but I don't think that they give enough detail to confirm that an 
implementation has done the right thing.
Obviously, I'm going to try interoperating, but it isn't always easy to find 
the error in the calculation when looking a black box.

If someone would be willing the confirm my calculations, my inputs and output 
are listed below, or in C-hex files at:
 
http://git.openswan.org/cgi-bin/gitweb.cgi?p=openswan.git;a=blob;f=testing/lib/libpluto/seam_gi.c;h=cfaa33012e3e3506e7cf62f5a64a7ca6b51d7a98;hb=7a2a3bf55fc19df377e78ea61673d74656ece8b0
http://git.openswan.org/cgi-bin/gitweb.cgi?p=openswan.git;a=blob;f=testing/lib/libpluto/seam_gi_sha1.c;h=e980dabd5cc17b3f12b56085ac7f09eccf60f861;hb=9d417f4bb2ebb4333dda6e228e7bc0eae834f61a

For instance, this is my calculation with MD5 as the PRF,
HMAC-MD5 as the intended auth and 3DES as the intended cipher for
the PARENT_SA. (I.e. 128 bits required for SK_a and SK_p, and 192 bits for SK_e).

(THESE ARE NOT CONFIRMED!!!)

| spii  75 46 d3 d6  ea 09 f7 df
| spir  61 a6 78 6a  41 ea 48 06
| ni  b5 ce 84 19  09 5c 6e 2b  6b 62 d3 05  53 05 b3 c4
| nr  47 e9 f9 25  8c a2 38 58  f6 75 b1 66  b0 2c c2 92
| gi  ff bc 6a 92  a6 b9 55 9b  05 fa 96 a7  a4 35 07 b4
|   c1 e1 c0 86  1a 58 71 d9  ba 73 a1 63  11 37 88 c0
|   de bb 39 79  e7 ff 0c 52  b4 ce 60 50  eb 05 36 9e
|   a4 30 0d 2b  ff 3b 1b 29  9f 3b 80 2c  cb 13 31 8c
|   2a b9 e3 b5  62 7c b4 b3  5e b9 39 98  20 76 b5 7c
|   05 0d 7b 35  c3 c5 c7 cc  8c 0f ea b7  b6 4a 7d 7b
|   6b 8f 6b 4d  ab f4 ac 40  6d d2 01 26  b9 0a 98 ac
|   76 6e fa 37  a7 89 0c 43  94 ff 9a 77  61 5b 58 f5
|   2d 65 1b bf  a5 8d 2a 54  9a f8 b0 1a  a4 bc a3 d7
|   62 42 66 63  b1 55 d4 eb  da 9f 60 a6  a1 35 73 e6
|   a8 88 13 5c  dc 67 3d d4  83 02 99 03  f3 a9 0e ca
|   23 e1 ec 1e  27 03 31 b2  d0 50 f4 f7  58 f4 99 27
| gr  cd 30 df 6e  c0 85 44 12  53 01 80 d8  7e 1a fb b3
|   26 79 3e 99  56 c8 6a 96  25 53 c2 77  ad 5b ab 50
|   f8 32 5a d8  64 0b 0e fe  a5 1d 6c 83  1f a1 7c fb
|   0f 2e 1a f4  b1 66 a0 fe  30 75 12 ad  0f 81 ab b8
|   aa fb 68 48  ec 10 a4 97  6c 3d b1 17  ec e1 e6 61
|   db bf 48 0c  28 2e 3f 11  07 c1 86 42  80 1e e8 3f
|   9e 4a b9 ab  63 6f 23 7d  aa f6 a7 aa  d8 22 99 3e
|   a4 1e a3 31  ee 27 82 0b  93 f5 0b 8f  3f 71 05 61
|   c9 25 70 26  97 ba 6b 1e  95 3c 21 fb  c9 a7 7d 2b
|   5f 87 3c fc  50 99 e7 7d  48 4c dd 52  66 4b cf 0d
|   bf 00 ca fd  ae 6d e7 14  6d 11 35 f6  5d 93 5f 60
|   b9 73 0f e0  49 2c 2a f8  c9 04 f6 4c  59 16 90 9d
| secret  17 9b b3 22  a6 77 6f bc  01 4e 41 03  f0 f6 2e 93
|   fb 07 d0 93  84 57 e4 54  1e 64 46 a9  34 37 c0 9d

| DH calculation gives:
|   c2 e9 1d a2  05 63 19 6e  34 89 df d1  af a5 4a 51
|   09 4d 76 2e  ff bf 39 a6  1a 64 f4 8c  8e fb 0a 4f
|   ac 5a a3 18  01 aa 1a cc  94 d6 91 50  96 38 16 8b
|   dd 39 19 c3  5e 99 5a 92  3d e3 fa 2c  2d 21 cb 15
|   ac 7a 81 49  ab 37 33 f7  55 a3 25 a0  90 4a 87 bb
|   fe 70 71 8b  63 ba af 56  a7 b4 8f 54  d5 0d 17 95
|   14 f3 09 21  da d6 8c 71  8c d4 82 89  06 c4 24 75
|   4b 55 4c d9  91 83 ce b6  ad ae 6a 5e  7d bf f9 ef
|   ae 60 a7 b7  97 b6 31 50  4e cc 0f ff  17 f1 aa 4b
|   1e 0c 61 71  32 d6 b9 79  58 61 e6 ab  f3 67 d8 9e
|   3c db 68 3e  ff 9e 37 ea  67 70 21 0e  07 ea b6 2b
|   72 30 ea 5d  55 86 9a 04  86 ed e1 c7  bd ee 61 84

| skeyseed:  35 8e b1 84  d9 02 7e a2  a3 b3 e6 08  b9 2f 5f bf

| prf+[1]:  52 9a 10 2f  28 df 41 78  6e c2 75 e1  06 3b d2 50
| prf+[2]:  3e 43 b9 a8  f8 4e b0 2b  a1 be 33 6f  4a 37 da 21
| prf+[3]:  ba 4e fe 1c  f0 0a 4d b0  22 02 5d 4f  53 b9 56 45
| prf+[4]:  50 a9 46 72  7a af fb 5d  8f 85 21 d4  88 eb 84 ec
| prf+[5]:  72 87 28 fe  b0 6a 22 c2  83 c5 c2 82  bb f7 d5 b7
| prf+[6]:  7a dc 9f 0b  1d 32 11 cc  90 22 79 2c  20 b4 93 d6
| prf+[7]:  18 01 15 e0  86 ce d3 95  6b 1a b1 f7  7b bb 6f 2d
| prf+[8]:  c0 47 bc 10  1f d5 b0 e9  b2 9f 74 93  2a 8e c4 3a

| SK_d:  52 9a 10 2f  28 df 41 78  6e c2 75 e1  06 3b d2 50
| SK_ai:  3e 43 b9 a8  f8 4e b0 2b  a1 be 33 6f  4a 37 da 21
| SK_ar:  ba 4e fe 1c  f0 0a 4d b0  22 02 5d 4f  53 b9 56 45
| SK_ei:  50 a9 46 72  7a af fb 5d  8f 85 21 d4  88 eb 84 ec
|   72 87 28 fe  b0 6a 22 c2
| SK_er:  83 c5 c2 82  bb f7 d5 b7  7a dc 9f 0b  1d 32 11 cc
|   90 22 79 2c  20 b4 93 d6
| SK_pi:  18 01 15 e0  86 ce d3 95  6b 1a b1 f7  7b bb 6f 2d
| SK_pr:  c0 47 bc 10  1f d5 b0 e9  b2 9f 74 93  2a 8e c4 3a

And for AES128 and SHA1:
| spii  75 46 d3 d6  ea 09 f7 df
| spir  61 a6 78 6a  41 ea 48 06
| ni  b5 ce 84 19  09 5c 6e 2b  6b 62 d3 05  53 05 b3 c4
| nr  47 e9 f9 25  8c a2 38 58  f6 75 b1 66  b0 2c c2 92
| gi  ff bc 6a 92  a6 b9 55 9b  05 fa 96 a7  a4 35 07 b4
|   c1 e1 c0 86  1a 58 71 d9  ba 73 a1 63  11 37 88 c0
|   de bb 39 79  e7 ff 0c 52  b4 ce 60 50  eb 05 36 9e
|   a4 30 0d 2b  ff 3b 1b 29  9f 3b 80 2c  cb 13 31 8c
|   2a b9 e3 b5  62 7c b4 b3  5e b9 39 98  20 76 b5 7c
|   05 0d 7b 35  c3 c5 c7 cc  8c 0f ea b7  b6 4a 7d 7b
|   6b 8f 6b 4d  ab f4 ac 40  6d d2 01 26  b9 0a 98 ac
|   76 6e fa 37  a7 89 0c 43  94 ff 9a 77  61 5b 58 f5
|   2d 65 1b bf  a5 8d 2a 54  9a f8 b0 1a  a4 bc a3 d7
|   62 42 66 63  b1 55 d4 eb  da 9f 60 a6  a1 35 73 e6
|   a8 88 13 5c  dc 67 3d d4  83 02 99 03  f3 a9 0e ca
|   23 e1 ec 1e  27 03 31 b2  d0 50 f4 f7  58 f4 99 27
| gr  cd 30 df 6e  c0 85 44 12  53 01 80 d8  7e 1a fb b3
|   26 79 3e 99  56 c8 6a 96  25 53 c2 77  ad 5b ab 50
|   f8 32 5a d8  64 0b 0e fe  a5 1d 6c 83  1f a1 7c fb
|   0f 2e 1a f4  b1 66 a0 fe  30 75 12 ad  0f 81 ab b8
|   aa fb 68 48  ec 10 a4 97  6c 3d b1 17  ec e1 e6 61
|   db bf 48 0c  28 2e 3f 11  07 c1 86 42  80 1e e8 3f
|   9e 4a b9 ab  63 6f 23 7d  aa f6 a7 aa  d8 22 99 3e
|   a4 1e a3 31  ee 27 82 0b  93 f5 0b 8f  3f 71 05 61
|   c9 25 70 26  97 ba 6b 1e  95 3c 21 fb  c9 a7 7d 2b
|   5f 87 3c fc  50 99 e7 7d  48 4c dd 52  66 4b cf 0d
|   bf 00 ca fd  ae 6d e7 14  6d 11 35 f6  5d 93 5f 60
|   b9 73 0f e0  49 2c 2a f8  c9 04 f6 4c  59 16 90 9d
| secret  17 9b b3 22  a6 ab cd ef  01 4e 41 03  f2 f6 2e 93
|   fb 07 d4 93  84 57 e4 54  1e 64 46 a9  34 37 c4 9d

| DH calculation gives:
|   60 76 62 71  0c 76 fe 27  4f 6f 7c 9f  68 cf cf e0
|   a7 56 44 cb  a1 92 2a b9  c9 c2 16 0e  a7 80 d0 71
|   50 06 87 10  85 f0 80 30  58 c4 2e c9  d6 ae 4f 53
|   41 b6 2b 7c  66 8d 9f ba  20 15 5a 7c  23 60 e6 22
|   03 55 a0 80  3b c9 11 a5  6f c7 30 0d  d7 f6 6b 01
|   c4 88 ab 8f  79 1a d2 cc  58 8d 28 c0  c0 78 fa 61
|   21 d5 88 1b  3a e9 b4 a7  d8 c9 a6 58  60 6e 0a 2a
|   5e 9c 5f 9e  c2 b5 0b 63  d7 af bb 80  f4 a4 83 37
|   ce de f5 aa  6f a1 a0 f3  af c3 21 47  19 2c 7f ba
|   7e 27 9f 00  28 81 21 cb  3d e7 f1 d9  76 fd f1 6c
|   99 28 db 95  92 38 f7 83  a4 fd 38 75  7e 55 2c e9
|   2d db d6 f5  0c 1d 35 af  77 34 fc 85  cb 30 b8 09

| skeyseed:  9d 8e 53 96  0b 36 01 f4  c0 d3 29 ee  1e c3 70 27
|   0d 06 22 17

| prf+[1]:  ac 97 eb 39  07 53 a4 5d  61 c1 64 ff  ca 25 99 b0
|   2e 05 3c 7e
| prf+[2]:  4e a8 e6 62  b0 7c dd 43  0f 69 44 c6  72 3e 4b 82
|   d5 72 24 18
| prf+[3]:  51 5b 0b d2  2e 6d 76 b3  4f db 76 0a  a7 bf ad 80
|   b1 09 b7 5d
| prf+[4]:  3f 44 bf 47  ca fd 81 50  59 1d eb 08  81 99 fc bf
|   be db 67 ec
| prf+[5]:  7d c3 d0 0c  cc ac 42 e7  0c d6 3b de  cc 07 97 44
|   b4 a3 4e 8a
| prf+[6]:  0d 2f 27 8b  ee 06 6d 07  a5 a5 75 2e  e9 00 11 7e
|   41 d4 31 62
| prf+[7]:  40 b8 63 22  bf 06 9f bc  eb 81 58 e7  6a 49 14 75
|   56 d3 3c 8e
| SK_d:  ac 97 eb 39  07 53 a4 5d  61 c1 64 ff  ca 25 99 b0
|   2e 05 3c 7e
| SK_ai:  4e a8 e6 62  b0 7c dd 43  0f 69 44 c6  72 3e 4b 82
|   d5 72 24 18
| SK_ar:  51 5b 0b d2  2e 6d 76 b3  4f db 76 0a  a7 bf ad 80
|   b1 09 b7 5d
| SK_ei:  3f 44 bf 47  ca fd 81 50  59 1d eb 08  81 99 fc bf
| SK_er:  be db 67 ec  7d c3 d0 0c  cc ac 42 e7  0c d6 3b de
| SK_pi:  cc 07 97 44  b4 a3 4e 8a  0d 2f 27 8b  ee 06 6d 07
|   a5 a5 75 2e
| SK_pr:  e9 00 11 7e  41 d4 31 62  40 b8 63 22  bf 06 9f bc
|   eb 81 58 e7

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

---

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

Michael Richardson wrote:
> I'm looking for some test vectors for SKEYSEED calculation.  I asked 
> google a bit, but I didn't find anything published on the IPsec list. 
> Perhaps there are some materials from one of the bakeoffs.  I wish that 
> we had put some vectors into rfc4306. I saw that there are some vectors 
> in the SHA256 drafts, but I don't think that they give enough detail to 
> confirm that an implementation has done the right thing.

I received a number of replies privately and Tero Kivinen ran my vectors, and 
found problems.
Some other people did too, and didn't find any problems --- I will reply to 
you and let you know --- if you found no problems with my vectors, then your 
code is likely broken too.

My code had two mistakes, of course in the one part which I didn't dump,
which was the key part of the initial SKEYSEED calculation.
(i.e. Ni|Nr)

The first error was a bits vs bytes error, easily corrected.

The second problem is more complex, and I think it represents some under 
specification in rfc4306. (Please tell me if I missed some text)
The under specification may be minor or major, I'm not sure yet.

Part A
The problem is that I didn't know what the key size for MD5 and SHA1 is.
As far as I knew, it was open --- I can use any key size, since
HMAC just prepends the key to the data.  This for me meant that I should
have no problems concatenating Ni|Nr

Part B
However, in order to know how much keying material to generate, and how much 
is going to be SK_d, SK_ai, SK_ar, I need to know how big each one is going 
to be.  For *ESP* the key size of integrity algorithms is MD5,SHA1 = (16 
bytes, 20 bytes).

SK_d is used in prf+ as specified in 2.17. As that is based upon prf, I might 
assume that the "keysize" for prf is like for ESP, i.e. 16 and 20 bytes.

Go back to Part A. If md5 has a 16-byte keysize, then if I provide two 
16-byte nonces (the smallest allowable), then I should take 8 bytes from Ni, 
and 8 bytes from Nr.  Tero's vector clearly didn't do that --- it had 32 
bytes of input, 16 from each nonce.

As I am writing this, I am inserting text from RFC4306, such as below:

This concerns RFC4306 sections 2.13/2.14.

2.13: says:

    We assume that each encryption algorithm and integrity protection
    algorithm uses a fixed-size key and that any randomly chosen value of
    that fixed size can serve as an appropriate key.  For algorithms that
    accept a variable length key, a fixed key size MUST be specified as
    part of the cryptographic transform negotiated.

I understood this to apply to things like AES.
Does this *ALSO* apply to MD5 and SHA1?
Are these considered to be variable length, and we need to include a keysize 
attribute for the *PRF* and *INTEGRITY* options for the PARENT SA?

Section 3.3.5 "Key Length" says that it applies to Encryption Algorithms only.

(Also is it just me, or has the table in 3.3.5, Attribute Type/Value/Format
been word wrapped on us?)

---

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

> have no problems concatenating Ni|Nr

Depends what HMAC-MD5 / HMAC-SHA1 you talk about. For the
AUTH_HMAC_MD5_96, and AUTH_MHAC_SHA1_96 the RFCs 2403 and 2404 clearly
specify that the input key size is 128 bits and 160 bits, and no other
key lengths are supported. For the PRF_HMAC_MD5 and PRF_HMAC_SHA1 the
RFC2104 does NOT specify the key lenght, but says any key lenght is
acceptable.

> to be.  For *ESP* the key size of integrity algorithms is MD5,SHA1 = (16 

That same applies to the SK_ai, and SK_ar, as they use
AUTH_HMAC_MD5_96 / AUTH_HMAC_SHA1_96.

The only problem is the SK_d, i.e. how many bytes of keying material
needs to be generated for the SK_d.

> SK_d is used in prf+ as specified in 2.17. As that is based upon
> prf, I might assume that the "keysize" for prf is like for ESP, i.e.
> 16 and 20 bytes.

That is what implementations do now, and I think that should be
specified in the future documents. 

> bytes of input, 16 from each nonce.

No.

Even when we have some key size associated with the PRF to specify how
many bytes we need to generate when generating key to be used for the
PRF, that does not make the PRF to require fixed size key. It can
still take variable size of key, thus no truncation is done, and full
Ni and Nr are used. 

> I understood this to apply to things like AES.

It does not apply to AES, which is encryption algorithm. It applies to
the RPF_AES128_XCBC which is PRF function. And note there is some
problems with that already (RFC4434 vs RFC 3664). 

> Does this *ALSO* apply to MD5 and SHA1?

No.

> attribute for the *PRF* and *INTEGRITY* options for the PARENT SA?

No. For integrity the key size is fixed by the RFC2403 and RFC2404.
For the PRF the key size is whatever is given to the PRF. The only
thing we should define is the length of the SK_d. 

> Section 3.3.5 "Key Length" says that it applies to Encryption

Yes.

> been word wrapped on us?)

Yes seems to be, should be:

         Attribute Type                 Value        Attribute Format
      --------------------------------------------------------------
      RESERVED                           0-13
      Key Length (in bits)               14                 TV
      RESERVED                           15-17
      RESERVED TO IANA                   18-16383
      PRIVATE USE                        16384-32767
-- 
[email-masked]

---

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

> problems with that already (RFC4434 vs RFC 3664). 

Well, the statement does apply to encryption algorithms (it says say that),
but here, I understand you.. if we negotiated PRF_AES128_XCBC, then are you 
saying that there would have had to be an attribute of "keysize=128" 
included?  It seems that "128" is included in the name of the PRF?

> thing we should define is the length of the SK_d. 

okay, so I'm happy, I generate the same vectors are you.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 27 Nov 2007 16:30:19 +0200

Michael Richardson writes:
> but here, I understand you..

Oh, sorry, I didn't check the where you cut & pasted that text, I
assumed it was from 2.14 i.e. about SKEYSEED generation, but that was
from 2.13 i.e. from generating key material. So that text applies to
all of the things generated out from the SKEYSEED, i.e SK_d, SK_ai,
SK_ar, SK_ei, SK_er, SK_pi, and SK_pr.

> if we negotiated PRF_AES128_XCBC, then are you 

No, we do not need keysize (and cannot have it) in that case, as the
PRF_AES128_XCBC is fixed key length algorith, that only accepts keys
of length of 128 bits, as defined in the section 4.1 of the RFC 3566
referenced from the section 2 of the RFC 3664 referenced from section
3.3.2 transform type 2 table of the RFC 4306.

Note, that it is not whether the underlaying algorithm can accept
variable length keys, it is whether the algorithm used in the IKE can
be used with variable lenght keys. 
-- 
[email-masked]