eap Mailing List: Some (minor) editorial comments on RFC 3748b

[Florent Bersani (florent.bersani]

Hi all,

Below are some (minor) editorial comments that came to my mind while 
reading the latest version of EAP I am aware of (RFC 3748.b).

Much like my comments on the EAP state machine, I know that these 
comments may come much too late :-((

Hence, I included in this mail only the editorial comments that I think 
are (relatively) easy to address (in a mail to come, I'll formalize my 
other technical and general comments on EAP, being aware that they can't 
be taken into account for they come well after the battle)

Comment #1

Section 1.2

Some entries start with a capital letter (e.g. Supplicant, Displayable 
Message, ...) while others do not (authenticator, peer,...).
Suggested change: adopt a constant behavior (namely start all entries 
with a capital letter)

This capitalization problem is all the more shocking with 
"authenticator" because this entry is written "authenticator" and in the 
definition text we may read authenticator with a capital A ("The term 
Authenticator is used in [IEEE-802.1X 
<mailbox:///C%7C/DOCUMENTS%20AND%20SETTINGS/FLORENT/APPLICATION%20DATA/Thunderbird/Profiles/default/rv09wr8p.slt/Mail/Local%20Folders/Drafts?number=59209688#ref-IEEE-802.1X>], 
and has the same meaning in this document.")
Suggested change: adopt a constant behavior for this term throughout the 
document.

Comment #2

Section 1.2

I disagree with the RFC 3748 definition of MIC:
"Message Integrity Check (MIC) A keyed hash function used for 
authentication and integrity protection of data. This is usually called 
a Message Authentication Code (MAC), but IEEE 802 specifications (and 
this document) use the acronym MIC to avoid confusion with Medium Access 
Control."

Keying a hash function is not the only cryptographic way to provide data 
origin authentication and I do not see why EAP mandates such a 
restriction for its MICs.
Suggested changes: either adopt/adapt the IEEE 802.11i definition
"Message Integrity Code (MIC): A value generated by a symmetric key 
cryptographic function. If the input data is changed, a new value cannot 
be correctly computed without knowledge of the symmetric key. Thus, the 
secret key protects the input data from undetectable alteration. This is 
traditionally called a Message Authentication Code, or MAC, but the 
acronym MAC is already reserved for another meaning in this standard." 
(BTW, IEEE 802.11i quite logically mandates MIC/MAC to come from 
symmetric key cryptography since this is how the term MAC is commonly 
used, however it again worth noting that there are asymmetric techniques 
than can also provide data origin authentication - IINM, symmetric 
cryptography is rather used for data origin authentication for 
performance reasons)
or this one "Message Integrity Code (MIC) Informally, the purpose of a 
MIC is to facilitate, without the use of any additional mechanisms, 
assurances regarding both the source of a message and its integrity, 
please refer to [HAC] for more details This is usually called a Message 
Authentication Code (MAC), but IEEE 802 specifications (and this 
document) use the acronym MIC to avoid confusion with Medium Access 
Control." where [HAC] = Menezes, A. et al., “Handbook of Applied 
Cryptography”, CRC Press, 1996.

Comment #3

Section 1.2

Rearrange section 1.2 with the entries sorted in alphabetical order to 
improve readability

Comment #4

Section 5.1 2nd paragraph typo: replace "Some EAP implementations 
piggy-back various options into the Identity Request after a 
NUL-character" with "Some EAP implementations piggy-back various options 
into the Identity Request after a NULL-character" (the typo is on NULL IINM)

Also, it appears that sometimes NULL is capitalized, sometimes it isn't.
Suggested change: adopt a constant behavior

Hope this helps and you aren't upset by my being so particular about EAP 
WG documents,

Florent