From aboba@internaut.com Sun Dec 1 03:16:29 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 30 Nov 2002 19:16:29 -0800 (PST) Subject: [eap] Request for presentations -- and draft minutes Message-ID: The draft minutes of IETF 55 EAP WG are available at: http://www.drizzle.com/~aboba/EAP/EAP-notes.txt Presentations are at: http://www.drizzle.com/~aboba/EAP/eap55.zip If you haven't already sent your presentation to me and Jari, please do. From aboba@internaut.com Mon Dec 2 21:22:37 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 2 Dec 2002 13:22:37 -0800 (PST) Subject: [eap] Wireless LAN Certificate Extensions to PS (fwd) Message-ID: FYI, this may be of interest to EAP WG members, since this draft affects the contents of certificates used in EAP TLS (RFC 2716). ==================================================================== To: IETF-Announce: ; Subject: Last Call: Wireless LAN Certificate Extensions and Attributes to Proposed Standard From: The IESG Date: Mon, 02 Dec 2002 13:31:56 -0500 Cc: ietf-pkix@IMC.ORG Reply-to: iesg@ietf.org Sender: jhargest@cnri.reston.va.us -------------------------------------------------------------------------------- The IESG has received a request from the Public-Key Infrastructure (X.509) Working Group to consider Wireless LAN Certificate Extensions and Attributes as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2002-12-16. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-03.txt From aboba@internaut.com Sat Dec 7 01:07:31 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 6 Dec 2002 17:07:31 -0800 (PST) Subject: [eap] New keying draft Message-ID: An updated strawman version of the EAP keying draft is now available at: http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-04.txt Comments welcome. From aboba@internaut.com Tue Dec 10 05:45:20 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 9 Dec 2002 21:45:20 -0800 (PST) Subject: [eap] P802.1aa/D4.1 Ballot - Disapprove (fwd) In-Reply-To: Message-ID: A reminder that the IEEE 802.1aa D4-1 ballot is now running. Even if you are not a voting member of the IEEE 802.1 task group, you can still read the document and send in your ballot comments in order to ensure that IEEE 802.1X-2003 is aligned with RFC 2284bis. Find enclosed an example ballot with some example comments from a non-voting member (me). Ballots can be mailed to stds-802-1@ieee.org. Access has been granted to the IEEE 802.1 archive for use by the EAP WG, as folows: http://www.ieee802.org/1/mirror/8021/aa-drafts/d4/802-1aa-d4-1.pdf userid: p8021 password: go_wildcats On Mon, 9 Dec 2002, Bernard Aboba wrote: > P802.1aa/D4.1 EMAIL BALLOT > 20th November 2002 > TO: Tony Jeffree > Editor, P802.1aa > SUBJECT: P802.1aa/D4.1 - Network Port Authentication > > _____ 802.1 Voting Member > __X__ I Disapprove (must attach binding comments below) > > Bernard Aboba > aboba@internaut.com > > ------------------------------------------------------------------------ > INCLUDE COMMENTS BELOW THIS POINT > > NAME: Bernard Aboba > COMMENT TYPE: T > CLAUSE: 6.6 > PAGE: 20 > LINE: 16 > COMMENT START: > Not sure what the implication is here. EAP has long supported > peer to peer operation as is described in this section so that > the authentication may be initiated by either party or both. > So I'm not clear how this would result in a mutually authenticating > EAP method being unsupported by 802.1X. > COMMENT END: > SUGGESTED CHANGES START: > Change the entire section to: > > "The model of operation of 802.1X is one where the Supplicant > is authenticated by the Authenticator, with the help of the > Authentication Server function. In situations where bi-directional > authentication is needed between a pair of systems connected by a > common LAN segment, it is necessary for each system to adopt both > Authenticator and Supplicant roles; operating as an Authenticator > in order to authenticate the other system, and as a Supplicant in > order to be authenticated by the other system. > > For example, this can be required within IEEE 802.11 in order to > support adhoc authentication. Alternatively it may be desirable to > protect a Bridged LAN from the attachment of additional unauthorized > Bridges, and for the additional Bridges to protect themselves against > being attached to an unauthorized Bridged LAN. In this case it would > be appropriate for the Bridges to implement both Authenticator and > Supplicant functionality. When two Bridges, A and B, first connect > to each other, they would both initiate authentication exchanges. > Once Bridge A successfully authenticates Bridge B, Bridge A's > controlled Port would be authorized; however, data transfer between > the Bridges can only take place once Bridge B has successfully > authenticated Bridge A, resulting in Bridge B's controlled Port > being Authorized. > > Note that systems supporting bi-directional authentication need > to be prepared for role reversal. That is, after completing > authentication in one direction, the system formerly operating > as an Authenticator may receive an EAP-Request from the system > formerly operating as a Supplicant, indicating the desire to > reverse the direction of authentication. > > Systems supporting bi-directional authentication typically authenticate based on > locally stored credentials, using a locally implemented authentication method, > so that they may operate without requiring assistance from backend authentication > servers. However, this need not necessarily be the case. It is even possible, though > uncommon, for a Supplicant to be assisted by a backend authentication server, so > that an EAP-Request could be encapsulated within an Access-Request, and > answered by an EAP-Response encapsulated within an Access-Response. This is > permitted by RFC 2869bis, though support is optional on the backend authentication > server. > > Note also that from the point of view of security, two one-way authentication exchanges in > each direction are not equivalent to a single mutual authentication exchange, since > the two one-way authentication exchanges are not cryptographically bound together. > For example, two EAP MD5 exchanges in each direction are vulnerable to man-in-the-middle > and reflection attacks, whereas a single mutually authenticating exchange would not > be, assuming that it derives a key that remains uncompromised by the attacker." > SUGGESTED CHANGES END: From aboba@internaut.com Wed Dec 11 16:58:44 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 11 Dec 2002 08:58:44 -0800 (PST) Subject: [eap] Minutes of the 12/11/02 ESTEEM Conference call Message-ID: Date: Wednesday, December 11, 2002 Time: 8 AM PDT Present: Bernard Aboba, Jari Arkko, Bob Moskowitz, John Vollbrecht, Paul Congdon, Glen Zorn, ? Scribe: Jari Arkko 1. Preliminary discussion This was the first meeting after IETF 55. Based on looking at the state machine drafts, they look good but not all design team decisions are yet adopted in them. The two drafts are being merged into one and some more issues are resolved in them at the same time. IEEE 802.1aa ballot may affect state machine. We encourage people to read the document and comment. 2. Discussion of EAP issues http://www.drizzle.com/~aboba/EAP/eapissues.html - 43: Security properties Jari: Worry about requireing proofs. Bernard: Yes, it may not be desireable. DECISION: We should encourage people to include references to proofs and other analysis, but not require proofs. Jari to write alternative text. Bernard: Is the text on dictionary attack sufficient? Glen: Does not sound too good yet. Bernard: Even liveness doesn't prove resistance. Glen: Last part makes sense. Jari: I would just put in that the spec must describe whether you are vulnerable to dictionary attacks. Glen: There is a difference between dictionary attack to a weak password vs. a method. DECISION: The following text can be used: Assuming there is a weak password in the secret, does the method allow a an attack better than brute force? John: There is a further distinction between off-line and on-line attacks. DECISION: Let's not describe different variants of dictionary attacks, instead reference text books on the subject. Key strength determination: How do we count key strength, do we count cleartext nonces during EAP TLS negotiation to the entropy? There is some counter-intuitive input on this subject from known cryptographers. It is unclear if adding a PRF function will create additional entropy or not. DECISION: Bernard will ask the cfrg IRTF group what a good definition of key strength is, but we will not give a full definition in the specification. - 2 Alternative indications Bernard has new text on the issue site. Question: If after receiving a protected success indication within a method, do you accept unprotected failure after the method has completed? Bernard: The current text prevents you only from spoofing a success. If the method has not completed, you will throw both failure and success indications away. How all this is handled must be described in the state machines. Also, within a tunnel are the state machines separate or joined? Bernard: We should think them as a single state machine. Bernard: There are two issues here: whether the methods are completed or not, and whether the methods have sent their success/failure indications to the other side. DECISION: If the method hasn't told the EAP mux layer that its done, the failure/success indications will be thrown away. Bernard: A method will just tell the mux when it is done. It may not know exactly about its success, but it indicates that it has completed succesfully. If a method says success (e.g. within PEAP) and after that an unprotected failure comes, what then? Jari: It is enough with the current text and protecting the success. Protecting the failure may not make sense as there are other DoS attacks in any case, e.g., on the methods. Bernard: Is the primitive for completion just for my own success, or do we indicate also the other side's success? If we indicate the peer's success, then we could avoid spoofed failures. Jari: However, if we are running a sequence of methods, then it is no longer clear when a failure can be accepted. One possible semantics is that the protected indication applies only to what follows the protected method immediately -- but not what happens after the method. However, an attacker who can inject messages can always cause DoS by sending random messages, sending only the first message of a method etc. DECISION: We will provide an indication from a method for both our own completion as well as the peer's completion. - 25: Spoofing and duplicate detection This attack is like attacking TLS TCP, but easier since the sequence number space is smaller in EAP. Is there a difference in EAP methods as to how they want to receive their messages, either letting the Mux handle the sequencing or doing it by themselves using some kind of integrity protection to avoid these attacks. This is analogous to the TLS over TCP vs. IKE situation. Should we have a primitive from the method to the mux which says 'take me back to the previous sequence number'? This is also related to retransmission of broken packets. DECISION: We should have a primitive for tossing out messages that fail integrity protection. There's also a timing issue: What if the real message arrives during the integrity verification? DECISION: The state machine must act in a lock-step; the EAP mux will not handle any new messages before the method processing has indicates that the previous message has been either processed or thrown away. - 41: NAK of extended types This is has proven to be complicated if you mix regular and extended types. Bernard proposes that we only allow one kind of types in NAK.DECISION: We will allow NAK of 1 or more regular types OR a NAK of one vendor. From paul@funk.com Thu Dec 12 00:40:57 2002 From: paul@funk.com (Paul Funk) Date: Wed, 11 Dec 2002 19:40:57 -0500 Subject: [eap] Minutes of the 12/11/02 ESTEEM Conference call In-Reply-To: Message-ID: <4.1.20021211192046.02734c40@mail.funk.com> At 08:58 AM 12/11/02 -0800, Bernard Aboba wrote: ... > - 41: NAK of extended types > > This is has proven to be complicated if you mix regular and > extended types. Bernard proposes that we only allow one kind of > types in NAK.DECISION: We will allow NAK of 1 or more regular > types OR a NAK of one vendor. I don't think this is the right decision. This creates two classes of EAP protocol, one which supports negotiation and one which doesn't. It is a recipe for confusion, and vendors will be forced to create their own mechanisms as workarounds. Also, if there is any reality to the fear of a stampede for types under 255, this decision could set it off. Remember, too, that one of the "vendors" is type 0, which provides an extension space for IETF protocols. Do we really want to say that IETF protocols over 255 aren't easily negotiated? As requested during the Atlanta meeting, I sent in a proposal which I believe solves the problem. There hasn't been discussion of it on the list; I don't know if it was discussed in the conference call. I don't consider it complicated; in fact, I think it clarifies the relation between one-octet types and types in the extended 8-octet space. It preserves all the functionality of EAP negotiation for all types. "Type space extension" is part of the charter of this group, and arguably its most important mission. The type space can be extended seamlessly while respecting legacy implementations. I don't see why we'd want to stop half-way to a full solution. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From aboba@internaut.com Thu Dec 12 00:01:05 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 11 Dec 2002 16:01:05 -0800 (PST) Subject: [eap] Minutes of the 12/11/02 ESTEEM Conference call In-Reply-To: <4.1.20021211192046.02734c40@mail.funk.com> Message-ID: > As requested during the Atlanta meeting, I sent in a proposal which I > believe solves the problem. There hasn't been discussion of it on the > list Can you resend it? I don't recall seeing it come through. From paul@funk.com Thu Dec 12 01:20:58 2002 From: paul@funk.com (Paul Funk) Date: Wed, 11 Dec 2002 20:20:58 -0500 Subject: [eap] Proposed resolution of issue #41 Message-ID: <4.1.20021211201759.02736ae0@mail.funk.com> --=====================_-1203455317==_.ALT Content-Type: text/plain; charset="us-ascii" Bernard asked me to resend this; it may not have reached the entire list. Paul -------------------------- Here is a proposed resolution of issue 41 - Nak of extended types. One thing I learned while writing this proposal: the past tense of Nak is "Nak'd", not "Naked". Out-of-scope changes -------------------------------- I've taken some liberties that go beyond the scope of this issue. Feel free to change things back to the way they were if there are objections: 1 I changed 255 to 254, on the theory that experimental use of EAP using type 255 is legacy behavior that should not be broken. 2 The original Vendor-specific type has everything after the Vendor-Id defined by the vendor, with the suggested format of Vendor-Type immediately following (RADIUS-style). I changed that to make the format uniform (Diameter-style), so all v-s types have a fixed format that includes Vendor-Type and are thus interpretable by anyone. Since Vendor-type is used as part of the protocol when Nak'ing, it's best to make sure everyone uses it the same way. I don't believe this limits vendor flexibility. Interesting implications of this proposal --------------------------------------------------------- Note that by using single-octet types and vendor-specific types in an interchangeable way, it is possible to extend EAP in all kinds of ways without breaking backward-compatibility. For example, if the authenticator starts the conversation with a vendor-specific type (as indicated by the first byte being 254), a legacy peer would Nak but a new peer could respond with a vendor-specific type (possibly a v-s Nak). Once both parties are talking vendor-specific, anything is possible. For example, the issue of bi-directional success and failure packets could be solved within this context. Proposed Text --------------------- 5.5. Vendor-specific Description Due to EAP's popularity, the original Method Type space, which only provides for 255 values, is being allocated at a pace, which if continued, would result in exhaustion within a few years. Since many of the existing uses of EAP are vendor-specific, the Vendor-Specific Method Type is available to allow vendors to support their own extended Types not suitable for general usage. The Vendor-specific type is also used to expand the global Method Type space beyond the original 255 values. A Vendor-Id of 0 maps the original 255 possible types onto a namespace of 2^32-1 possible types, allowing for virtually unlimited expansion. (Note that type 0 is never used.) An implementation that supports the Vendor-specific attribute MUST treat EAP types that are less than 256 equivalently whether they appear as a single octet or as the 32-bit Vendor-Type within a Vendor-specific type where Vendor-Id is 0. The single exception to this rule is the Nak type, as described below. Peers not equipped to interpret the Vendor-specific Type MUST send a Nak, and negotiate a more suitable authentication method. A summary of the Vendor-specific Type format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 254 for Vendor-specific Vendor-Id The Vendor-Id is 3 octets and represents the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as allocated by IANA. A Vendor-Id of zero is reserved for use by the IETF in providing an expanded global EAP Type space. Vendor-Type The Vendor-Type field is four octets and represents the vendor- specific Method Type. If Vendor-Id is zero, the Vendor-Type field is an extension and superset of the existing namespace for EAP types. The first 256 types are reserved for compatibility with single-octet EAP types that have already been assigned or may be assigned in the future. Thus, EAP types from 0 through 255 are semantically identical whether they appear as single octet EAP types or as Vendor-Types when Vendor-Id is zero. Vendor-Specific The Vendor-Specific field is dependent on the vendor's definition of that attribute. Where a Vendor-Id of zero is present, the Vendor- Specific field will be used for transporting the contents of EAP Methods of Types defined by the IETF. 5.5.1 Vendor-Specific Nak The Vendor-specific type may be Nak'd in either of two ways: Legacy Nak or Vendor-specific Nak 5.5.1.1 Legacy Nak The Legacy Nak, consisting of a single octet of value 3, is used to reject Vendor-specific requests entirely. This type of Nak indicates that the Vendor-specific type itself is unacceptable to the peer. This type of Nak provides backward compatibility for peers that implement RFC2284 or earlier. Peer implementations that do support the Vendor-specific type SHOULD NOT use this type of Nak, even as a shortcut to rejecting all possible Vendor-specific methods at once. Future specifications may depend on an authenticator being able to recognize the implementation level of the peer, and eliciting a Nak may provide a means of doing this. 5.5.1.2 Vendor-specific Nak The Vendor-specific Nak is a Nak within a Vendor-specific type with Vendor-Id of 0, as shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 254 | Vendor-Id = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Types ... + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Desired Types field contains zero or more Vendor-specific Types, in order of preference, with the most preferred method first; each Type is In order to avoid an interminable negotiation, the Peer MUST only include Types that it is willing to accept. Each Type in the Desired Types field MUST be in the form of a Vendor-specific Type, even if it is a Type from the original namespace 1 - 255. The Vendor-specific Nak allows individual authentication methods expressed as Vendor-specific Types to be Nak'd, without rejecting the Vendor-specific Type in general. In addition, it permits the peer to list any authentication type -- whether IETF- or vendor- defined -- as acceptable. An example of a Vendor-specific Nak indicating that MD5-Challenge would be acceptable is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com --=====================_-1203455317==_.ALT Content-Type: text/html; charset="us-ascii" Bernard asked me to resend this; it may not have reached the
entire list.

