Subject: [eap] Notes on rfc2284bis-02

From: [email-masked] (David Reeder)
Date: Thu, 7 Mar 2002 19:07:28 -0500

I am relatively new to this discussion, apologies if any of the
following issues have already been treated or solved.  My sense is
EAP is a work in progress and that some of the following obseravtions
may be useful.  Most are well-contained notes about the details in
the draft.

ISSUE #1 -- Request/Response Type namespace:

  Advisable to introduce some growing room in the Type namespace
  given at the top of Section 5 ("Initial EAP Request/Respose
  Types").  Types 1-3 are EAP control messages, wherease Type 4 is
  the beginning of the list of authentication types.

  Clearly EAP is yet incomplete and is likely to grow (possibly in
  state, operational details and header fields).  Why not set the
  first authentication type at some higher number (25? 50?).  This
  leaves room for new control types.  Eg, new Types may be needed
  for key management.

ISSUE #2 -- NAK lists ordered alternatives:

  Would it be conveient for the NAK (Section 5.3) to return an
  ordered list of authentication types, instead of just one?  Thus
  both the Peer and Authenticator have more choice as the list of
  authentication types grows.  The list might provide an indicator of
  security/access policy -- eg, specify a list such as: #1 IKE, #2 
  OTP, #3 MD5-Challenge.  The Authenticator could immediately
  downgrade to #3 if it is too busy and SLA with the Peer allows it.

ISSUE #3 -- Multi-message authentication exchanges:

  It is not clear how EAP will handle Request/Response Types which,
  themselves, consist of multi-message exchanges.  Eg, IKE requires
  3-6 messages.  Is Code "Request" always used for messages initiated
  by the Authenticator, and Code "Response" for all messages from the
  Peer?  How does the identifier change (or not) during the exchange?
  Assume that it does not change and instead rely on sequence numbers
  within the given authentication protocol?

ISSUE #4 -- Peer plays active as well as passive role:

  Seems like there should be a clear means for Peer to initate an
  exchange with Authenticator, rather than having to wait for a
  Request.  This is most important if (eg) a mobile device wishes to
  have mutual authentication with an access router even though they
  share no other acceptable authentication method besides MD5-Challenge.

  More sophisticated authentication methods (IKE, TLS) support mutual
  authentication no matter who begins the exchange, so this may not
  be a problem in those cases.  Though if it is arbitrary who begins the
  exchange for these methods, it could be convenient for the Peer to
  begin the exchange once it detects (eg) an access router advertisement.

ISSUE #5 -- Division of labor with PANA WG:

  There appears to be important overlap between the charters of the
  PANA and proposed EAP WGs.  (Not to mention other WGs such as
  IPSRA.)  This overlap may be removed by collapsing one group into
  the other, or by clearly distinguishing the role of each.

  Seems like WG roles might be distinguished very simply:

    . PANA is concerned with the transport layer(s) of EAP; 
    . EAP is concerned with everything else, and is transport agnostic.

  Following this guideline, PANA should defer any questions about
  security (key management, replay protection, &c), protocol state
  machines, retry mechanisms and robustness of the authentication
  exchange to EAP.  EAP should, in turn, defer any interactions
  between itself and the layer at which it is transported to PANA.

  Acting on such guidelines would significantly shrink the PANA
  charter, and in turn, possibly indicate that Section 3
  ("Media-specific issues") be separated out of the BIS draft into a
  separate document for further specification and maintenance by PANA.

david

 ..........................................................................
  David Reeder   908/947-7075                     804a 2990 2490 47c3 8ef1  
  <[email-masked]>                           23be 39ce d1f5 56c0 a5c5

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 7 Mar 2002 16:48:10 -0800 (PST)

> may be useful.  

Actually, RFC 2284 is an IETF Proposed Standard, and thus is not a "work
in progress". As a result, RFC 2284bis is about clarifying the
specification while remaining backwards-compatible with RFC 2284. So this
is not a "greenfield" effort. 

>   Why not set the
>   first authentication type at some higher number (25? 50?). 

Because changing existing authentication types would be incompatible with
RFC 2284, and existing Method Types allocated by IANA. 

>   ordered list of authentication types, instead of just one?  

This might be possible while retaining backward compatibility, as long as
existing implementations won't discard the NAK packet as a
result. This would imply that a peer sending a list of authentication
types in the NAK, instead of just one, might get back a type it didn't put
in the list, because the other implementation only read the first NAK type
and didn't go farther. 

>   themselves have multiple roundtrips. 

Existing EAP methods handle this today. See RFC 2716 for an example. 

>   Is Code "Request" always used for messages initiated
>   Peer?  

Yes. 

>   How does the identifier change (or not) during the exchange?

We could use more detail on this, I think. Most implementations I have
seen increment the Identifier. 

>   within the given authentication protocol?

Some protocols do use "Parts" but I have so far not seen sequence numbers. 

>   Request.  

EAP is a peer-to-peer protocol. So it's quite feasible for one party to
initiate to the other or vice versa. In other words, there's no reason
that a NAS couldn't be a peer, and a host couldn't be the authenticator. 

>   This is most important if (eg) a mobile device wishes to

Since EAP is peer to peer, it's quite feasible for each side to do an
MD5-Challenge authentication to the other (although you have to be wary of
reflection attacks). 

>  EAP is concerned with everything else, and is transport agnostic.

One of the goals of RFC 2284bis is to lay out the requirements that EAP
has on the lower layers, and make the protocol more media
independent. Assuming this can be achieved, then other WGs and
standards bodies can successfully adapt EAP for use with other media and
transports. 

An example of some of the problems we have in this regard are the RFC 2284
references to "alternate indications" of success/failure. These are
problematic because not all lower layers provide these indications; also
the implementation surveys indicate that few if any implementations
actually take these indications into account. However, the lack of an ACK
for Success/Failure packets was built on the assumption that "alternate
indications" would be available. Thus the discussion about creating new
ACK'd EAP Types for Success and Failure. 

>   exchange to EAP.  

I think that makes sense. We already have enough trouble rationalizing
a potential EAP state machine with the 802.1X state machine. Thankfully,
Bill Arbaugh's group at University of Maryland has signed up to tackle
this. Creating yet another potentially incompatible state machine would
make their job that much harder. 

>   EAP should, in turn, defer any interactions

I suspect that PANA is not concerned about EAP transport over *all* lower
layers, just IP, correct? 

>   separate document for further specification and maintenance by PANA.

I'm not clear why PANA would be concerned with how EAP is transported over
PPP and IEEE 802. Can you explain?