This is very interesting and potentially useful. Note that the RFC
probably comes out sometime in January, so if you have some way of
verifying (e.g., to another implementation) before then, perhaps we
could argue for this to be added to an appendix. And its always possible
to publish a very simple second RFC that just contains the test vectors.
I can agree to take care of the practical details of that, if someone
provides the actual data.
Jari
Jouni Malinen wrote:
On Tue, Nov 11, 2008 at 08:55:36AM +0200, Jari Arkko wrote:
Yes, that is the question. I do not myself have an implementation yet. I
know people are working on one, but without an implementation I'm not sure
I can provide test vectors.
This may be a bit late for the RFC, but how about something like the
following text? A small disclaimer is in order, though: I haven't
checked the correctness of the implementation yet (i.e., these are the
results from more or less the first developer test run when my own
server and peer implementation managed to complete negotiation), so I
would obviously appreciate it if someone could verify whether they get
the same results. Likewise, I would be interested in running an interop
test with another implementation to verify that I've interpreted the
draft correctly for areas that do not show up that easily in just
comparing test vectors. If I didn't miss anything, I think I now have
most of the draft implemented apart from the use of AT_BIDDING in
EAP-AKA since IANA does not appear to have allocated an attribute value
for it yet.
EAP-AKA' (draft-arkko-eap-aka-kdf-10.txt)
Test USIM with parameters from 3GPP TS 35.208 v6.0.0 4.3.20 Test Set 20
(Milenage):
IMSI="232010000000000"
Ki=90dca4eda45b53cf0f12d7c9c3bc6a89
OPc=cb9cccc4b9258e6dca4760379fb82581
AMF=61df
Full authentication
-------------------
Identity: "0232010000000000"
RAND=93919412b4f77039967312e67c8fa082
AUTN=b475f7abb53e61dfde33aa7e70a35faf
IK=e0f3d116c8e47b7304aaa43847f240ad
CK=0f894edd1b37b9f7fd52dbd1ac97986a
RES=f28f28e92bd22166
AK=b475f7abb46a
SQN=000000000154
(CK',IK') = F(CK, IK, <access network identity>)
(based on 33.402 CR 0033 to v8.1.1)
CK: 0f894edd1b37b9f7fd52dbd1ac97986a
IK: e0f3d116c8e47b7304aaa43847f240ad
FC = 0x20
P0 = Access network identity: "WLAN" (574c414e)
P1 = SQN xor AK: b475f7abb53e
Key = CK || IK: 0f894edd1b37b9f7fd52dbd1ac97986ae0f3d116c8e47b7304aaa43847f240ad
KDF output (CK' || IK'):
6836dd1eddcc8abd29ce2e664753ed7718105327f8a5c98bdc10360dc8ccef5b
CK': 6836dd1eddcc8abd29ce2e664753ed77
IK': 18105327f8a5c98bdc10360dc8ccef5b
Selected identity for MK derivation: "0232010000000000"
MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
K_encr: 12c66e38118369dc388c08c9d8af2f73
K_aut: 53fcca89940b9a8802e19bde730cc4497d21a2070ca140b4fe0f018961b48337
K_re: e5cfeb09ad34f0b47c4c880dfd4958bd0a1d71aa6bbbb82c319b9e91ddb86761
MSK:
9085aad974d3323a96fa68c0db54afdc538744f26f8c33869199d1e09bf081ed0d85bdd4b8136cff0f59ce83840587211d5988a69a60b3323e2bc8ecc46678e1
EMSK:
439a9fb8300f33628882f9d0ca101d34b0c1ffb7806c597ea37ac0f949efa59e2b10e4b6263893f98249ffcdcaef12ed4b6e24a498d019a5bb4b9e54f8989e37
NEXT_PSEUDONYM="28c179b81ab38747021e2"
NEXT_REAUTH_ID="4ec9a95ae5b8deaceb0d8"
Fast re-authentication
----------------------
Identity: "4ec9a95ae5b8deaceb0d8"
COUNTER: 1
NONCE_S: 2a949450a95d31eaa2a4f6ea9faaa56c
MK = PRF'(K_re,"EAP-AKA' re-auth"|Identity|counter|NONCE_S)
MSK:
c2ad95db83cfbd1b886d3c91f355d321903107f9e77377671d1b2772ed1c475c36b92a1d07dca082962b83ac7d6cd70ef024d4cf2f4ce97716e15f9fa4fb934c
EMSK:
229a30ae81329be2516da975335a7d95956f8a9524548845b97a89778e18f98bd901cb33fa3389add3f29eb1b671af338744a8b9219715fbb96f8a20d724bd88
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