Paul

--------------------------

Here is a proposed resolution of issue 41 - Nak of extended types.

One thing I learned while writing this proposal: the past tense of
Nak is "Nak'd", not "Naked".


Out-of-scope changes
--------------------------------
I've taken some liberties that go beyond the scope of this issue.
Feel free to change things back to the way they were if there
are objections:

1   I changed 255 to 254, on the theory that experimental use of
EAP using type 255 is legacy behavior that should not be broken.

2   The original Vendor-specific type has everything after the
Vendor-Id defined by the vendor, with the suggested format of
Vendor-Type immediately following (RADIUS-style). I changed that
to make the format uniform (Diameter-style), so all v-s types have
a fixed format that includes Vendor-Type and are thus interpretable
by anyone. Since Vendor-type is used as part of the protocol when
Nak'ing, it's best to make sure everyone uses it the same way. I
don't believe this limits vendor flexibility.


Interesting implications of this proposal
---------------------------------------------------------
Note that by using single-octet types and vendor-specific types
in an interchangeable way, it is possible to extend EAP in all
kinds of ways without breaking backward-compatibility. For example,
if the authenticator starts the conversation with a vendor-specific
type (as indicated by the first byte being 254), a legacy peer would
Nak but a new peer could respond with a vendor-specific type
(possibly a v-s Nak). Once both parties are talking vendor-specific,
anything is possible.

