Subject: [eap] issue - method sequence documentation

From: [email-masked] (John Vollbrecht)
Date: Mon, 03 Feb 2003 17:36:14 -0500

Issue:  Wording of some terminology
Submitter: John Vollbrecht - [email-masked]
Date: Feb 3, 2003
Document:draft-ietf-eap-rfc2284bis-00a.txt
Comment: Editorial
Priority: 3
Section: 2.1

Issue:  multiple methods in a sequence

Rationale:

Multiple methods may be used in sequence, some before and some after an 
actual authentication method.  Thus an identity method may precede 
authentication, and a QoS method may follow.  The wording in the RFC should 
not indicate that this is unexpected behaviour.

Also, the details on when a NAK can be sent and what responses should occur 
should be moved to a separate section, or should reference a state machine 
document (rfc or appendix)

Suggested Change
change-

   An EAP conversation MAY utilize a sequence of methods. A common
   example of this is an Identity request followed by a single EAP
   authentication method such as an MD5-Challenge. However, within or
   associated with each EAP server, it is not anticipated that a
   particular named peer will utilize multiple authentication methods
   (Type 4 or greater), either by supporting a choice of methods or by
   using multiple methods in sequence.  This would make the peer
   vulnerable to attacks that negotiate the least secure method from
   among a set (negotiation attacks, described in Section 7.8) or
   man-in-the-middle attacks (described in Section 7.4). Instead, for
   each named peer there SHOULD be an indication of exactly one method
   used to authenticate that peer name. If a peer needs to make use of
   different authentication methods under different circumstances, then
   distinct identities SHOULD be employed, each of which identifies
   exactly one authentication method.  If additional authentication
   methods are required beyond the initial one, the authenticator MAY
   send a Request packet for a subsequent authentication method, or it
   MAY send another Identity request.  If the peer does not support
   additional methods, it SHOULD respond with a Nak, indicating no
   acceptable alternative, as described in Section 5.3.  However, peer
   implementations MAY not respond at all, in which case a timeout will
   result and authentication will fail. Since the authenticator
   presumably requires successful completion of the sequence in order to
   grant access, authentication failure is the correct result.
   Therefore, it is not necessary for the authenticator to determine
   that the peer supports sequences prior to sending a Request for a
   subsequent authentication method.

   The above prescription also applies in the situation where an
   authenticator sends a message of a different Type prior to completion
   of the final round of a given method. If the peer wishes to continue
   authenticating with the method in progress, it SHOULD send a Nak in
   response to such a Request, indicating the Type in progress as the
   alternative.  Otherwise it MAY send a Response with the same Type as
   the Request.  Since an EAP packet with a different Type may be sent
   by an attacker, an authenticator receiving a Nak including a
   preference for the Type in progress SHOULD log the event, but
   otherwise not take any action.

   Once a peer has sent a Response of the same Type as a Request, some
   existing peer implementations might expect the method to run to
   completion. As a result, these implementations silently discard EAP
   Requests of a Type different from the method in progress, despite the
   requirement for a Response in Section 4.1. For this reason, EAP
   authenticators that must interoperate with these peers are
   discouraged from switching methods before the final round of a given
   method has completed.

to-
  An EAP conversation MAY utilize a sequence of methods. A common
  example of this is an Identity request followed by a single EAP
  authentication method such as an MD5-Challenge. Another example
  is an authentication method followed by a method that negotiates QoS
  parameters with the user.  In both cases only one authentication Method 

  is used.
  [Note: it is not considered good practice to allow the peer to
  "negotiate down" the EAP methods that do authentication.  That is,
  trying a different authentication method after failing a method SHOULD
  not be allowed.]

  Sequences are driven by the authenticator end of the EAP connection.
  The authenticator proposes a method by sending an EAP request for that
  Method.  The Peer can accept the method by responding to the request or
  refuse the method by responding with a NAK.

  On completion of one method the authenticator may attempt to initiate
  another method or may signal completion by sending either a Success or
  Failure message.  Success or Failure messages indicate to the peer that
  the sequence is complete and that the authenticator believes the
  sequence has succeeded or failed.

  Note that each end of the EAP connection may independently decide whether 

  to activate the connection, and in particular the peer may decide not to 

  activate the connection based on the results of its EAP methods,
  regardless of the Success or Failure from the authenticator.  This is
  what allow mutual authentication to work.

  Interactions between authenticator and peer in cases where messages are
  lost and retransmitted, where unexpected NAKs or timeouts occur are
  described in section (xxx or rfc xxx state machine).

---

From: [email-masked] (Henrik Levkowetz)
Date: Tue, 4 Feb 2003 15:27:32 +0100

John,

	This change looks fine to me, with regards to the text,
the proposed text is an easier read.

	The requirement 
					"If a peer needs to make use of
    different authentication methods under different circumstances, then
    distinct identities SHOULD be employed, each of which identifies
    exactly one authentication method." 

	which is made in the old text but not in the proposed is covered
under 7.8 Negotiation attacks, and not lost. There are some other
requirements in the old text (mainly SHOULD's) which are not expressed
with requirement language in the new text, but I think that the new text
is ok on this point nevertheless.

        There's one thing, however, I'd like to question:  The reference
to the EAP state machine document in the last proposed paragraph seems
to be normative, and binds the publication of 2284 bis to the
publication of the state machine docment. Is that desireable?

	Henrik

On Mon, 03 Feb 2003 17:36:14 -0500, John Vollbrecht <[email-masked]> wrote:
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

		Henrik

-- 

Henrik Levkowetz +46708321608 [email-masked] www.ipunplugged.com
------------------------------------------------------------------------

  It is impossible for a man to love his wife wholeheartedly without
  loving all women somewhat. I suppose that the converse must be true of
  women. 
    -- Lazarus Long in 'Time Enough for Love'

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 04 Feb 2003 14:50:13 -0500

comment inline
--On Tuesday, February 4, 2003 3:27 PM +0100 Henrik Levkowetz 

> publication of the state machine docment. Is that desireable?

 I think the state machine will not be normative if it is a separate rfc. 
I am wondering if it should not be an appendix to the eap-bis rfc.  what do 
others think?

-- JohnV
> > authentication, and a QoS method may follow.  The wording in the RFC
> > should  not indicate that this is unexpected behaviour.
> >
> > Also, the details on when a NAK can be sent and what responses should
> > occur  should be moved to a separate section, or should reference a
> > state machine  document (rfc or appendix)
> >
> > Suggested Change
> > change-
> >
> >   Method.  The Peer can accept the method by responding to the request
> >   or refuse the method by responding with a NAK.
> >
> >   Failure message.  Success or Failure messages indicate to the peer
> >   that the sequence is complete and that the authenticator believes the
> >   Interactions between authenticator and peer in cases where messages
> >   are lost and retransmitted, where unexpected NAKs or timeouts occur
> >   are described in section (xxx or rfc xxx state machine).
> >
> >
> >
> >
> >