Subject: [eap] issue: counter length (review of eap-keying-08 by mats naslund)

From: Jari Arkko <[email-masked]>
Date: Thu, 01 Dec 2005 07:30:12 +0200

Submitter name: Mats Naslund
Submitter email address: [email-masked]
Reference: (this email)
Document: Keying Framework
Comment type: T
Priority: 1
Section: multiple
Rationale/Explanation of issue:

Lower Layer
     The lower layer Secure Association Protocol MUST generate a fresh
     session key for each session, even if the keying material and
     parameters provided by EAP methods are cached, or the peer or
     authenticator lacks a high entropy random number generator.  A
     RECOMMENDED method is for the peer and authenticator to each
     provide a nonce or counter of at least 128 bits, used in session
     key derivation.

MN: If it is a counter, I don't see why it needs to be 128 bits...
Only a few bits will change anyway each time a new key is generated.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 30 Nov 2005 22:51:42 -0800

For a random nonce, large size makes sense so as to avoid replay.

For a counter, it need only be as large as the maximum number of TSK rekeys 
to be supported.

For example, if only 256 rekeys were to be supported, the counter could only 
be 8 bits, right?

The point is that this is a rekey counter, not a packet replay counter.

>From: Jari Arkko <[email-masked]>
>To: [email-masked]
>CC: "Mats Näslund (KI/EAB)" <[email-masked]>
>Subject: [eap] issue: counter length (review of eap-keying-08 by 
>matsnaslund)
>Date: Thu, 01 Dec 2005 07:30:12 +0200
>