Subject: [eap] Some (minor) editorial comments on RFC 3748b

From: Florent Bersani <[email-masked]>
Date: Thu, 10 Jun 2004 10:00:36 +0200

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
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 10 Jun 2004 12:54:35 +0200

Hi Florent,

    You're rather impressive in your ability to see mistakes in details,
aren't you! :-)

On Thursday, 10 Jun 2004, Florent Bersani wrote:
...
> Authenticator is used in [IEEE-802.1X], 

Proposed change:
Section 1.2, para. 2:
OLD:

   authenticator
      The end of the link initiating EAP authentication.  The term
      Authenticator is used in [IEEE-802.1X], and has the same
      meaning in this document.

NEW:

   authenticator
      The end of the link initiating EAP authentication.  The term
      authenticator is used in [IEEE-802.1X], and has the same
      meaning in this document.

> I disagree with the RFC 3748 definition of MIC:
....

Someone else will have to take a position on this one, I can't argue
strongly either way.

> Rearrange section 1.2 with the entries sorted in alphabetical order to 

I'd rather not do this now...

> into the Identity Request after a NULL-character" (the typo is on NULL IINM)

Nope, here the name of the ASCII character is "NUL", not "NULL".  Other
places in the document the term "null" is used as a term in itself, and
then I've spelled it "null", indeed.  There's one place where I've missed
this distinction though, giving this correction:
 
Appendix A., para. 12:
OLD:
 
    o  It is now required in Section 5.1 that if the Type-Data field of
       an Identity Request contains a null character, only the part
       before the null is displayed.  RFC 2284 prohibits the Null
       termination of the Type-Data field of Identity messages.  This
       rule has been relaxed for Identity Request messages and the
       Identity Request Type-Data field may now be null terminated.
 
NEW:
 
    o  It is now required in Section 5.1 that if the Type-Data field of
       an Identity Request contains a NUL-character, only the part
       before the null is displayed.  RFC 2284 prohibits the null
       termination of the Type-Data field of Identity messages.  This
       rule has been relaxed for Identity Request messages and the
       Identity Request Type-Data field may now be null terminated.

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

    Sooner (during last call, for instance :) would have been better,
but now is better than never, as far as I'm concerned.  No upsets.

	Regards,

		Henrik

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Jun 2004 14:00:58 +0300

Hi,

I agree with the edits that Florent and Henrik
propose below. I don't think we should change the
MIC definition, or rearrange text parts (comment #3)
now.

--Jari