For example, the issue of bi-directional success and failure packets
could be solved within this context.


Proposed Text
---------------------

5.5.  Vendor-specific

Description

   Due to EAP's popularity, the original Method Type space, which only
   provides for 255 values, is being allocated at a pace, which if
   continued, would result in exhaustion within a few years.  Since many
   of the existing uses of EAP are vendor-specific, the Vendor-Specific
   Method Type is available to allow vendors to support their own
   extended Types not suitable for general usage.

   The Vendor-specific type is also used to expand the global Method
   Type space beyond the original 255 values. A Vendor-Id of 0 maps the
   original 255 possible types onto a namespace of 2^32-1 possible types,
   allowing for virtually unlimited expansion. (Note that type 0 is
   never used.)

   An implementation that supports the Vendor-specific attribute MUST
   treat EAP types that are less than 256 equivalently whether they
   appear as a single octet or as the 32-bit Vendor-Type within a
   Vendor-specific type where Vendor-Id is 0. The single exception
   to this rule is the Nak type, as described below.

   Peers not equipped to interpret the Vendor-specific Type MUST send a
   Nak, and negotiate a more suitable authentication method.

   A summary of the Vendor-specific Type format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |               Vendor-Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor-Type                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vendor data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

   254 for Vendor-specific

Vendor-Id

   The Vendor-Id is 3 octets and represents the SMI Network Management
   Private Enterprise Code of the Vendor in network byte order, as
   allocated by IANA. A Vendor-Id of zero is reserved for use by the
   IETF in providing an expanded global EAP Type space.

Vendor-Type

   The Vendor-Type field is four octets and represents the vendor-
   specific Method Type.

   If Vendor-Id is zero, the Vendor-Type field is an extension and
   superset of the existing namespace for EAP types. The first 256
   types are reserved for compatibility with single-octet EAP types
   that have already been assigned or may be assigned in the future.
   Thus, EAP types from 0 through 255 are semantically identical
   whether they appear as single octet EAP types or as Vendor-Types
   when Vendor-Id is zero.

Vendor-Specific

   The Vendor-Specific field is dependent on the vendor's definition of
   that attribute. Where a Vendor-Id of zero is present, the Vendor-
   Specific field will be used for transporting the contents of EAP
   Methods of Types defined by the IETF.

5.5.1 Vendor-Specific Nak

   The Vendor-specific type may be Nak'd in either of two ways: Legacy
   Nak or Vendor-specific Nak

5.5.1.1 Legacy Nak

   The Legacy Nak, consisting of a single octet of value 3, is used to
   reject Vendor-specific requests entirely. This type of Nak indicates
   that the Vendor-specific type itself is unacceptable to the peer.
   This type of Nak provides backward compatibility for peers that
   implement RFC2284 or earlier.

   Peer implementations that do support the Vendor-specific type SHOULD
   NOT use this type of Nak, even as a shortcut to rejecting all possible
   Vendor-specific methods at once. Future specifications may depend on
   an authenticator being able to recognize the implementation level of
   the peer, and eliciting a Nak may provide a means of doing this.

5.5.1.2 Vendor-specific Nak

   The Vendor-specific Nak is a Nak within a Vendor-specific type with
   Vendor-Id of 0, as shown below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 254   |            Vendor-Id = 0                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Vendor-Type = 3                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Desired Types ...
   +
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Desired Types field contains zero or more Vendor-specific
   Types, in order of preference, with the most preferred method
   first; each Type is In order to avoid an interminable negotiation,
   the Peer MUST only include Types that it is willing to accept.

   Each Type in the Desired Types field MUST be in the form of a
   Vendor-specific Type, even if it is a Type from the original
   namespace 1 - 255.

   The Vendor-specific Nak allows individual authentication methods
   expressed as Vendor-specific Types to be Nak'd, without rejecting
   the Vendor-specific Type in general. In addition, it permits the
   peer to list any authentication type -- whether IETF- or vendor-
   defined -- as acceptable.

   An example of a Vendor-specific Nak indicating that MD5-Challenge
   would be acceptable is shown below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      254      |                       0                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               3                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       4       |                       0                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               4                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Paul Funk
