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

From: Florent Bersani <[email-masked]>
Date: Thu, 28 Aug 2003 16:35:04 +0200

Technical Comments

Par 2.1 : "secret nonces"

Why is it important that the nonces be secret, which is not IMHO a
classic cryptographic setting ?

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.

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 ?

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.

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).

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.

6.3.2 : "AES used in CBC-MAC mode provide message integrity against all
other forgery attacks provided AES is not broken [12]"

I think this is not guaranteed by [12] see above

Editorial comments :

Page 1 : Two expiration dates

Remove "Expiration: September 2003"

Par 2.1 : "A successful instance of the Archie protocol establishes a
session, sometimes also called a security association."

Maybe a reference to "draft-aboba-pppext-key-problem-07.txt"
could help stating that this document refers to such an association as
an EAP SA.

Par 2.1 :"MAC1 is
a message authentication code computed over the Archie-Request's AuthID
field and the prior Archie-Response message fields."

There
seems to be a slight inconsistency between this formulation and the
formula of page 17 "MAC1 = AES-CBC-MAC-96(KCK,
Archie-Request(Type...AuthID) | Archie-Response(Type...Binding))"

Par 2.1 : "Binding is the addressing information the EAP Peer believes
it is using during this session. It indicates the identifier the EAP
Peer uses for itself, as well as that of its intended communication
partner, which is typically some sort of Network Access Server (NAS)."

Maybe a concrete example could help (for instance in the 802.11 context)

Par 2.1 : "MAC2 is a message authentication code computed over the
Archie Request's AuthID field, the Archie-Response's NonceP field,
followed by the prior Archie-Confirm fields"

Slight inconsistency (similar to the one for MAC1) with the formula
page 25 "MAC = AES-CBC-MAC-96(KCK, Archie-Request(Type...AuthID) |
Archie-Response(Type...Bindings))"

Par 2.5 : [10] has evolved to "draft-aboba-pppext-key-problem-07.txt",
hence I feel a relabeling is necessary.

In my understanding,

The EAP-Archie long-lived key is the EAP Master Key (MK)

There is no TEK derivation per se within EAP-Archie (they are not
needed)

The Master Session Key and Extended Master Session Key's derivation
procedure need to be respecified

There is no IV derivation

All the other keys (especially the TSKs are out of the scope of
EAP-Archie)

"The derived EMK is uniquely identified by the 5-tuple <AuthID,
PeerID, SessionID, AuthNonce, PeerNonce>, where AuthID is the NAI
the EAP Server presents in the Archie-Request message, PeerID is the
NAI the EAP Peer presents in the Archie-Response message, SessionID is
the random challenge value the EAP Server presents in the
Archie-Request message, and where AutheNonce and PeerNonce are as
above."

This should be changed according to draft-aboba-pppext-key-problem-07.txt
:

EAP SA
name

The EAP security
association is negotiated between the EAP peer and

EAP server, and is uniquely named as
follows <EAP peer name, EAP

server name, EAP Method Type, EAP peer nonce, EAP server
nonce>.

Here the EAP peer
name and EAP server name are the identifiers

securely exchanged within the EAP method.  Since multiple EAP SAs

may exist between an EAP peer and EAP
server, the EAP peer nonce

and
EAP server nonce allow EAP SAs to be differentiated.  The

inclusion of
the Method Type in the EAP SA name ensures that each

EAP method has a distinct EAP SA
space.

MSK
Name

The MSK is named by the
concatenation of the EAP SA name, "MSK" and

the authenticator name, since the MSK may
only be bound to a single

authenticator.  While the AAA
server has several potentially unique

authenticator identifiers (including the NAS-Identifier, NAS-IP-

Address, and NAS-IPv6-Address
attributes), only the Called-Station-

Id is guaranteed to be known by the EAP peer, EAP server and

authenticator and as a result, this is
used as the NAS name.

I suggest inserting a reference to draft-aboba-pppext-key-problem-07.txt
and removing all the text apart perhaps a mapping between the
terminology in EAP-Archie and the terminology in draft-aboba-pppext-key-problem-07.txt
which should be the same

Par 2.5 : "the final 32 octets (512 bits)"

Change to the final 32 octets (256 bits)

Par 4.3.2 : " MAC = AES-CBC-MAC-96(KCK, Archie-Request(Type...AuthID) |
Archie-Response(Type...Bindings))

Change to "MAC2 = ..."

Par 4.4.2 : "MAC = AES-CBC-MAC-96(KCK, Archie-Request(Type...AuthID) |
Archie-Response(NonceP) | Archie-Confirm(Type...Bindings))"

Change to "MAC3 = ..."

Par
6.3.4

Maybe a word on the Binding field could be inserted in this section.

Par 6.4 : See remarks on Par 2.5

Questions :

Where does the name EAP-Archie come from ?

Is there any cryptanalytic analysis of the AES Key Wrap algorithm
available ?

Florent

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