eap Mailing List: Proposed resolution to Issue 207: IESG comments on RFC 2284bis-07

[Bernard Aboba (aboba]

The text of Issue 207 is enclosed below.  The proposed resolution is as
follows:

Change "passthrough" to "pass-through" throughout the document.

Change "ad-hoc" to "ad hoc" throughout the document.

In Section 2.1, add the following definition:

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.

Change the definition of the EMSK to the following:

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

In Section 1.3, change the 4th paragraph from:

" EAP authentication is initiated by the authenticator, whereas many
authentication protocols are initiated by the client (peer). As a
result, it may be necessary for an algorithm to add 0.5 - 1
additional roundtrips between the client and authenticator in order
to run over EAP."

To:

" EAP authentication is initiated by the authenticator, whereas many
authentication protocols are initiated by the client (peer). As a
result, it may be necessary for an algorithm to add one or two
additional messages (at most one roundtrip) between the peer and
server in order to run over EAP."

In Section 2.4, first paragraph, change:

"Both peers may act as authenticators and authenticatees at the same time,
in which case it is necessary for both peers to implement EAP
authenticator and peer layers."

To:

"Both ends of the link may act as authenticators and peers at the same
time. In this case it is necessary for both ends to implement EAP
authenticator and peer layers."

In Section 3.2, 1st paragraph, change:

" In order to establish communications over a point-to-point link, each
end of the PPP link must first send LCP packets to configure the data
link during Link Establishment phase."

To:

" In order to establish communications over a point-to-point link, each
end of the PPP link first sends LCP packets to configure the data
link during Link Establishment phase."

In Section 4.3, paragraph [a], change:

"These MUST be pseudo-random, generated by a PRNG
seeded as per [RFC1750]."

To:

"These MUST be pseudo-random. For a discussion
of pseudo-random number generation, see [RFC1750]."

Change the reference to [RFC1750] to Informative.

In Section 7.2.1, change:

"The effective key strength SHOULD be stated as number of bits,
defined as follows: If the effective key strength is N bits, the
best currently known methods to recover the key (with
non-negligible probability) require an effort comparable to 2^N
operations of a typical block cipher."

To:

"The effective key strength SHOULD be stated as number of bits,
defined as follows: If the effective key strength is N bits, the
best currently known methods to recover the key (with
non-negligible probability) requires on average an effort
comparable to 2^(N-1) operations of a typical block cipher."

In section 7.11, change 2nd paragraph from:

" As a result, as noted in Section 3.1, where EAP is used over a
physically insecure lower layer, per-packet authentication, integrity
and replay protection SHOULD be used, and per-packet confidentiality
is also recommended."

To:

" As a result, as noted in Section 3.1, where EAP is used over a
physically insecure lower layer, per-packet authentication, integrity
and replay protection SHOULD be used, and per-packet confidentiality
is RECOMMENDED."

In Section 4.2, 7th paragraph, change:

" A mutually authenticating method (such as EAP-TLS [RFC2716]) that
provides authorization error messages provides protected result
indications for the purpose of this specification. Within
EAP-TLS, the peer always authenticates the authenticator, and may
send a TLS-alert message in the event of an authentication
failure. An authenticator may use the "access denied" TLS alert
after successfully authenticating the peer to indicate that a
valid certificate was received from the peer, but when access
control was applied, the authenticator decided not to proceed. If
a method provides authorization error messages, the authenticator
SHOULD use them so as to ensure consistency with the final access
decision and avoid lengthy timeouts."

To:

"If a mutually authenticating method supports error messages,
then the peer and server SHOULD use them to provide
protected result indications. This ensures that the peer
and server are aware of each other's final access decision,
and prevents lengthy timeouts.

For example, within EAP-TLS [RFC2716], the peer
always authenticates the server, and sends a TLS alert message
in the event of an authentication or authorization failure.
If the server does not receive a TLS alert message from the
peer and the peer continues the conversation
to completion, then the server can assume that the peer
will accept access if granted it by the server.

Similarly, the peer can assume that the server will grant
access if it does not receive a TLS alert message from the
server, and the server carries the conversation to completion.

A server may use the "access denied" TLS alert
after successfully authenticating the peer to indicate that a
valid certificate was received from the peer, but when access
control was applied, the server decided not to proceed."

------------------------------------------------------------------------
Issue 207: IESG comments on RFC2284bis-07
Submitter name: Russ Housley
Submitter email address: housley [at] vigilsec.com
Date first submitted: 12/15/2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-December/002003.html
Document: RFC 2284bis-07
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

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.

   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.

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'

   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.

   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.

   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.

   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.

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