Funk Software, Inc.
617 497-6339
paul@funk.com
--=====================_-1203455317==_.ALT-- From aboba@internaut.com Fri Dec 13 00:24:04 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 12 Dec 2002 16:24:04 -0800 (PST) Subject: [eap] Comments on draft-puthenkulam-eap-binding-01.txt Message-ID: This draft describes aspects of MiTM attacks that can be mounted against compound EAP methods. At IETF 55, there was consensus that this was a problem that needed more work. The first step in that direction is to complete the problem statement. This is the core of what this draft is trying to do, I think. However, in reading through it, I think it doesn't do a very good job in several aspects: a. Motivation for compound methods. One obvious solution to the problem of compound method security is to say "don't use compound methods, use strong simple methods instead." So some justification for the use of compound methods needs to be included in the draft. b. Discussing vulnerabilities of EAP method sequences. Are the same attacks launchable against sequences? In what scenarios? The discussion is mostly focussed on tunneling. c. Discussing the circumstances in which the attack can occur. For example, can the attack occur when the tunnel authentication is mutual? If there is no credential reuse? What role can policy play? d. Discussing the *incremental* vulnerabilities created by compound methods. This is very important in understand what problems are *created* by compound methods, and which problems are inherent in the scenarios being discussed. For example, when dealing with "legacy" methods (e.g. methods which do one-way auth and don't derive keys) and wired networks (e.g. PPP and IEEE 802) there is an inherent vulnerability to hijacking. Therefore the scenario is inherently insecure from the start -- and so the question is not whether security is present (it isn't) -- but how compound methods make the situation *worse*. e. Discussing the requirements for a solution. What would a "solution" to the "problem" being defined look like? What should we expect from a "solution"? For example, would a solution prevent offline attacks against weak tunneled methods? Would it apply to all EAP methods, or just some subset? If it only applies to a subset, why does this subset benefit from tunneling? From jose.p.puthenkulam@intel.com Fri Dec 13 19:16:52 2002 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Fri, 13 Dec 2002 11:16:52 -0800 Subject: [eap] Comments on draft-puthenkulam-eap-binding-01.txt Message-ID: Hi Bernard, These are all good comments. And its really positive to have an open discussion on the list to get more input from others in the working group. The current plan is to have a revised draft submitted in early Jan taking into account some of these additional areas which the draft didn't address as we were racing to make the IETF#55 deadline :) best regards, jose ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jose Puthenkulam Senior Software Engineer Emerging Platforms Lab Intel R & D Intel Corporation 2111 NE 25th Avenue, JF2-58 Hillsboro, OR 97124 Tel: (503) 264 6121 Fax: (503) 264 8154 Email: jose.p.puthenkulam@intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Thursday, December 12, 2002 4:24 PM To: eap@frascone.com Subject: [eap] Comments on draft-puthenkulam-eap-binding-01.txt This draft describes aspects of MiTM attacks that can be mounted against compound EAP methods. At IETF 55, there was consensus that this was a problem that needed more work. The first step in that direction is to complete the problem statement. This is the core of what this draft is trying to do, I think. However, in reading through it, I think it doesn't do a very good job in several aspects: a. Motivation for compound methods. One obvious solution to the problem of compound method security is to say "don't use compound methods, use strong simple methods instead." So some justification for the use of compound methods needs to be included in the draft. b. Discussing vulnerabilities of EAP method sequences. Are the same attacks launchable against sequences? In what scenarios? The discussion is mostly focussed on tunneling. c. Discussing the circumstances in which the attack can occur. For example, can the attack occur when the tunnel authentication is mutual? If there is no credential reuse? What role can policy play? d. Discussing the *incremental* vulnerabilities created by compound methods. This is very important in understand what problems are *created* by compound methods, and which problems are inherent in the scenarios being discussed. For example, when dealing with "legacy" methods (e.g. methods which do one-way auth and don't derive keys) and wired networks (e.g. PPP and IEEE 802) there is an inherent vulnerability to hijacking. Therefore the scenario is inherently insecure from the start -- and so the question is not whether security is present (it isn't) -- but how compound methods make the situation *worse*. e. Discussing the requirements for a solution. What would a "solution" to the "problem" being defined look like? What should we expect from a "solution"? For example, would a solution prevent offline attacks against weak tunneled methods? Would it apply to all EAP methods, or just some subset? If it only applies to a subset, why does this subset benefit from tunneling? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Sun Dec 15 03:49:59 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 14 Dec 2002 19:49:59 -0800 (PST) Subject: [eap] Re: Proposed resolution of issue #41 In-Reply-To: <4.1.20021211201759.02736ae0@mail.funk.com> Message-ID: > 1 I changed 255 to 254, on the theory that experimental use of > EAP using type 255 is legacy behavior that should not be broken. Good idea. We had agreed at IETF 55 to add an experimental Type. So 255 will be the Experimental Type, and 254 will be for extended Types. > 2 The original Vendor-specific type has everything after the > Vendor-Id defined by the vendor, with the suggested format of > Vendor-Type immediately following (RADIUS-style). I changed that > to make the format uniform (Diameter-style), so all v-s types have > a fixed format that includes Vendor-Type and are thus interpretable > by anyone. This is also a good idea -- the Vendor-Type field as a fixed format of 4 octets as opposed to being of vendor-defined size. > Since Vendor-type is used as part of the protocol when > Nak'ing, it's best to make sure everyone uses it the same way. I > don't believe this limits vendor flexibility. Yes. > if the authenticator starts the conversation with a vendor-specific > type (as indicated by the first byte being 254), a legacy peer would > Nak but a new peer could respond with a vendor-specific type > (possibly a v-s Nak). Once both parties are talking vendor-specific, > anything is possible. I assume that if the authenticator begins with a V-S type (254), then the legacy peer would NAK with a single type within the standard space (4-192). The RFC 2284bis Peer would respond with: a. A list of extended types with a single vendorid? b. A mixture of extended types with different vendorids? c. Some mixture of standard and extended types? I wasn't clear what you are advocating in your proposal. > 5.5.1.1 Legacy Nak > > The Legacy Nak, consisting of a single octet of value 3, is used to > reject Vendor-specific requests entirely. Type=3 is NAK. If you wanted to reject Vendor-Specific requests, why wouldn't the Legacy client NAK with the type of the method it prefers? > This type of Nak provides backward compatibility for peers that > implement RFC2284 or earlier. RFC 2284 states: The Nak Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains the authentication Type desired by the peer. So a NAK with a Type=3 in the data field is not legal in a legacy implementation. > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 254 | Vendor-Id = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-Type = 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Desired Types ... > + > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Vendor-Id = 0 is used to extend the "standard" type space. So presumably this example packet would only be able to indicate the desire to use alternative "standard" types, no? Why is a Vendor-Type=3 required to do this? couldn't the desired types (4 octets) each just be included in a list fter the initial 4 octets? > The Desired Types field contains zero or more Vendor-specific > Types, in order of preference, with the most preferred method > first How can Vendor-Specific types be indicated if the Vendor-Id is always = 0 (IETF standard extension space). Or can the Vendor-Id field contain another value, too? What if the client needs to indicate the desire to do some mixture of IETF standard and Vendor-Specific Types? Is stacking possible? > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 254 | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 4 | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Why couldn't this be indicated by the following payload: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ And as an example, could we indicate a preference for Vendor-Id=311, Type = 15, and then EAP-MD5 as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | 311 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From paul@funk.com Sun Dec 15 19:43:27 2002 From: paul@funk.com (Paul Funk) Date: Sun, 15 Dec 2002 14:43:27 -0500 Subject: [eap] Re: Proposed resolution of issue #41 In-Reply-To: References: <4.1.20021211201759.02736ae0@mail.funk.com> Message-ID: <4.1.20021215130655.0270ed40@mail.funk.com> --=====================_172493061==_.ALT Content-Type: text/plain; charset="us-ascii" At 07:49 PM 12/14/02 -0800, Bernard Aboba wrote: ... >> if the authenticator starts the conversation with a vendor-specific >> type (as indicated by the first byte being 254), a legacy peer would >> Nak but a new peer could respond with a vendor-specific type >> (possibly a v-s Nak). Once both parties are talking vendor-specific, >> anything is possible. > >I assume that if the authenticator begins with a V-S type (254), then the >legacy peer would NAK with a single type within the standard space >(4-192). Correct. > >The RFC 2284bis Peer would respond with: > >a. A list of extended types with a single vendorid? >b. A mixture of extended types with different vendorids? >c. Some mixture of standard and extended types? > >I wasn't clear what you are advocating in your proposal. The 2284bis Peer would Nak with a mixture of standard and extended types. However, all types (including the Nak itself) would be in extended (8-octet) format. The distinction between standard and extended types sort of disappears in this proposal. The extended format is a superset of the single-octet format, and includes all single-octet types. All single-octet types (including Identity, Notification and Nak) map into the extended format with Vendor-Id of 0. > >> 5.5.1.1 Legacy Nak >> >> The Legacy Nak, consisting of a single octet of value 3, is used to >> reject Vendor-specific requests entirely. > >Type=3 is NAK. If you wanted to reject Vendor-Specific requests, why >wouldn't the Legacy client NAK with the type of the method it prefers? It would. My text is misleading. How about this: The Legacy Nak, consisting of a single octet of value 3 followed by one or more single-octet Authentication Types of value 4 or above, is used to reject Vendor-specific requests entirely. > >> This type of Nak provides backward compatibility for peers that >> implement RFC2284 or earlier. > >RFC 2284 states: > > > The Nak Type is valid only in Response messages. It is sent in > reply to a Request where the desired authentication Type is > unacceptable. Authentication Types are numbered 4 and above. > The Response contains the authentication Type desired by the peer. > >So a NAK with a Type=3 in the data field is not legal in a legacy >implementation. Correct. My intent was that a Legacy Nak is an ordinary Nak that existing pre-2284bis Peer implementations would issue. A 2284bis Authenticator, upon receiving a Legacy Nak in response to an extended (254) type, would recognize that the Peer doesn't support 2284bis. It would therefore interpret the Nak according to the pre-2284bis rules, and would desist from offering any other extended authentication types during that session. > >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type = 254 | Vendor-Id = 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Vendor-Type = 3 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Desired Types ... >> + >> | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >A Vendor-Id = 0 is used to extend the "standard" type space. So presumably >this example packet would only be able to indicate the desire to use >alternative "standard" types, no? Why is a Vendor-Type=3 required to do >this? couldn't the desired types (4 octets) each just be included in a >list fter the initial 4 octets? > >> The Desired Types field contains zero or more Vendor-specific >> Types, in order of preference, with the most preferred method >> first > >How can Vendor-Specific types be indicated if the Vendor-Id is always = 0 >(IETF standard extension space). Or can the Vendor-Id field contain >another value, too? What if the client needs to indicate the desire to do >some mixture of IETF standard and Vendor-Specific Types? Is stacking >possible? The idea here is that when a 2284bis Peer wants to Nak a 2284bis Authenticator's extended (v-s) type, it uses extended types instead of single-octet types. The Nak type as well as each desired type is in extended format. So, the first 8 octets above are interpreted as type Nak, thus indicating that this is a Nak response packet. Instead of a single octet of value 3, the Nak is represented as an extended (vendor-specific) type: the initial 254 indicates that this is an extended type, the Vendor-Id of 0 indicates it is a type from the IANA space, and the Vendor-Type of 3 indicates it is a Nak. The Desired Types that follow are a list of one or more 8-octet extended authentication types that the Peer is willing to use. Each individual desired type has its own Vendor-Id - 0, 311, 1411, etc. > >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 254 | 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 3 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 4 | 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Why couldn't this be indicated by the following payload: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 254 | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >And as an example, could we indicate a preference for Vendor-Id=311, Type >= 15, and then EAP-MD5 as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 254 | 311 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 15 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 254 | 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There is a typo in my original example, which may be causing confusion. The single octet "4" should be a "254". Your two examples are correct, except for the omission of the extended Nak type itself. Here's an improved version of my proposed text with example, that includes both 0 and non-0 Vendor-Ids, fixes the typo, and adds some gloss to the type numbers: An example is shown below of a Vendor-specific Nak indicating the acceptability of two authentication types: (1) MD5-Challenge, and (2) a hypothetical type 15 defined by a (not-so-hypothetical) vendor with id 311: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | Vendor-Id = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type = 3 (Nak) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | Vendor-Id = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type = 4 (MD5-Challenge) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | Vendor-Id = 311 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type = 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com --=====================_172493061==_.ALT Content-Type: text/html; charset="us-ascii" At 07:49 PM 12/14/02 -0800, Bernard Aboba wrote:
...
>> if the authenticator starts the conversation with a vendor-specific
>> type (as indicated by the first byte being 254), a legacy peer would
>> Nak but a new peer could respond with a vendor-specific type
>> (possibly a v-s Nak). Once both parties are talking vendor-specific,
>> anything is possible.
>
>I assume that if the authenticator begins with a V-S type (254), then the
>legacy peer would NAK with a single type within the standard space
>(4-192).

Correct.

>
>The RFC 2284bis Peer would respond with:
>
>a. A list of extended types with a single vendorid?
>b. A mixture of extended types with different vendorids?
>c. Some mixture of standard and extended types?
>
>I wasn't clear what you are advocating in your proposal.

The 2284bis Peer would Nak with a mixture of standard and
extended types. However, all types (including the Nak itself)
would be in extended (8-octet) format.

The distinction between standard and extended types sort of 
disappears in this proposal. The extended format is a superset of the
single-octet format, and includes all single-octet types. All single-octet
types (including Identity, Notification and Nak) map into the extended
format with Vendor-Id of 0.

>
>> 5.5.1.1 Legacy Nak
>>
>>    The Legacy Nak, consisting of a single octet of value 3, is used to
>>    reject Vendor-specific requests entirely.
>
>Type=3 is NAK. If you wanted to reject Vendor-Specific requests, why
>wouldn't the Legacy client NAK with the type of the method it prefers?

It would. My text is misleading. How about this:

The Legacy Nak, consisting of a single octet of value 3
followed by one or more single-octet Authentication Types
of value 4 or above, is used to reject Vendor-specific
requests entirely. 

>
>>    This type of Nak provides backward compatibility for peers that
>>    implement RFC2284 or earlier.
>
>RFC 2284 states:
>
>
>      The Nak Type is valid only in Response messages.  It is sent in
>      reply to a Request where the desired authentication Type is
>      unacceptable.   Authentication Types are numbered 4 and above.
>      The Response contains the authentication Type desired by the peer.
>
>So a NAK with a Type=3 in the data field is not legal in a legacy
>implementation.

Correct. My intent was that a Legacy Nak is an ordinary Nak that
existing pre-2284bis Peer implementations would issue. A 2284bis
Authenticator, upon receiving a Legacy Nak in response to an extended
(254) type, would recognize that the Peer doesn't support 2284bis. It
would therefore interpret the Nak according to the pre-2284bis rules, and
would desist from offering any other extended authentication types during
that session.

>
>>     0                   1                   2                   3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |  Type = 254   |            Vendor-Id = 0                      |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                       Vendor-Type = 3                         |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                Desired Types ...
>>    +
>>    |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>A Vendor-Id = 0 is used to extend the "standard" type space. So presumably
>this example packet would only be able to indicate the desire to use
>alternative "standard" types, no? Why is a Vendor-Type=3 required to do
>this? couldn't the desired types (4 octets) each just be included in a
>list fter the initial 4 octets?
>
>>    The Desired Types field contains zero or more Vendor-specific
>>    Types, in order of preference, with the most preferred method
>>    first
>
>How can Vendor-Specific types be indicated if the Vendor-Id is always = 0
>(IETF standard extension space). Or can the Vendor-Id field contain
>another value, too? What if the client needs to indicate the desire to do
>some mixture of IETF standard and Vendor-Specific Types? Is stacking
>possible?

The idea here is that when a 2284bis Peer wants to Nak a 2284bis
Authenticator's extended (v-s) type, it uses extended types instead
of single-octet types.

The Nak type as well as each desired type is in extended format.

So, the first 8 octets above are interpreted as type Nak, thus indicating that
this is a Nak response packet. Instead of a single octet of value 3, the Nak is
represented as an extended (vendor-specific) type: the initial 254 indicates that
this is an extended type, the Vendor-Id of 0 indicates it is a type from the IANA
space, and the Vendor-Type of 3 indicates it is a Nak.

The Desired Types that follow are a list of one or more 8-octet extended
authentication types that the Peer is willing to use.

Each individual desired type has its own Vendor-Id - 0, 311, 1411, etc.

>
>>     0                   1                   2                   3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |      254      |                       0                       |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                               3                               |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |       4       |                       0                       |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                               4                               |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Why couldn't this be indicated by the following payload:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      254      |                       0                       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                               4                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>And as an example, could we indicate a preference for Vendor-Id=311, Type
>= 15, and then EAP-MD5 as follows:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      254      |                     311                       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                               15                              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      254      |                      0                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                4                              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

There is a typo in my original example, which may be causing confusion. The single
octet "4" should be a "254".

Your two examples are correct, except for the omission of the extended Nak
type itself.

Here's an improved version of my proposed text with example, that includes both
0 and non-0 Vendor-Ids, fixes the typo, and adds some gloss to the type numbers:

An example is shown below of a Vendor-specific Nak indicating
the acceptability of two authentication types: (1) MD5-Challenge,
and (2) a hypothetical type 15 defined by a (not-so-hypothetical)
vendor with id 311:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      254      |                 Vendor-Id = 0                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Vendor-Type = 3 (Nak)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      254      |                 Vendor-Id = 0                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Vendor-Type = 4 (MD5-Challenge)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      254      |                 Vendor-Id = 311                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Vendor-Type = 15                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Paul




Paul Funk
Funk Software, Inc.
617 497-6339
paul@funk.com
--=====================_172493061==_.ALT-- From aboba@internaut.com Sun Dec 15 19:58:56 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 15 Dec 2002 11:58:56 -0800 (PST) Subject: [eap] Re: Proposed resolution of issue #41 In-Reply-To: <4.1.20021215130655.0270ed40@mail.funk.com> Message-ID: > It would. My text is misleading. How about this: > > The Legacy Nak, consisting of a single octet of value 3 > followed by one or more single-octet Authentication Types > of value 4 or above, is used to reject Vendor-specific > requests entirely. OK. > Correct. My intent was that a Legacy Nak is an ordinary Nak that > existing pre-2284bis Peer implementations would issue. A 2284bis > Authenticator, upon receiving a Legacy Nak in response to an extended > (254) type, would recognize that the Peer doesn't support 2284bis. It > would therefore interpret the Nak according to the pre-2284bis rules, and > would desist from offering any other extended authentication types during > that session. OK. > The idea here is that when a 2284bis Peer wants to Nak a 2284bis > Authenticator's extended (v-s) type, it uses extended types instead > of single-octet types. > > The Nak type as well as each desired type is in extended format. OK. Can the RFC 2248bis Peer respond with an extended Nak to an offer of a standard (1-255) type from a legacy peer? I think the answer is yes, since it is assumed that the legacy peer will ignore everything except the first octet of the type-data (254). It will either counter with another offer within the standard space, or send an EAP Failure. > Nak is represented as an extended (vendor-specific) type: the initial > 254 indicates that The problem is that the state machine only allows an initial Request (offer) of a given Type to be answered by a Response of that same Type (offer acceptance) or a Nak (Type 3). Allowing it to be answered by a Response of either Type 3 or 254 complicates the state machine. > Your two examples are correct, except for the omission of the extended Nak > type itself. OK. So we're talking about whether a Type of 254 or 3 is used for the NAK packet itself. Essentially, you are defining a new NAK packet of Type 254, and I was talking about extended the old NAK packet of Type 3. > An example is shown below of a Vendor-specific Nak indicating > the acceptability of two authentication types: (1) MD5-Challenge, > and (2) a hypothetical type 15 defined by a (not-so-hypothetical) > vendor with id 311: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 254 | Vendor-Id = 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-Type = 3 (Nak) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 254 | Vendor-Id = 0 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-Type = 4 (MD5-Challenge) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 254 | Vendor-Id = 311 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-Type = 15 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks. Question -- are there things that you can do by defining a new NAK packet that you couldn't do by extending the old one? In the case given above the functionality is similar -- but I assume that the added overhead is also meant to provide some additional flexibility. From paul@funk.com Sun Dec 15 22:01:10 2002 From: paul@funk.com (Paul Funk) Date: Sun, 15 Dec 2002 17:01:10 -0500 Subject: [eap] Re: Proposed resolution of issue #41 In-Reply-To: References: <4.1.20021215130655.0270ed40@mail.funk.com> Message-ID: <4.1.20021215160817.02716e70@mail.funk.com> --=====================_180755843==_.ALT Content-Type: text/plain; charset="us-ascii" At 11:58 AM 12/15/02 -0800, Bernard Aboba wrote: ... >> The idea here is that when a 2284bis Peer wants to Nak a 2284bis >> Authenticator's extended (v-s) type, it uses extended types instead >> of single-octet types. >> >> The Nak type as well as each desired type is in extended format. > >OK. Can the RFC 2248bis Peer respond with an extended Nak to an offer of a >standard (1-255) type from a legacy peer? I think the answer is >yes, since it is assumed that the legacy peer will ignore everything >except the first octet of the type-data (254). It will either counter with >another offer within the standard space, or send an EAP Failure. Actually, I think it can't. The extended Nak starts with an 8-octet, not a 1-octet, Nak. So the type of the packet looks like 254 to the legacy authenticator, and it won't understand it at all. If the 2284bis Peer gets a request in non-extended form, it doesn't know if the Authenticator is legacy or 2284bis. It should therefore Nak in non- extended form as well. If it supports authentication types in the extended space, it can include a 254 as a desired type. If the Authenticator is legacy, the 254 would be disregarded. If the Authenticator is 2284bis, the presence of 254 in a Nak (even if single-octet) indicates that the Peer is 2284bis, so its next request can be in extended form. Once the Peer receives the extended form request, it then Nak extended types precisely, since it now knows the Authenticator is also 2284bis. A 2284bis Authenticator could take the approach of always issuing an extended request first, even if the authentication method is a standard one such as MD5-Challenge. If the Peer is pre-2284bis it will issue a legacy Nak and the Authenticator will drop down to legacy operation. If the Peer is 2284bis, it can respond with an extended Nak. This approach may cost a round trip when the Peer is pre-2284bis, but when the Peer is 2284bis it provides a cleanest negotiation and may save a round trip. > >> Nak is represented as an extended (vendor-specific) type: the initial >> 254 indicates that > >The problem is that the state machine only allows an initial Request >(offer) of a given Type to be answered by a Response of that same Type >(offer acceptance) or a Nak (Type 3). Allowing it to be answered by >a Response of either Type 3 or 254 complicates the state machine. I would suggest that we don't consider 254 a "type". It is really like an escape character. So if we understand "type" to be a code point in a 7-octet space composed of vendor-id and ordinal, and that this code point can be represented in either 1 octet or 8 octets (where the 1 octet version has limited span), I think the problem goes away. > >> Your two examples are correct, except for the omission of the extended Nak >> type itself. > >OK. So we're talking about whether a Type of 254 or 3 is used for the NAK >packet itself. Essentially, you are defining a new NAK packet of Type 254, >and I was talking about extended the old NAK packet of Type 3. Yes. > >> An example is shown below of a Vendor-specific Nak indicating >> the acceptability of two authentication types: (1) MD5-Challenge, >> and (2) a hypothetical type 15 defined by a (not-so-hypothetical) >> vendor with id 311: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 254 | Vendor-Id = 0 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Vendor-Type = 3 (Nak) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 254 | Vendor-Id = 0 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Vendor-Type = 4 (MD5-Challenge) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 254 | Vendor-Id = 311 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Vendor-Type = 15 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Thanks. > >Question -- are there things that you can do by defining a new NAK packet >that you couldn't do by extending the old one? In the case given above the >functionality is similar -- but I assume that the added overhead is also >meant to provide some additional flexibility. Actually, I don't think of this as defining a new Nak packet, but extending the interpretation of the Nak element. The purpose of the extended Nak packet is to provide backward compatibility while preserving equivalent functionality across the entire spectrum of types. This could have be done in a number of ways; any mechanism would have to be examined to make sure there are no avenues for misinterpretation due to different versions of the standard being supported on Peer and Authenticator. The mechanism of defining an extended type space that comprises the original type space seemed to me the least arbitrary, and easily verified to be harmless to existing implementations. I think any added flexibility it provides relates to the ability of a 2284bis Peer and 2284bis Authenticator to discover that they are both indeed 2284bis, even if they are using a standard protocol such as MD5-Challenge. If we want to add any new features to the protocol, such as Peer response to EAP-Success, this could be the avenue to do this without breaking existing implementations. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com --=====================_180755843==_.ALT Content-Type: text/html; charset="us-ascii" At 11:58 AM 12/15/02 -0800, Bernard Aboba wrote:
...
>> The idea here is that when a 2284bis Peer wants to Nak a 2284bis
>> Authenticator's extended (v-s) type, it uses extended types instead
>> of single-octet types.
>>
>> The Nak type as well as each desired type is in extended format.
>
>OK. Can the RFC 2248bis Peer respond with an extended Nak to an offer of a
>standard (1-255) type from a legacy peer? I think the answer is
>yes, since it is assumed that the legacy peer will ignore everything
>except the first octet of the type-data (254). It will either counter with
>another offer within the standard space, or send an EAP Failure.

Actually, I think it can't. The extended Nak starts with an 8-octet, not
a 1-octet, Nak. So the type of the packet looks like 254 to the legacy
authenticator, and it won't understand it at all.

If the 2284bis Peer gets a request in non-extended form, it doesn't know if
the Authenticator is legacy or 2284bis. It should therefore Nak in non-
extended form as well. If it supports authentication types in the extended
space, it can include a 254 as a desired type. If the Authenticator is
legacy, the 254 would be disregarded. If the Authenticator is 2284bis, the
presence of 254 in a Nak (even if single-octet) indicates that the Peer is
2284bis, so its next request can be in extended form. Once the Peer
receives the extended form request, it then Nak extended types
precisely, since it now knows the Authenticator is also 2284bis.

A 2284bis Authenticator could take the approach of always issuing an
extended request first, even if the authentication method is a standard
one such as MD5-Challenge. If the Peer is pre-2284bis it will issue a
legacy Nak and the Authenticator will drop down to legacy operation. If
the Peer is 2284bis, it can respond with an extended Nak. This approach
may cost a round trip when the Peer is pre-2284bis, but when the Peer
is 2284bis it provides a cleanest negotiation and may save a round trip.

>
>> Nak is represented as an extended (vendor-specific) type: the initial
>> 254 indicates that
>
>The problem is that the state machine only allows an initial Request
>(offer) of a given Type to be answered by a Response of that same Type
>(offer acceptance) or a Nak (Type 3). Allowing it to be answered by
>a Response of either Type 3 or 254 complicates the state machine.

I would suggest that we don't consider 254 a "type". It is really like an
escape character. So if we understand "type" to be a code point in a
7-octet space composed of vendor-id and ordinal, and that this code
point can be represented in either 1 octet or 8 octets (where the 1 octet
version has limited span), I think the problem goes away.

>
>> Your two examples are correct, except for the omission of the extended Nak
>> type itself.
>
>OK. So we're talking about whether a Type of 254 or 3 is used for the NAK
>packet itself. Essentially, you are defining a new NAK packet of Type 254,
>and I was talking about extended the old NAK packet of Type 3.

Yes.

>
>> An example is shown below of a Vendor-specific Nak indicating
>> the acceptability of two authentication types: (1) MD5-Challenge,
>> and (2) a hypothetical type 15 defined by a (not-so-hypothetical)
>> vendor with id 311:
>>
>>  0                   1                   2                   3
>>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |      254      |                 Vendor-Id = 0
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |                       Vendor-Type = 3 (Nak)                   |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |      254      |                 Vendor-Id = 0
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |                       Vendor-Type = 4 (MD5-Challenge)         |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |      254      |                 Vendor-Id = 311
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |                       Vendor-Type = 15                        |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Thanks.
>
>Question -- are there things that you can do by defining a new NAK packet
>that you couldn't do by extending the old one? In the case given above the
>functionality is similar -- but I assume that the added overhead is also
>meant to provide some additional flexibility.

Actually, I don't think of this as defining a new Nak packet, but extending
the interpretation of the Nak element.

The purpose of the extended Nak packet is to provide backward
compatibility while preserving equivalent functionality across the entire
spectrum of types.

This could have be done in a number of ways; any mechanism would have
to be examined to make sure there are no avenues for misinterpretation
due to different versions of the standard being supported on Peer and
Authenticator.

The mechanism of defining an extended type space that comprises
the original type space seemed to me the least arbitrary, and easily
verified to be harmless to existing implementations.

I think any added flexibility it provides relates to the ability of a 2284bis Peer
and 2284bis Authenticator to discover that they are both indeed 2284bis,
even if they are using a standard protocol such as MD5-Challenge. If we
want to add any new features to the protocol, such as Peer response
to EAP-Success, this could be the avenue to do this without breaking
existing implementations.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
paul@funk.com
--=====================_180755843==_.ALT-- From aboba@internaut.com Tue Dec 17 06:48:43 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 16 Dec 2002 22:48:43 -0800 (PST) Subject: [eap] Resolution of Issue 25: Accept In-Reply-To: <499DC368E25AD411B3F100902740AD65129921F1@xrose03.rose.hp.com> Message-ID: The minutes of the 12/11/02 EAP Design team reflects the logic you state below. However, this has not yet been reflected in new text for resolving Issue 25. Care to take a crack at it? On Mon, 16 Dec 2002, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > I don't fully understand the resolution to this issue. I guess there is no > queue between the EAP layer and the EAP method, so the EAP layer must > discard potentially good frames because the EAP method hasn't generated the > response yet? Why not simply have the EAP layer deliver frames that it > thinks are potentially good and potentially retransmissions (because the ID > field is right) and discard everything else until a response is sent. It > would be the responsibility of the EAP method to catch-up or discard the > duplicate requests. It doesn't seem like the EAP layer should discard > things that could be valid retransmissions by the authenticator. > > Paul > > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Wednesday, November 27, 2002 6:00 PM > > To: eap@frascone.com > > Subject: [eap] Resolution of Issue 25: Accept > > > > > > Issue 25: Spoofing and duplicate detection > > Submitter: Jesse Walker > > Submitter email address: jesse.walker@intel.com > > Date first submitted: May 3, 2002 > > Reference: > > Document: RFC2284bis-04 > > Comment type: T > > Priority: S > > Section: 2.2, 7.7 > > > > Proposed resolution: > > > > Delete Section 7.7. > > > > Add the following text to Section 2.2: > > > > "The EAP layer provides sequencing and duplicate elimination > > to EAP methods. During the period after an > > EAP Peer receives an EAP-Request, but has not yet sent an > > EAP-Response, the Peer EAP layer MUST silently discard > > additional EAP packets upon reception, rather than providing > > them to the EAP method. This occurs whether the received > > packet is a duplicate (same Identifier) or not (different Identifier). > > > > This provides an opportunity for a denial of service attack: > > an attacker can swamp a Peer with EAP Requests, > > preventing valid EAP Requests from being processed. > > Addressing this requires an EAP method to be able > > to indicate to the EAP layer that it wants to handle > > duplicate elimination and packet validation itself, which > > is not supported." > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > From paul.congdon@hp.com Tue Dec 17 05:45:26 2002 From: paul.congdon@hp.com (CONGDON,PAUL (HP-Roseville,ex1)) Date: Mon, 16 Dec 2002 21:45:26 -0800 Subject: [eap] Resolution of Issue 25: Accept Message-ID: <499DC368E25AD411B3F100902740AD65129921F1@xrose03.rose.hp.com> I don't fully understand the resolution to this issue. I guess there is no queue between the EAP layer and the EAP method, so the EAP layer must discard potentially good frames because the EAP method hasn't generated the response yet? Why not simply have the EAP layer deliver frames that it thinks are potentially good and potentially retransmissions (because the ID field is right) and discard everything else until a response is sent. It would be the responsibility of the EAP method to catch-up or discard the duplicate requests. It doesn't seem like the EAP layer should discard things that could be valid retransmissions by the authenticator. Paul > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Wednesday, November 27, 2002 6:00 PM > To: eap@frascone.com > Subject: [eap] Resolution of Issue 25: Accept > > > Issue 25: Spoofing and duplicate detection > Submitter: Jesse Walker > Submitter email address: jesse.walker@intel.com > Date first submitted: May 3, 2002 > Reference: > Document: RFC2284bis-04 > Comment type: T > Priority: S > Section: 2.2, 7.7 > > Proposed resolution: > > Delete Section 7.7. > > Add the following text to Section 2.2: > > "The EAP layer provides sequencing and duplicate elimination > to EAP methods. During the period after an > EAP Peer receives an EAP-Request, but has not yet sent an > EAP-Response, the Peer EAP layer MUST silently discard > additional EAP packets upon reception, rather than providing > them to the EAP method. This occurs whether the received > packet is a duplicate (same Identifier) or not (different Identifier). > > This provides an opportunity for a denial of service attack: > an attacker can swamp a Peer with EAP Requests, > preventing valid EAP Requests from being processed. > Addressing this requires an EAP method to be able > to indicate to the EAP layer that it wants to handle > duplicate elimination and packet validation itself, which > is not supported." > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Wed Dec 18 17:51:49 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 18 Dec 2002 09:51:49 -0800 (PST) Subject: [eap] EAP Design Team Minutes 12/18/02 Message-ID: EAP Design Team Minutes 12/18/02 Scribe: Paul Congdon 802.1aa discussion [1] In Paul's ballot comments for 802.1aa/D4.1 he brought up some issues between the interface of 802.1X and the EAP layer. There have been many new checks put into the EAP layer and subsequent EAP Methods that may cause silent discards or state changes the 802.1X layer may need to know about. The current 802.1aa draft always assumes it sends a response to every request, so this doesn't support silent discards. The two machines need to be looked at side-by-side to assure a proper interface exists for the expected behavior. [2] It was agreed to prepare a reconciliation between the two layers and present at the 802.1aa interim meeting in Vancouver (1/6 - 1/10). Paul to send mail to Tony to request a specific time for the AA meeting. John and Bernard to suggest times when they could possibly attend the 802.1aa meeting to schedule this particular aspect. [3] Discussing the interface between media layers and EAP layers. It should be simple handshakes and should avoid putting media into particular modes or states if possible. Something that simply acknowledges the receipt of EAP frames from the media layer. EAP state machine discussions [1] We need to consider EAP DoS attacks that can come from the wired side as well now that pre-auth is part of 802.11i. With Pre- authentication, an attacker can authenticate to an AP, and then attack another AP within the same ESS. This means that EAP attacks do not have to be local, as would a DoS attack on an 802.11 cipher such as TKIP. [2] In the proposed state machine if any method in a sequence fails, the authentication fails. [3] There is a question about what happens on the peer when it perceives the authentication to have failed. For example, say the authenticator failed to authenticate to the peer, or it send a protected failure indication to the peer. Does the peer have to wait until receipt of an EAP-Failure? Or can it transition to another state immediately? What if the Authenticator thinks that the method is still ongoing and keeps retransmitting? How does the Peer terminate the conversation? There is a need for the peer to be able to signal termination of the authentication. A way to know that the peer has "hung up", so to speak. This is media specific, since not all media may have this ability. For example, with PPP, an LCP-Terminate can be sent; in IEEE 802.11, you can send a Dissociate or De-authenticate. But what do you do on an Ethernet? Lower carrier? [4] Some methods may support protected success/failure indications. In such a method, the authenticator will tell the peer that authentication has failed, and perhaps the Peer can respond, ACK'ing that assessment. In this case, assuming the exchange is completed, then both sides are in synch as to the outcome. [5] Retransmissions need to be checked by the EAP layer and tossed if necessary. How will you know the frame is truly a retransmission? John: All the bits must be checked to know this and the EAP layer isn't currently doing that. You can't just check the identifier. Bernard: Do you really want to require a comparison between a received frame and previously received frames for that identifier? Wouldn't this be creating a significant amount of work that would make a DoS attack easier? Remember, the underlying media is assumed to have a CRC check -- both PPP and IEEE 802 have this. If the CRC check fails, then the EAP packet isn't even processed by the EAP layer, it is discarded. [6] One possible approach here is for the EAP layer to queue packets for the method and then pass queued Requests up to the method, one at a time. If the EAP method replies with a Response, the EAP layer should empty the queue since there should not be any additional packets in flight. If the Authenticator retransmit timer is off, it may have retransmitted earlier before receiving a Response, but that is not of concern to the Peer - clearing those packets from the queue has no ill effects. The Peer sends its Response; if a retransmission comes in after that, it can respond again; if not, it can handle the next Request. Clearing the queue is a DoS attack optimization. [7] If the EAP method didn't like the request it got (presumably because it failed an integrity check) it would tell the EAP layer "packet not accepted" and then the EAP layer will hand the next packet in the queue to the EAP method. Alternatively, the method could abort because it doesn't know how to handle integrity check failures (EAP TLS). [9] This implies that the EAP layer only does some basic checks: given the state of the method, is the Peer accepting packets other than Requests? Is the Type field acceptable? Is the length of the packet appropriate? There is no duplicate checking per se - the EAP layer just maintains a queue that is cleared after a Response is sent. This seems consistent with the behavior desired by Token Card methods. It could take a while for a person to enter in a Response - and if there is a retransmission during that time, you don't want to prompt the user again. You let them type in their Response, send it, clear the queue and then see if a retransmission occurs after that. [10] Some methods may not be able to survive an integrity check failure. For example, Yoshi pointed out that TLS cannot survive a MAC failure, so that presumably EAP TLS cannot survive this either. Bernard agreed to check on this. [11] Notification is handled differently than other methods. A Notification Request can be sent at any time, a Response is sent automatically by the EAP layer, and there is no state change resulting from this (other than perhaps Identifier state). John V was under the impression that Notification Request cannot occur in the middle of the method, but this was agreed upon in a previous Design Team meeting. In the ESTEEM draft we found the previous discussion that indicates the Notification Requests can be sent at any time and can't be NAK'd. We will stick to this decision, and John agreed to update the state machine document to reflect this. On the peer side it is fairly easy to just respond to the Notify, but on the authenticator, you must process the Notification Request like any other packet, wait for a response and retransmit as necessary, etc. [12] John would like to re-visit this issue before making the changes. Could we meet on the 27th in the early afternoon or the 30th (the following Monday). Paul will get a phone line for the 30th to close this issue unless Bernard can secure the Microsoft line. From aboba@internaut.com Wed Dec 18 18:03:10 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 18 Dec 2002 10:03:10 -0800 (PST) Subject: [eap] Survey: handling of retransmissions Message-ID: A question has arisen as to how retransmissions are handled in current implementations, as well as integrity check failures (within a method). a. What does your Peer implementation doif it receives multiple packets with the same Identifier before it has sent a Response? 1. Does it check whether the packets are "the same"? 2. Does it process the first packet, generate a Response, and clear the queue? 3. Does it process all the enqueued packets? 4. Does it drop all incoming packets other than the first one? b. What if there are multiple incoming packets with different Identifier values? c. What if, after sending an EAP packet up to the method, that packet fails a method-specific integrity check? If the method can handle it, can it silently discard the packet and ask for the next one in the queue? d. What about on the Authenticator side? 1. Does the authenticator enqueue Responses, or is only one Response allowed? 2. Is the incoming queue cleared after another Request is sent? 3. Are Responses that don't match the outstanding Request ID automatically discarded? From henry.haverinen@nokia.com Fri Dec 20 11:57:53 2002 From: henry.haverinen@nokia.com (henry.haverinen@nokia.com) Date: Fri, 20 Dec 2002 13:57:53 +0200 Subject: [eap] Survey: handling of retransmissions Message-ID: Hello, EAP SIM and EAP AKA are examples of methods that can silently=20 discard EAP packets based on an incorrect ICV.=20 It is also conceivable that an EAP method could delay the processing of some unprotected packet, say a method-specific notification. If another packet with a correct ICV is received during the delay, then the unprotected packet may be silently discarded. If no other packets are received, the method may decide to process the unprotected packet. This could also happen in EAP SIM, where ICV can only be included once=20 keys have been derived, so in the very first packets there is no ICV. If we further consider EAP SIM as an example, the fact that the very first packets are not MAC'd makes it easy to spoof packets. Of course spoofing will later be detected, but if only the first received packet is processed, then it is quite easy to mount a DoS attack. So it makes me wonder if some method implementations could process several copies of the=20 "same" packet and kind of "fork" separate states for each=20 processed packet. The spoofed states should later be detected and removed, but if the valid packets were processed separately,=20 the authentication could still succeed. Based on these examples, I'm inclined to think that the EAP layer should simply pass all EAP packets of a certain type to the appropriate method, and let the method decide how to process the packets. The EAP layer should not act as a "flip-flop" by keeping track of requests and corresponding responses or by flushing the packet queue. This would make the software interface between EAP layer and methods simple while allowing sophisticated processing of EAP packets. I don't know about any implementations that would work like=20 this, so I didn't answer the survey below. Regards, Henry > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 18 December, 2002 20:03 > To: eap@frascone.com > Subject: [eap] Survey: handling of retransmissions >=20 >=20 > A question has arisen as to how retransmissions are handled in current > implementations, as well as integrity check failures (within=20 > a method). >=20 > a. What does your Peer implementation doif it receives=20 > multiple packets > with the same Identifier before it has sent a Response? > 1. Does it check whether the packets are "the same"? > 2. Does it process the first packet, generate a Response, and clear > the queue? > 3. Does it process all the enqueued packets? > 4. Does it drop all incoming packets other than the first one? >=20 > b. What if there are multiple incoming packets with different=20 > Identifier > values? >=20 > c. What if, after sending an EAP packet up to the method, that packet > fails a method-specific integrity check? If the method can handle it, > can it silently discard the packet and ask for the next one in the > queue? >=20 > d. What about on the Authenticator side? > 1. Does the authenticator enqueue Responses, or is only one Response > allowed? > 2. Is the incoming queue cleared after another Request is sent? > 3. Are Responses that don't match the outstanding Request ID > automatically discarded? >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 From aboba@internaut.com Fri Dec 20 18:10:54 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 20 Dec 2002 10:10:54 -0800 (PST) Subject: [eap] Re: EAP packet processing In-Reply-To: <200212201654.gBKGsXL21886@internaut.com> Message-ID: > EAP SIM and EAP AKA are examples of methods that can silently > discard EAP packets based on an incorrect ICV. I presume they do silent discard in this case, not terminating the method, correct? > This could also > happen in EAP SIM, where ICV can only be included once > keys have been derived, so in the very first packets there > is no ICV. This is generally true. If the initial packets are spoofed, typically the ICV will fail later on - but this could take another roundtrip to be discovered. The way to fix this is for the method to incorporate some DoS resistance -- such as cookie state. Forking seems complicated. > Based on these examples, I'm inclined to think that the > EAP layer should simply pass all EAP packets of a certain > type to the appropriate method, and let the method > decide how to process the packets. To some extent, EAP methods have to be prepared to handle duplicates anyway. For example a NAS can timeout and send another Request before receiving the first Response in flight, and as a result, the AAA server may get multiple Responses. I believe that these will typically be passed up to the EAP method. Yet RFC 2284 does seem to mandate other checks, such as requiring Responses to have the same Identifier as Requests. Where are these checks supposed to be done? In the method? In the EAP layer? The question is really whether EAP methods are expecting to run over a reliable, sequenced transport, or not. From yohba@tari.toshiba.com Sat Dec 21 03:15:35 2002 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Fri, 20 Dec 2002 22:15:35 -0500 Subject: [eap] Re: EAP packet processing In-Reply-To: References: <200212201654.gBKGsXL21886@internaut.com> Message-ID: <20021221031535.GA759@catfish> On Fri, Dec 20, 2002 at 10:10:54AM -0800, Bernard Aboba wrote: > To some extent, EAP methods have to be prepared to handle duplicates > anyway. For example a NAS can timeout and send another Request before > receiving the first Response in flight, and as a result, the AAA server > may get multiple Responses. I believe that these will typically be passed > up to the EAP method. That, I believe depends on how the EAP switch state machine is designed. I think it is possible to design the EAP switch state machine similar to TCP so that duplicate responses are not passed up to the application (i.e., the EAP method). > > Yet RFC 2284 does seem to mandate other checks, such > as requiring Responses to have the same Identifier as Requests. Where are > these checks supposed to be done? In the method? In the EAP layer? > > The question is really whether EAP methods are expecting to run over a > reliable, sequenced transport, or not. If EAP methods can expect the EAP switch to provide a reliable, sequenced transport, that would be fine because total implementation cost can be reduced in that each method does not have to provide retransmission and duplicate detection, even the implementation cost for EAP switch state machine would increase. There are some Request messages that might require retransmission from the method (not from the EAP switch) if the Response requires human intervention (e.g., username, password input) as described in RFC2284bis, but different Identifier values can be used for such retransmission and the EAP switch would view them different Requests. But more investigation might be needed. Regarding the issue of ICV error, I think how to react when ICV error occurs (e.g., discard the message or terminate the method) depends on the method, and thus defining ICV error event in the EAP switch state machine does not make sence to me. Yoshihiro Ohba From aboba@internaut.com Sat Dec 21 18:52:00 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 21 Dec 2002 10:52:00 -0800 (PST) Subject: [eap] Request for feedback Message-ID: Since many of you will be taking a vacation during the holidays, may I suggest that you consider reading and commenting on an EAP draft during your downtime. EAP WG drafts make excellent reading material, particularly before bed time. For your consideration, I would like to recommend the following drafts: http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-08.txt http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-05.txt (Keying framework -05 strawman) As usual, Issues should be sent to the EAP WG mailing list using the format described at: http://www.drizzle.com/~aboba/EAP/eapissues.html From dharkins@trpz.com Wed Dec 18 20:51:03 2002 From: dharkins@trpz.com (Dan Harkins) Date: Wed, 18 Dec 2002 12:51:03 -0800 Subject: [eap] PEAP question Message-ID: <200212182051.gBIKp3B78884@homebrew.trpz.com> Hello! draft-josefsson-pppext-eap-tls-eap-02.html says that PEAP phase 2 is done "within the TLS session" established in PEAP phase 1. What exactly does that mean? The examples from appendix A show phase 2 packets like this: <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=X EAP-Response/ EAP-Type=X or NAK -> <- EAP-Request/ EAP-Type=X So what does the packet look like on the wire? The ID request the authenticator sends "within the TLS channel" cannot be an encrypted ID request because layer transporting EAP will not be able to decode it as an EAP packet. There's no EAP data to "protect" so it could be a raw ID request but then the supplicant state machine will transition back into ACQUIRED when it receives it. It must be a PEAP packet (length included) with the PEAP data being an encrypted EAP packet with the type=1. Correct? If so then the requests and responses are not EAP-Type=X, they're EAP-Type=PEAP and the PEAP data is an EAP packet with EAP-Type=X: <- EAP-Request/EAP-Type=PEAP/EAP-Request/EAP-Type=X So the phase 2 ID request from the authenticator looks like this on the wire: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Identifier | len(PEAP hdr+encryped idreq) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PEAP |1 0 0 0 0 0 0 1| length of encrypted... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... EAP ID request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ following is protected by TLS cipher suite +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Identifier+1? | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of id request | 1=ID | cruft... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | from TLS.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What then does one do about the identifiers in this packet? The one in the encrypted EAP header is one more than the one in the PEAP header? Are they the same? Is this even the correct format? Or have I completely missed something and the packets on the wire really have EAP-Type=X? If so then how do you encode the phase 2 id request? Dan. From aboba@internaut.com Mon Dec 23 12:41:51 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 23 Dec 2002 04:41:51 -0800 (PST) Subject: [eap] EAP binding problem statement: request for feedback Message-ID: At IETF 55, the attendees at the EAP WG meeting indicated an interest in working on the EAP compound binding problem. A first step toward that goal would be to take on the problem statement document as a WG work item: http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt However, before we do that, we would like to get comments from the EAP WG participants on the draft itself, as well as whether this would be appropriate as a WG work item. Since the problem is also being considered in other forums (IPsec WG, PANA WG), I am also going to post a request for feedback to the SAAG list.