Subject: RE: [eap] Comments and questions on draft-jwalker-eap-archie-00.txt

From: "Walker, Jesse" <[email-masked]>
Date: Thu, 28 Aug 2003 11:00:23 -0700

Florent,
 
Thank you for your comments. Here are some response.

Par 2.1 : "secret nonces"
Why is it important that the nonces be secret, which is not IMHO a classic cryptographic setting ?[Walker, Jesse] This is not really necessary. It was done as a mechanism to hide a little bit more entropy that gets mixed into the derived session key. The encryption can be removed if that's what poeple want. Doing so will not harm the security of the protocol.

Par 2.1 : "If the unencrypted nonce value is random"
A nonce can well be a counter (i.e. non-random). The difference may be crucial as explained in your reference [11]
Maybe you should state that your nonces are in addition random values (which you do in Par 6.3.1 "All nonces used by EAP-Archie are 256-bits and are specified as random.") earlier in the draft.[Walker, Jesse] The specification already requires that the unencrypted nonces are random. See, e.g., 4.3.1 and 4.4.1. 

Par 2.5 : "Note that the AES Key Wrap has its own internal integrity check. Potential evidence of compromise of the KCK is the AES Key Wrap integrity check of either NonceP or NonceS fails but the MAC of the Archie message delivering the nonce is valid."
How strong is the integrity check provided by the AES key wrap ?[Walker, Jesse] I haven't seen a careful analysis of the AES key wrap's integrity, so can't answer the question. 
Is this integrity check really useful ? IMHO if a KCK gets compromised, the corresponding LL-Key should immediately be revoked and scenarios in which the KCK gets compromised but not the KEK seem to me somehow unrealistic. [Walker, Jesse] If  folks want to drop encryption of the nonces, then this integrity check won't contribute anything!

Par 6.3.1 : 
I feel quite uncomfortable with your use of [12].
I tend to think that it is not a good idea to raw CBC-MAC variable-length messages (regardless whether you know the lengths of the messages in advance or not). If my maths is still right MAC1, 2 and 3 are calculated over different lengths - which could be by the way stated in the document).[Walker, Jesse]  We are not using CBC-MAC over variable length messages. Each message has a well-defined, fixed length. If we allowed variable length messages then extension attacks against the protocol are enabled. The downside of fixed length messages is that every field in the bindings field must be the maximum size of any value that can occur, whereas in reality most of this space will never be used, so is wasted bits. One way around this problem would be to replace CBC-MAC with, e.g., OMAC. Another approach would be to ditch AES and use something like HMAC-SHA1 instead. That would also address the concern that you raise, which I do not believe is valid.
I don't yet see a damaging attack on CBC-MAC as used in EAP-Archie (maybe there isn't any) but I (conservatively) think the results of [12] do not directly apply and require a little more work to get a proof of EAP-Archie's security.

[Walker, Jesse] I will incorporate all the editorial comments in the next version; thanks. 

-- Jesse

---

From: Florent Bersani <[email-masked]>
Date: Fri, 29 Aug 2003 16:59:26 +0200

Jesse,

Many thanks for your answer, here some remarks to your response :

Walker, Jesse wrote:

Florent,

Thank you for your comments. Here are some
response.

Par 6.3.1 :

I tend to think that it is not a good idea to raw CBC-MAC
variable-length messages (regardless whether you know the lengths of
the messages in advance or not). If my maths is still right MAC1, 2 and
3 are calculated over different lengths - which could be by the way
stated in the document).[Walker, Jesse]  We are not
using CBC-MAC over variable length messages. Each message has a
well-defined, fixed length. If we allowed variable length messages then
extension attacks against the protocol are enabled. The downside of
fixed length messages is that every field in the bindings field must be
the maximum size of any value that can occur, whereas in reality most
of this space will never be used, so is wasted bits. One way around
this problem would be to replace CBC-MAC with, e.g., OMAC. Another
approach would be to ditch AES and use something like HMAC-SHA1
instead. That would also address the concern that you raise, which I do
not believe is valid.

I don't yet see a damaging attack on CBC-MAC as used in EAP-Archie
(maybe there isn't any) but I (conservatively) think the results of
[12] do not directly apply and require a little more work to get a
proof of EAP-Archie's security.

I meant that if you CBC-MAC messages of different lengths with the same
key even if their lengths are fixed, you may be in trouble and the
results of [12] (i.e the security proof) do not apply

Assume for instance that you CBC-MAC with the same key K, messages of
type 1 always consisting of one blocks (fixed length) and messages of
type 2 always consisting  of two blocks (fixed length), then you can
easily forge messages (with what you call extensions attacks) :

if I you get

MAC1 = MAC(a) (a being a one-block message of type 1)

MAC2 = MAC(b) (b being a one-block message of type 2)

then you can forge a MAC for the following two block-message of type 2
: a||(b xor MAC1) (its MAC is indeed MAC2)

(of course, you have to forge messages that make sense for the protocol
but it is a common assumption in cryptography not to rely on such a
weak protection)

My point is just to demonstrate that we cannot use the security proof
of [12], it is quite lucky that the MAC lengths used in EAP-Archie
(1120 bytes, 892 bytes and 36 bytes, if I am right) do not directly
combine neatly - like 1120, 896 and 32 for instance - for an attacker.
Still the door is open for the attacker and we are by no way under the
umbrella of provable security.

I agree with your proposed solutions. As you suggest, why not use a
mode that gives us the security we are looking for : e.g OMAC
(standardized by NIST) (or RMAC, EMAC... - or even MACs like HMAC-SHA1)
?

A nonce can well be a counter (i.e. non-random). The difference may be
crucial as explained in your reference [11]

Maybe you should state that your nonces are in addition random values
(which you do in Par 6.3.1 "All nonces used by EAP-Archie are 256-bits
and are specified as random.") earlier in the draft.[Walker,
Jesse] The specification already requires that the unencrypted nonces
are random. See, e.g., 4.3.1 and 4.4.1.

OK, I had noticed you mentioned that your nonces were in fact random
values. My concern was the confusion that could arise for
non-specialists, which could be damaging if random values are indeed
needed for the security. Maybe adding the following text to the
terminology section (1.2) :

Nonce : A nonce is a (cryptographic) value used at most once within the
same context. A counter or a random (non-repeating) value can be used
as a nonce. In some cases, it is necessary for the security of a
protocol that the nonces be random values and therefore cannot be
predicted.

and the following text at the end of Overview of EAP-Archie (Par 2.1)  :

Note : all nonces within EAP-Archie are supposed to be random values
and thus unpredictable. This is crucial for the security of EAP-Archie

Par
2.5 : "Note that the AES Key Wrap has its own internal integrity check.
Potential evidence of compromise of the KCK is the AES Key Wrap
integrity check of either NonceP or NonceS fails but the MAC of the
Archie message delivering the nonce is valid."

How strong is the integrity check provided by the AES key wrap ?[Walker,
Jesse] I haven't seen a careful analysis of the AES key wrap's
integrity, so can't answer the question.

Is this integrity check really useful ? IMHO if a KCK gets compromised,
the corresponding LL-Key should immediately be revoked and scenarios in
which the KCK gets compromised but not the KEK seem to me somehow
unrealistic. [Walker, Jesse] If  folks want to
drop encryption of the nonces, then this integrity check
won't contribute anything!

I just wanted to understand better the cryptographic properties of the
AES key wrap

Florent

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap