eap Mailing List: [Issue]: IESG DISCUSS comments on RFC 2284bis

[Bernard Aboba (aboba]

Find below Russ Housley's DISCUSS comments on RFC 2284bis.  My
recommendation is that the proposed changes be accepted, with one
exception.  Comments?

-----Original Message-----
From: iesg-admin [at] ietf.org On Behalf Of ext Russ Housley
Sent: Tuesday, December 16, 2003 12:10 PM
To: iesg [at] ietf.org
Subject: DISCUSS: draft-ietf-eap-rfc2284bis-06

draft-ietf-eap-rfc2284bis-06.txt
Extensible Authentication Protocol (EAP) (Proposed Standard)

DISCUSS

   1.  In section 4.3, paragraph [a], the document says: "These MUST
   be pseudo-random, generated by a PRNG seeded as per [RFC1750]."
   While I like RFC 1750 very much, I do not think that a MUST
   statement ought to reference it.  An informative reference is
   better in this case than a normative reference.

[BA] OK.  Suggest rewording to: "These MUST be pseudo-random.  For
discussion of pseudo-random number generation, see [RFC1750]."  Also,
move the reference to informative.

   2.  In section 7.2.1, the definition of 'key strength' is not
   correct.  In a perfect symmetric cipher, the brute force attack is
   the best possible attack.  That is, the attacker must attempt to
   decrypt with each possible key value until the correct one is found.
   On average, half of the key values need to be tried to locate the
   correct one to decrypt a particular ciphertext.  So, on average,
   2^(N-1) operations are needed to attack a key with N bits of
   effective strength.

[BA] OK.

COMMENT

   1.  Please pick one spelling and use it throughout the document:
     - either 'passthrough' or 'pass-through'
     - either 'ad-hoc' or 'ad-hoc' or 'ad hoc'

[BA] Suggest "pass-through" and "ad-hoc".

   2.  In section 1.2, please add the definition of supplicant and
   slightly revise the definition of EMSK as follows:

     supplicant
           The end of the link that responds to the authenticator in
           [IEEE-802.1X].  In this document, this end of the link is
           called the peer.

     Extended Master Session Key (EMSK)
           Additional keying material derived between the EAP client
           and server that is exported by the EAP method.  The EMSK is
           at least 64 octets in length.  The EMSK is not shared with
           the authenticator or any other third party.  The EMSK is
           reserved for future uses that are not defined yet.

[BA] OK.

   3.  In section 1.3, I find the last sentence of the 4th paragraph
   awkward.  I propose the following rewording:

     As a result, it may be necessary for an authentication algorithm
     to add one or two additional messages (at most one roundtrip)
     between the client and authenticator in order to run over EAP.

[BA] OK.

   4.  In section 2.4, 1st paragraph, last sentence, the term
   'authenticatees' is introduced.  I think that 'peers' should be used
   instead.  This leads to a problem because 'peers' is used elsewhere
   in the sentence.  Proposal:

     Both ends of the link may act as authenticators and peers at
     the same time.

[BA] OK.

   5.  In section 3.2, 1st paragraph, 1st sentence: s/must/MUST/

[BA] This sentence refers to PPP, and making the statement normative
would in effect be a change to RFC 1661.  This seems inappropriate to me.

   6.  In section 4.2, 7th paragraph at the top of page 25, 1st
sentence,
   I cannot figure out what the sentence means:

     A mutually authenticating method (such as EAP-TLS [RFC2716]) that
     provides authorization error messages provides protected result
     indications for the purpose of this specification.

[BA] I think this means that in TLS, the server indicates to the client
that it will provide access when it sends a FINISHED message, without
having previously sent a TLS alert to indicate that the client is
unauthorized.

The client indicates that it will accept the access by indicating that
it has authenticated the server certificate and continuing the
conversation to its conclusion.  So both sides have knowledge of their
own decision as well as the decision of the other side.

   7.  In section 7.11, 2nd paragraph, last sentence:
   s/recommended/RECOMMENDED/

[BA] OK.