From aboba@internaut.com Wed Jan 1 19:54:22 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 1 Jan 2003 11:54:22 -0800 (PST) Subject: [eap] Re: Survey: handling of retransmissions Message-ID: It is common for early messages within an EAP method to not contain a message integrity check, because a key has not yet been negotiated. This problem occurs in TLS [RFC2246], for which the solution is to include all the handshake messages within the MIC included in the Finished message. If we can assume that the EAP conversation is available to a method (not clear), then this could work, although it would not address the DoS issue. I think what you are saying is that some EAP methods may wish to process packets themselves (e.g. they want a "UDP" transport) while others might want a reliable transport. This makes some sense to me -- but I am still trying to figure out exactly what transport service RFC 2284 had in mind, and what implementations do. For example, RFC 2284bis talks about not passing duplicate Requests to the EAP method in the case of a token card, so I think that it supports duplicate elimination of a sort. However, once the Response is sent it could be lost, and so the EAP Peer EAP can receive the same Request again. In that case, I think that RFC 2284 implies that the duplicate Request is passed to the EAP method, which is presumed to have kept state and therefore can resend the previous Response. If that is true, then duplicate elimination is sometimes the responsibility of the EAP layer (when a Response is pending) and sometimes not (when a Response is not pending). This is not the service that a reliable, non-duplicating transport provides -- and protocols like TLS do assume that they run over such a service. If someone has a different reading of RFC 2284, please speak up. On December 20, 2002 Henry Haverinen said this: 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 From james.d.carlson@east.sun.com Thu Jan 2 12:12:40 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 2 Jan 2003 07:12:40 -0500 Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: Bernard Aboba's message of 1 January 2003 11:54:22 References: Message-ID: <15892.11448.55312.944756@gargle.gargle.HOWL> Bernard Aboba writes: > I think what you are saying is that some EAP methods may wish to > process packets themselves (e.g. they want a "UDP" transport) > while others might want a reliable transport. This makes some > sense to me -- but I am still trying to figure out exactly what > transport service RFC 2284 had in mind, and what implementations do. It seems to me that what you're talking about here is really an internal design issue, and not an on-the-wire protocol issue. > For example, RFC 2284bis talks about not passing duplicate > Requests to the EAP method in the case of a token card, so I > think that it supports duplicate elimination of a sort. However, > once the Response is sent it could be lost, and so the EAP Peer > EAP can receive the same Request again. In that case, > I think that RFC 2284 implies that the duplicate Request is > passed to the EAP method, which is presumed to have kept state > and therefore can resend the previous Response. What's the difference? Suppose the software that supports the interface between EAP and the token card method is itself smart enough to eliminate duplicates. Wouldn't that solve the problem? This looks like software and programming interface design, not protocol. Other than implementation bugs, is there any way that someone viewing this conversation on the wire can tell if the duplicates were eliminated within EAP or within the method? If the answer is "no," then there's no protocol issue here. > If someone has a different reading of RFC 2284, please speak up. My reading of the original RFC is much simpler: the authenticator sends a Request message. It waits for a Response. If there is none, then it resends the Request or takes any other action that it deems appropriate (trying a different method, disconnecting the session). There is intentionally no discussion of the internal software design: you can do the methods as a single piece of code with switches, as a plug-in architecture, or as some O-O monstrosity. As long as it sends the right messages on the wire, the design issues involved in making those differing implementation models work right is *NOT* a protocol issue and thus not an appropriate IETF issue. I don't see how internal software interfaces between EAP and its methods make any difference to the protocol as viewed on the wire. Or, more to the point: if you're not able to get the behavior on the wire that the document for the method in use describes, then the software design is bad, not the document. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Thu Jan 2 12:27:56 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 2 Jan 2003 07:27:56 -0500 Subject: [eap] rfc2284bis-08: turn-around description Message-ID: <15892.12364.552383.349397@gargle.gargle.HOWL> The turn-around description is not correct given current PPP practice, nor does it seem practical. (If you're to turn the link around, then one of the two equal peers must go first. Which one?) Submitter name: James Carlson Submitter email address: james.d.carlson@sun.com. Date first submitted: January 2, 2003 Document: RFC2284bis Comment type: T Priority: S Section: 2 Rationale/Explanation of issue: This problem seems to have been introduced with the resolution to issue #48. The description, though, is at odds with the original EAP design and usage in PPP. Despite the text, there is no requirement of synchronization between the independent authentication sessions in each direction. The words "after" and "complete" are misleading. Requested change: from: [7] Since EAP is a Peer-to-Peer protocol, after authentication in one direction is complete, the direction of authentication MAY reverse, with the endpoint previously serving as the Authenticator assuming the Peer role, and the former Peer now taking on the Authenticator role. As with the original conversation, the reversal is signalled by the (new) Authenticator sending a Request. Support for bi- directional authentication requires that each endpoint implement both the Peer and Authenticator roles. to: [7] Since EAP is a Peer-to-Peer protocol, an independent and simultaneous authentication may take place in the reverse direction. Both peers may act as authenticators and authenticatees at the same time. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Thu Jan 2 12:48:15 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 2 Jan 2003 07:48:15 -0500 Subject: [eap] rfc2284bis-08: identity requery Message-ID: <15892.13583.179417.196915@gargle.gargle.HOWL> The Identity description limits usage such that this message cannot be sent in the "middle of another method." Since EAP itself isn't stateful in this way -- there's no indication on the wire of whether the authenticator is in the "middle" of a method or has suddenly decided to start over from the beginning -- this restriction doesn't appear to help, and does hurt. Submitter name: James Carlson Submitter email address: james.d.carlson@sun.com. Date first submitted: January 2, 2003 Document: RFC2284bis Comment type: T Priority: 1 Section: 5.1 Rationale/Explanation of issue: The restriction doesn't appear to be warranted. There's no visible difference between, for example, an authenticator suddenly deciding to start authentication over because the current method cannot proceed (which should be allowed), and sending an Identity message in the "middle" of a method (which has been proscribed). Since there's no distinction, the requirements can't be different. Requested change: from: The Identity Type is used to query the identity of the Peer. The Authenticator will typically issue this as the initial Request; however, an Identity Request MAY also be sent multiple times within a sequence of methods. An Identity Request MUST NOT be sent in the middle of another method conversation. to: The Identity Type is used to query the identity of the Peer. The Authenticator will typically issue this as the initial Request; however, an Identity Request MAY be sent at any time. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Thu Jan 2 12:56:24 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 2 Jan 2003 07:56:24 -0500 Subject: [eap] rfc2284bis-08: issue 35 redux Message-ID: <15892.14072.574635.177557@gargle.gargle.HOWL> It appears to me that issue 35 (Nak of an Identity message) was resolved incorrectly. RFC 2284 allowed an implementation to send Nak for Identity messages. The fact that common implementations don't *use* this mechanism to any good effect is not a sufficient reason to make Identity a special case in the protocol. Submitter name: James Carlson Submitter email address: james.d.carlson@sun.com. Date first submitted: January 2, 2003 Document: RFC2284bis Comment type: T Priority: S Section: 5.1 Rationale/Explanation of issue: The change made in this draft breaks compatibility with the prior RFC, and doesn't appear to add any benefit. Worse, it means that there's now a completely undefined corner in the protocol: what do you do if the peer sends Nak for Identity anyway? Do you terminate? Try again? This was once well-defined (process as you would for any Nak), and is now undefined. Requested change: from: An optional displayable message MAY be included within an Identity Request, to prompt the Peer in the case where there is an expectation of interaction with a user. An Identity Response MUST be sent to an Identity Request. A Peer MUST NOT respond to an Identity Request with a NAK. to: An optional displayable message MAY be included within an Identity Request, to prompt the Peer in the case where there is an expectation of interaction with a user. An Identity Response MUST be sent to an Identity Request. A peer with no known identity to offer MAY send Nak instead. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Thu Jan 2 13:05:03 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 2 Jan 2003 08:05:03 -0500 Subject: [eap] rfc2284bis-08: problem with Nak type Message-ID: <15892.14591.885344.317180@gargle.gargle.HOWL> The Length description for Nak says >= 5, but the text description indicates that the Authentication Type field could be omitted (length 4) if it's just a Nak with no suggested alternative. Submitter name: James Carlson Submitter email address: james.d.carlson@sun.com. Date first submitted: January 2, 2003 Document: RFC2284bis Comment type: T Priority: 1 Section: 5.1 Rationale/Explanation of issue: This also breaks RFC 2284 compatibility. In the original RFC, the type field was *required*. Systems implemented to RFC 2284 will *discard* bogus Nak messages that don't have a suggested type field. Instead, if "Nak with no alternative" is required (I don't think it is), then I suggest either a reserved value (e.g., 0) or (better yet) using the value 1 (Identity) to tell the peer to start over. Requested change: from: The Nak Type is valid only in Response messages. It is sent in reply to a method proposal (the initial EAP Request for a given Type) where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains zero or one authentication Type desired by the Peer. A Nak with no authentication Type indicates that the Peer does not wish to authenticate using the proposed method but is not proposing an alternative. to: The Nak Type is valid only in Response messages. It is sent in reply to a method proposal (the initial EAP Request for a given Type) where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains a single octent authentication Type desired by the Peer. This value may be 1 (Identity) to indicate that the sender has no viable alternatives, or that the authentication attempt should be restarted. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Thu Jan 2 13:22:11 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 2 Jan 2003 08:22:11 -0500 Subject: [eap] rfc2284bis-08: formatting errors Message-ID: <15892.15619.103808.379778@gargle.gargle.HOWL> The header on the draft is not in compliance with 1id-guidelines.txt or RFC 2223. Submitter name: James Carlson Submitter email address: james.d.carlson@sun.com. Date first submitted: January 2, 2003 Document: RFC2284bis Comment type: E Priority: 2 Section: 0 Rationale/Explanation of issue: Internet Drafts are not RFCs and must not use RFC language, such as "standards track" or "obsoletes." Document expiry must be made prominent. Requested change: from: EAP Working Group L. Blunk INTERNET-DRAFT Merit Networks, Inc. Category: Standards Track J. Vollbrecht Interlink Networks, Inc. 28 November 2002 Bernard Aboba Obsoletes: RFC 2284 Microsoft [...] Blunk, Vollbrecht & Aboba Standards Track [Page 35] INTERNET-DRAFT RFC2284bis 28 November 2002 [...] to: Network Working Group L. Blunk INTERNET-DRAFT Merit Networks, Inc. Expires: June 2003 J. Vollbrecht Interlink Networks, Inc. Bernard Aboba Microsoft [...] Blunk, Vollbrecht & Aboba Expires June 2003 [Page 35] INTERNET-DRAFT RFC2284bis November 2002 [...] -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Thu Jan 2 13:23:54 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 2 Jan 2003 08:23:54 -0500 Subject: [eap] rfc2284bis-08: problem with Nak type In-Reply-To: James Carlson's message of 2 January 2003 08:05:03 References: <15892.14591.885344.317180@gargle.gargle.HOWL> Message-ID: <15892.15722.308264.210683@gargle.gargle.HOWL> James Carlson writes: > The Length description for Nak says >= 5, but the text description > indicates that the Authentication Type field could be omitted (length > 4) if it's just a Nak with no suggested alternative. [...] > Section: 5.1 [...] Obviously, that should be 5.3. (Am I the only one who finds the form required for commentary to be far too difficult to use?) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Jan 2 16:32:32 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 2 Jan 2003 08:32:32 -0800 (PST) Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: <15892.11448.55312.944756@gargle.gargle.HOWL> Message-ID: > this conversation on the wire can tell if the duplicates were > eliminated within EAP or within the method? If the answer is "no," > then there's no protocol issue here. The definition of the EAP layer transport service impacts on-the-wire behavior, as well as security. As has been pointed out, there are protocols (such as TLS) that assume a reliable duplicate-free transport. If they are not provided with this service, then they may not function well -- and this will be reflected in on-the-wire behavior. Similarly, there may be EAP methods that prefer to do their own duplicate elimination, such as those that consider MIC failures to be non-fatal. If you take an implementation that does duplicate elimination in the EAP layer, and one that does it in the method layer, and implement such a method above it, you will not see the same on-the-wire behavior, particularly in the case where a DoS attack is in progress. From aboba@internaut.com Thu Jan 2 16:37:21 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 2 Jan 2003 08:37:21 -0800 (PST) Subject: [eap] Naming of keys (fwd) Message-ID: ---------- Forwarded message ---------- Date: Thu, 2 Jan 2003 08:51:19 -0800 From: "Walker, Jesse" To: Bernard Aboba Subject: RE: Request for feedback One thing missing from the key problem draft is a way to name keys. Each method needs to describe how it identifies keys. This means there must be some way to indicate which key the method derived and how to identify that it belongs to this and not to some other session. This functionality will become important to resolve synchronization issues that arise due to roaming. I did not get around to rfc2284bis, but will try to go through it prior to the 802.11 meeting in Ft. Lauderdale. -- Jesse From james.d.carlson@east.sun.com Thu Jan 2 18:22:54 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 2 Jan 2003 13:22:54 -0500 Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: Bernard Aboba's message of 2 January 2003 08:32:32 References: <15892.11448.55312.944756@gargle.gargle.HOWL> Message-ID: <15892.33662.607295.699193@gargle.gargle.HOWL> Bernard Aboba writes: > > this conversation on the wire can tell if the duplicates were > > eliminated within EAP or within the method? If the answer is "no," > > then there's no protocol issue here. > > The definition of the EAP layer transport service impacts on-the-wire > behavior, as well as security. I think one of the security issues you're referring to is the DoS issue -- if the authenticatee is somehow proxying out handling of Request messages (note that this isn't possible with RADIUS or DIAMETER; not that this matters), then the implementation needs to be smart enough to limit or eliminate the queue of messages that can build up before a Response is generated by the proxy. But how is that really visible to an EAP peer on the wire? Here's the behavior conjectured: Authenticator Authenticatee Request #1 --> (goes out to lunch handling request) Request #2 --> XXX dropped by flush Request #3 --> XXX dropped by flush <-- back from lunch: Response #1 (old id 1; drop) (timeout) Request #4 --> ... Here's possible scenario (on a slow, error-prone link) that does *not* include the behavior described in the draft (pardon the ASCII art; it's hard to show time delays) and is yet indistinguishable: Authenticator Authenticatee Request #1 - Request #2 -\ Request #3 -\\__ Handle Request #1; send Response #1 \\__ Request #2 send Response #2 /\__ Request #3 send Response #3 (old id 1; drop) // (old id 2; drop) X (id 3 lost in transit) (timeout) Request #4 --> ... While I agree that, as an implementation issue, it's wise for an implementation that finds processing EAP messages to be "expensive" (for whatever local definition of 'expensive' implies) to discard as much as possible rather than being slogged down by an unfriendly peer, I disagree that these sorts of details are necessarily appropriate for a document that describes a protocol, except perhaps as asides. Part of the issue here is that it's not just what's theoretically observable by someone who does not bother implementing the protocol as defined, but what's materially important to the behavior given the constraints of the protocol, which is why I ask how it matters. Since the behavior is defined in terms of Response ID numbers that must *exactly* match the most recent Request ID number, any other responses that happen just aren't material. They MUST be discarded by any reasonable implementation. It is as if they never occur. Note that the same thing happens for retransmit cases where the id numbers are not changed -- any straggling duplicates are immaterial because they won't match the latest Request ID number when they finally arrive. Anything else is an implementation bug. > As has been pointed out, there are protocols (such as TLS) that assume > a reliable duplicate-free transport. If they are not provided with this > service, then they may not function well -- and this will be reflected in > on-the-wire behavior. Since RFC 2284's usage of ID numbers provides a duplicate-free messaging mechanism, I don't see how that could be understood as anything other than an implementation error. If the algorithm chosen can't handle duplicate messages, then the definition of the method for EAP needs to address this. Whether an EAP software module, when treated as a "transport," provides duplicate-free messaging or relies on the methods themselves to detect and deal with duplicates as necessary still looks to me like an internal software interface implementation issue. Assuming the implementation isn't flawed, how can a peer tell whether EAP itself handled the duplicate or the EAP plug-in method did the job? (If we have to assume that the implementation is flawed to get here, then I think that's enough reason to leave it out of the draft. IETF standards-track documents shouldn't be a tutorial on how to write networking software.) > Similarly, there may be EAP methods that prefer to do their own duplicate > elimination, such as those that consider MIC failures to be non-fatal. > If you take an implementation that does duplicate elimination in the EAP > layer, and one that does it in the method layer, and implement such a > method above it, you will not see the same on-the-wire behavior, > particularly in the case where a DoS attack is in progress. If you take link propagation delays into account, the whole issue becomes indeterminate. Since the previous Response may already be in flight, there is *NO* way for the sender of a new EAP Request (or a passive observer on the wire) to know whether the previous request has actually completed. There are several cases possible here: 1. The previous Request isn't done, and (per the draft) the new Request is discarded. The authenticator sees the old Response alone. 2. The previous Request is already done, and the Response is somewhere in flight. The old Response to the prior Request will eventually arrive, *and* the new Request will be dispatched and acted upon as well, and generate a Response. If the old Request had the same ID (i.e., the new one is a retransmit), then the old Response satisfies the Request, and the new Response is discarded (wrong ID). If the old request had a different ID, then the old Response is discarded (wrong ID), and the new one is used. 3. The previous Request is already done, and the Response is in flight. The new Request itself can be lost due to transmission errors, and the new Response can be lost in the same way. The effect is indistinguishable from (1). Note that (2) is both legal and impermissible according to the current language of the draft. The draft can't outlaw physics -- propagation delays will still happen -- but the draft asserts that queued messages must be discarded. Since the real input queue extends from the receiving EAP implementation on one side back through the underlying drivers, the wires, and up through the transmit logic on the sender's side, the receiver can't actually do what's demanded. It can only approximate that behavior by flushing some nearby queues. Where you can't actually tell the difference, and where the differences are discarded by properly-implemented peers, I suggest that these differences don't matter and ought not be specified. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Jan 2 17:36:22 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 2 Jan 2003 09:36:22 -0800 (PST) Subject: [eap] Re: Issue 51: Turnaround Description Message-ID: This looks reasonable. Any objections to accepting this change? Issue 51: Turnaround description Submitter name: James Carlson Submitter email address: james.d.carlson@sun.com. Date first submitted: January 2, 2003 Document: RFC2284bis Comment type: T Priority: S Section: 2 Rationale/Explanation of issue: This problem seems to have been introduced with the resolution to issue #48. The description, though, is at odds with the original EAP design and usage in PPP. Despite the text, there is no requirement of synchronization between the independent authentication sessions in each direction. The words "after" and "complete" are misleading. Requested change: from: [7] Since EAP is a Peer-to-Peer protocol, after authentication in one direction is complete, the direction of authentication MAY reverse, with the endpoint previously serving as the Authenticator assuming the Peer role, and the former Peer now taking on the Authenticator role. As with the original conversation, the reversal is signalled by the (new) Authenticator sending a Request. Support for bi- directional authentication requires that each endpoint implement both the Peer and Authenticator roles. to: [7] Since EAP is a Peer-to-Peer protocol, an independent and simultaneous authentication may take place in the reverse direction. Both peers may act as authenticators and authenticatees at the same time. From aboba@internaut.com Thu Jan 2 17:45:11 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 2 Jan 2003 09:45:11 -0800 (PST) Subject: [eap] Re: Issue 53: NAK of Identity message Message-ID: Here is the text in RFC 2284 that lead to the conclusion that Identity Requests (and Notification Requests) can't be NAK'd: Section 3.3 "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." Since Identity is Type 1, and Notification is Type 2, the conclusion was drawn that NAKs cannot be sent in response to these requests. Section 3.1 states: "A Response MUST be sent to this Request with a Type of 1 (Identity)." This could be interpretted as saying that the Response MUST be of Type 1, or that a Response MUST be sent when the Request is of Type 1. Issue 53: NAK of Identity message Submitter name: James Carlson Submitter email address: james.d.carlson@sun.com. Date first submitted: January 2, 2003 Document: RFC2284bis Comment type: T Priority: S Section: 5.1 Rationale/Explanation of issue: The change made in this draft breaks compatibility with the prior RFC, and doesn't appear to add any benefit. Worse, it means that there's now a completely undefined corner in the protocol: what do you do if the peer sends Nak for Identity anyway? Do you terminate? Try again? This was once well-defined (process as you would for any Nak), and is now undefined. Requested change: from: An optional displayable message MAY be included within an Identity Request, to prompt the Peer in the case where there is an expectation of interaction with a user. An Identity Response MUST be sent to an Identity Request. A Peer MUST NOT respond to an Identity Request with a NAK. to: An optional displayable message MAY be included within an Identity Request, to prompt the Peer in the case where there is an expectation of interaction with a user. An Identity Response MUST be sent to an Identity Request. A peer with no known identity to offer MAY send Nak instead. From james.d.carlson@east.sun.com Thu Jan 2 19:01:11 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 2 Jan 2003 14:01:11 -0500 Subject: [eap] Re: Issue 53: NAK of Identity message In-Reply-To: Bernard Aboba's message of 2 January 2003 09:45:11 References: Message-ID: <15892.35959.912630.431677@gargle.gargle.HOWL> Bernard Aboba writes: > Here is the text in RFC 2284 that lead to the conclusion that Identity > Requests (and Notification Requests) can't be NAK'd: > > Section 3.3 > > "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." That part seems like a mostly reasonable interpretation, though I'm less convinced that equating "identity is the null string" and "facility to identify peer is unavailable" together is a good thing. In that case, I think the text should indicate what an implementation should (or may) do if it sees Types 0 to 3 in a Nak. > Section 3.1 states: > > "A Response MUST be sent to this Request with a Type of 1 (Identity)." > > This could be interpretted as saying that the Response MUST be of Type 1, > or that a Response MUST be sent when the Request is of Type 1. I've always read that as the former -- if any Response is generated, it must have Type set to 1. I read it that way because of the nearly identical text in section 3.6: The Type-Data field in the Request contains a displayable message greater than zero octets in length. The length of the message is determined by Length field of the Request packet. The message MUST not be null terminated. A Response MUST be sent in reply to the Request with a Type field of 6 (Generic Token Card). The Response contains data from the Token Card required for authentication. The length is of the data is determined by the Length field of the Response packet. Surely, that can't possibly mean that nobody is allowed to send Nak for Generic Token Card. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Jan 2 17:56:48 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 2 Jan 2003 09:56:48 -0800 (PST) Subject: [eap] Re: Issue 54: Problem with NAK type Message-ID: Here is the text from RFC 2284 that might support the conclusion that the NAK Type might contain no alternatives: Section 2.2.1: When sending a Nak in response to a Request, the peer MAY indicate an alternative desired authentication Type which it supports. On the other hand, section 3.3 says: This field MUST contain a single octet indicating the desired authentication type. John V. or Larry Blunk -- can you clarify the intent here? ------------------------------------------------------------ Issue 54: Problem with NAK type Submitter name: James Carlson Submitter email address: james.d.carlson@sun.com. Date first submitted: January 2, 2003 Document: RFC2284bis Comment type: T Priority: 1 Section: 5.3 Rationale/Explanation of issue: This also breaks RFC 2284 compatibility. In the original RFC, the type field was *required*. Systems implemented to RFC 2284 will *discard* bogus Nak messages that don't have a suggested type field. Instead, if "Nak with no alternative" is required (I don't think it is), then I suggest either a reserved value (e.g., 0) or (better yet) using the value 1 (Identity) to tell the peer to start over. Requested change: from: The Nak Type is valid only in Response messages. It is sent in reply to a method proposal (the initial EAP Request for a given Type) where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains zero or one authentication Type desired by the Peer. A Nak with no authentication Type indicates that the Peer does not wish to authenticate using the proposed method but is not proposing an alternative. to: The Nak Type is valid only in Response messages. It is sent in reply to a method proposal (the initial EAP Request for a given Type) where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains a single octet authentication Type desired by the Peer. This value may be 1 (Identity) to indicate that the sender has no viable alternatives, or that the authentication attempt should be restarted. From aboba@internaut.com Thu Jan 2 18:01:35 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 2 Jan 2003 10:01:35 -0800 (PST) Subject: [eap] Re: Issue 53: NAK of Identity message In-Reply-To: <15892.35959.912630.431677@gargle.gargle.HOWL> Message-ID: > That part seems like a mostly reasonable interpretation, though I'm > less convinced that equating "identity is the null string" and > "facility to identify peer is unavailable" together is a good thing. > > In that case, I think the text should indicate what an implementation > should (or may) do if it sees Types 0 to 3 in a Nak. Any suggestions? > > "A Response MUST be sent to this Request with a Type of 1 (Identity)." > > > > This could be interpretted as saying that the Response MUST be of Type 1, > > or that a Response MUST be sent when the Request is of Type 1. > > I've always read that as the former -- if any Response is generated, > it must have Type set to 1. That's how I read it as well. From aboba@internaut.com Thu Jan 2 18:11:29 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 2 Jan 2003 10:11:29 -0800 (PST) Subject: [eap] Re: Issue 55: Header issues Message-ID: This seems reasonable. Any objections to the proposed header changes? Issue 55: Header issues Submitter name: James Carlson Submitter email address: james.d.carlson@sun.com. Date first submitted: January 2, 2003 Document: RFC2284bis Comment type: E Priority: 2 Section: 0 Rationale/Explanation of issue: Internet Drafts are not RFCs and must not use RFC language, such as "standards track" or "obsoletes." Document expiry must be made prominent. Requested change: from: EAP Working Group L. Blunk INTERNET-DRAFT Merit Networks, Inc. Category: Standards Track J. Vollbrecht Interlink Networks, Inc. 28 November 2002 Bernard Aboba Obsoletes: RFC 2284 Microsoft [...] Blunk, Vollbrecht & Aboba Standards Track [Page 35] INTERNET-DRAFT RFC2284bis 28 November 2002 [...] to: Network Working Group L. Blunk INTERNET-DRAFT Merit Networks, Inc. Expires: June 2003 J. Vollbrecht Interlink Networks, Inc. Bernard Aboba Microsoft [...] Blunk, Vollbrecht & Aboba Expires June 2003 [Page 35] INTERNET-DRAFT RFC2284bis November 2002 [...] From james.d.carlson@east.sun.com Thu Jan 2 19:22:37 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 2 Jan 2003 14:22:37 -0500 Subject: [eap] Re: Issue 54: Problem with NAK type In-Reply-To: Bernard Aboba's message of 2 January 2003 09:56:48 References: Message-ID: <15892.37245.92798.213161@gargle.gargle.HOWL> Bernard Aboba writes: > Section 2.2.1: > > When sending a Nak in response to a > Request, the peer MAY indicate an alternative desired > authentication Type which it supports. I ways assumed that meant "or might have non-working garbage such as zero in this field," but you're right that it's lacking detail on what was intended in the 'not' case. > to: > The Nak Type is valid only in Response messages. It is sent in reply > to a method proposal (the initial EAP Request for a given Type) where > the desired authentication Type is unacceptable. Authentication Types > are numbered 4 and above. The Response contains a single octet > authentication Type desired by the Peer. This value may be 1 > (Identity) to indicate that the sender has no viable alternatives, > or that the authentication attempt should be restarted. Actually, now that I've looked that over again, I'd like to amend it further by removing the word "initial." EAP as defined in RFC 2284 has no such concept as "method proposal." There's no reason that I can see to suppose that the first Request of a given Type is somehow special, beyond what the method definition itself specifies. More to the point: there's no apparent reason to prohibit an implementation from getting half way through an authentication method before saying "oops; I can't go on -- please use something else." (I think the "method proposal" language is another example of the implementation leaking into the protocol specification: the fact that any vendor's implementation internally presumes that it will run one method to completion and then signal another method to run has nothing to do with the definition of EAP itself. Especially because of fast rechallenge support in some methods, I think this needs to be left to the documentation of the individual methods. That is, *if* the authenticatee can presume anything at all from seeing a different Type in a Request [i.e., "discard state here"], then that needs to be documented.) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Jan 2 18:18:07 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 2 Jan 2003 10:18:07 -0800 (PST) Subject: [eap] Re: Issue 52: Identity requery Message-ID: Question: Are you also asserting that a new method can be started prior to completion of a previous method? I think that the state machine document assumes that this is not possible (which lead to the restriction on Identity, too). Issue 52: Identity requery Submitter name: James Carlson Submitter email address: james.d.carlson@sun.com. Date first submitted: January 2, 2003 Document: RFC2284bis Comment type: T Priority: 1 Section: 5.1 Rationale/Explanation of issue: The restriction doesn't appear to be warranted. There's no visible difference between, for example, an authenticator suddenly deciding to start authentication over because the current method cannot proceed (which should be allowed), and sending an Identity message in the "middle" of a method (which has been proscribed). Since there's no distinction, the requirements can't be different. Requested change: from: The Identity Type is used to query the identity of the Peer. The Authenticator will typically issue this as the initial Request; however, an Identity Request MAY also be sent multiple times within a sequence of methods. An Identity Request MUST NOT be sent in the middle of another method conversation. to: The Identity Type is used to query the identity of the Peer. The Authenticator will typically issue this as the initial Request; however, an Identity Request MAY be sent at any time. From james.d.carlson@east.sun.com Thu Jan 2 19:55:27 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 2 Jan 2003 14:55:27 -0500 Subject: [eap] Re: Issue 52: Identity requery In-Reply-To: Bernard Aboba's message of 2 January 2003 10:18:07 References: Message-ID: <15892.39215.83083.193276@gargle.gargle.HOWL> Bernard Aboba writes: > Question: Are you also asserting that a new method can be started prior to > completion of a previous method? I think that the state machine > document assumes that this is not possible (which lead to the restriction > on Identity, too). I'm saying that stating this as a restriction on the authenticator doesn't make sense to me. Suppose the authenticator wants to give up on the currently running method (due, perhaps, to compatibility problems with the peer) and decides to try an alternative method. Does the authenticator need to provide any notification to the authenticatee that it wants to start over? Would that notification need to be anything more than a Request message with a new Type value? Or is the authenticator "forced" to continue with the current method, even if continuation is infeasible? I'm not saying that it makes sense to have multiple concurrent methods running at one time. But it also doesn't make sense to me to say that the authenticator needs to be limited in any way in its choice of Request messages to send. The original EAP model seemed much simpler to me: the authenticator is the master, and the authenticatee is a slave. The authenticatee must respond to requests it gets at best it can, and can't be in the business of predicting the future. If there's some concern about fully documenting how to *implement* an authenticatee (though I don't think there should be), then language like this might work: Other than Type 2 (Notification), which is unrelated to the operation of any authentication method, and Type 3 (Nak), which is used in a session operating in the opposite direction, an authenticatee receiving any Type number that differs from the previous Type number may assume (e.g., for purposes of allocating transient storage) that the method indicated by any previous Type number received has concluded. I don't think this is actually required for proper operation, though. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Jan 2 20:48:31 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 2 Jan 2003 12:48:31 -0800 (PST) Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: <15892.33662.607295.699193@gargle.gargle.HOWL> Message-ID: > I think one of the security issues you're referring to is the DoS > issue -- if the authenticatee is somehow proxying out handling of > Request messages Actually, I think the DoS attack that people had in mind was one where the attacker is sending bogus EAP messages, possibly cycling through the Identifier space, until the right value is found. The bogus packets have the correct CRC so they are processed by the link layer, but might not have the right Code or Type. If the method includes a MIC, it can be assumed that the bogus packets will fail the MIC check. As an example, the attacker might send: a. Forged EAP Success packets, hoping to convince the Peer to connect to a rogue Authenticator, bypassing mutual authentication. b. Forged EAP Failure packets, hoping to abort the conversation. c. Forged EAP Requests of a different Type, hoping to abort the conversation. d. Forged EAP Requests or Responses which fail the MIC check. The question is how Peers and Authenticators will react to these attacks. > But how is that really visible to an EAP peer on the wire? Here's the > behavior conjectured: > > Authenticator Authenticatee > Request #1 --> > (goes out to lunch handling request) > Request #2 --> XXX dropped by flush > Request #3 --> XXX dropped by flush > <-- back from lunch: Response #1 > (old id 1; drop) > (timeout) > Request #4 --> ... Are requests 2 and 3 retransmissions of 1? If so, then shouldn't the Authenticatee's Response be processed? If not, then why is the Authenticator sending a new Request rather than retransmitting? > Here's possible scenario (on a slow, error-prone link) that does *not* > include the behavior described in the draft (pardon the ASCII art; > it's hard to show time delays) and is yet indistinguishable: > > Authenticator Authenticatee > Request #1 - > Request #2 -\ > Request #3 -\\__ Handle Request #1; send Response #1 > \\__ Request #2 send Response #2 > /\__ Request #3 send Response #3 > (old id 1; drop) // > (old id 2; drop) X > (id 3 lost in transit) > (timeout) > Request #4 --> ... Yes, this can happen. The difference is that in the first case, there are no duplicate Responses, but in the second case, there are (assuming that 2 and 3 are retransmissions of 1). > I disagree that these sorts of details are necessarily appropriate for > a document that describes a protocol, except perhaps as asides. That seems sensible, but what if you have a situation like this: Authenticator Authenticatee Real Request: ID 22 -------> Attacker: Bogus Request: ID 22 ---------> Assume that both the bogus and real request have valid CRCs, but that the bogus request fails a MIC check and the real request passes. How does the Authenticatee behave? Some possibilities: a. The Real Request is processed, and elicits a Response. The Authenticatee then sees a Bogus Request with the same ID, and resends the Response, even though the Bogus Request is different. b. The Real Request is processed, and elicits a Response. The Authenticatee then sees a Bogus Request with the same ID, and processes the Request, which fails the MIC check. The Authenticatee then either silently discards (if the method defines that) or aborts (EAP TLS). > the behavior is defined in terms of Response ID numbers that must > *exactly* match the most recent Request ID number, any other responses > that happen just aren't material. They MUST be discarded by any > reasonable implementation. It is as if they never occur. Agreed. > Note that the same thing happens for retransmit cases where the id > numbers are not changed -- any straggling duplicates are immaterial > because they won't match the latest Request ID number when they > finally arrive. Anything else is an implementation bug. Agreed -- though I'm not sure that the document indicates this clearly enough. > Since RFC 2284's usage of ID numbers provides a duplicate-free > messaging mechanism Does it? It seems like it just provides for reliable delivery of *at least one* copy of the message. The question is exactly how duplicates are processed, and RFC 2284 doesn't seem clear on how that occurs. > implementation isn't flawed, how can a peer tell whether EAP itself > handled the duplicate or the EAP plug-in method did the job? I don't think it can tell -- but the question is what the expected behavior is, and whether a method will behave the same way if hosted on every EAP implementation or not. If the method needs to be able to handle duplicates, then that would be something that would be specified in its design. > but the draft asserts that queued messages > must be discarded. I think that we agree that the draft is wrong -- but the question is how to fix it. > Where you can't actually tell the difference, and where the > differences are discarded by properly-implemented peers, I suggest > that these differences don't matter and ought not be specified. I think you are right about that. From james.d.carlson@east.sun.com Thu Jan 2 22:22:28 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 2 Jan 2003 17:22:28 -0500 Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: Bernard Aboba's message of 2 January 2003 12:48:31 References: <15892.33662.607295.699193@gargle.gargle.HOWL> Message-ID: <15892.48036.436050.22296@gargle.gargle.HOWL> Bernard Aboba writes: > > I think one of the security issues you're referring to is the DoS > > issue -- if the authenticatee is somehow proxying out handling of > > Request messages > > Actually, I think the DoS attack that people had in mind was one where the > attacker is sending bogus EAP messages, possibly cycling through the > Identifier space, until the right value is found. The bogus packets > have the correct CRC so they are processed by the link layer, > but might not have the right Code or Type. If the method includes a MIC, > it can be assumed that the bogus packets will fail the MIC check. OK. That's a different case, but I don't think it raises new issues. In that case, there needs to be some sort of backdoor interface between the EAP 'method' that computes the information necessary for the MIC, and the EAP 'mechanism' that does the actual per-message generation and checking. > The question is how Peers and Authenticators will react to these attacks. Assuming it's properly implemented, the system drops the bad messages. Whether they're dropped within an "EAP layer," a "method interface," or even in some front-end processing mechanism sounds like a local design issue to me. > > But how is that really visible to an EAP peer on the wire? Here's the > > behavior conjectured: > > > > Authenticator Authenticatee > > Request #1 --> > > (goes out to lunch handling request) > > Request #2 --> XXX dropped by flush > > Request #3 --> XXX dropped by flush > > <-- back from lunch: Response #1 > > (old id 1; drop) > > (timeout) > > Request #4 --> ... > > Are requests 2 and 3 retransmissions of 1? Not in that illustration. > If so, then shouldn't the > Authenticatee's Response be processed? If not, then why is the > Authenticator sending a new Request rather than retransmitting? There's nothing in RFC 2284 to prohibit the authenticator from deciding to switch authentication mechanisms for any reason. However, if you feel more comfortable dealing with pure retransmits, then here you go: Authenticator Authenticatee Request #1 --> (goes out to lunch handling request) Request #1 --> XXX dropped by flush Request #1 --> XXX dropped by flush <-- back from lunch: Response #1 Got response #1 Request #2 --> Send Response #2 Got response #2 versus: Authenticator Authenticatee Request #1 --> Send Response #1 Request #1 --> Send Response #1 Request #1 --> Send Response #1 Got response #1 Request #2 --> ... Discard old #1 Discard old #1 Got response #2 Again, if you add in transmission delays, you can easily make these two cases indistinguishable on the wire. > Yes, this can happen. The difference is that in the first case, there are > no duplicate Responses, but in the second case, there are (assuming that 2 > and 3 are retransmissions of 1). I think duplicate responses are indistinguishable from any other sort of unwanted responses. They don't match the current ID. They're junk. > > I disagree that these sorts of details are necessarily appropriate for > > a document that describes a protocol, except perhaps as asides. > > That seems sensible, but what if you have a situation like this: > > > Authenticator Authenticatee > Real Request: ID 22 -------> > > Attacker: > Bogus Request: ID 22 ---------> > > Assume that both the bogus and real request have valid CRCs, but that the > bogus request fails a MIC check and the real request passes. It depends, I think, on how the MIC is defined to operate. Since EAP doesn't have a MIC on its own, I don't see how that's really an EAP issue. If the goal is to specify how all possible future MICs should work with EAP, then I'd be inclined go with the 'silent discard' behavior (despite what EAP TLS may say) since anything else will open fairly obvious DoS vulnerabilities. > How does the Authenticatee behave? Some possibilities: > > a. The Real Request is processed, and elicits a Response. The > Authenticatee then sees a Bogus Request with the same ID, and resends the > Response, even though the Bogus Request is different. > > b. The Real Request is processed, and elicits a Response. The > Authenticatee then sees a Bogus Request with the same ID, and processes > the Request, which fails the MIC check. The Authenticatee then either > silently discards (if the method defines that) or aborts (EAP TLS). c. The Real Request is processed and elicits a Response. The Bogus Request fails the MIC and is silently ignored. No change in any authenticatee state is made. No additional Response is generated. It didn't happen. > > Since RFC 2284's usage of ID numbers provides a duplicate-free > > messaging mechanism > > Does it? It seems like it just provides for reliable delivery of *at least > one* copy of the message. The question is exactly how duplicates are > processed, and RFC 2284 doesn't seem clear on how that occurs. Perhaps that's the bit that needs to be made clear. For canonical EAP processing, once you receive a message with a given ID number, you're done with that ID. Move on. Allocate a new ID for new messages. Any duplicates still in flight that may arrive must be dumped on the floor. (But see below.) > > implementation isn't flawed, how can a peer tell whether EAP itself > > handled the duplicate or the EAP plug-in method did the job? > > I don't think it can tell -- but the question is what the expected > behavior is, and whether a method will behave the same way if hosted on > every EAP implementation or not. That's still an internal software design issue, and I'd really rather see such issues handled in forums that are equipped to handle them in an architecture-dependent way. For UNIX systems, that would probably be The Open Group. For MS systems, I have no clue, and I'd prefer to keep it that way. ;-} > If the method needs to be able to > handle duplicates, then that would be something that would be specified > in its design. If the definition of the method itself specifies special handling of duplicates as part of the protocol, I think that's really pretty awful and I'd argue against such a draft if I saw it, but I see no specific reason to document it one way or the other in the base EAP specification. The requirement would still essentially be an internal software design issue ("how do I access dups when I need to?"), not something that's visible on the wire. (Unless there's a wire I don't know about between 'EAP itself' and 'the method' ...) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From jrv@umich.edu Thu Jan 2 22:31:57 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 02 Jan 2003 17:31:57 -0500 Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: <15892.33662.607295.699193@gargle.gargle.HOWL> References: <15892.33662.607295.699193@gargle.gargle.HOWL> Message-ID: <30141971.1041528716@johnv-home> --On Thursday, January 02, 2003 1:22 PM -0500 James Carlson wrote: > Bernard Aboba writes: > > > this conversation on the wire can tell if the duplicates were > > > eliminated within EAP or within the method? If the answer is "no," > > > then there's no protocol issue here. > > > > The definition of the EAP layer transport service impacts on-the-wire > > behavior, as well as security. > I agree with James Carlson's point here. I think the on the wire protocol is not affected by how the flushing is done. This implies that the exact method for dealing with it should not be specified in the protocol. On the other hand, there does seem to be a potential for DOS attacks, especially in 802.11 application, so the method of flushing can be important if equipment is to interwork well. This implies to me that this could be a subject for an 802.11 recommended practices document. I am curious to know if the retransmission method as originally described has been found to be problem for TLS - does anyone have any insight into that? John From jrv@umich.edu Thu Jan 2 22:48:56 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 02 Jan 2003 17:48:56 -0500 Subject: [eap] Re: Issue 54: Problem with NAK type In-Reply-To: References: Message-ID: <31161688.1041529735@johnv-home> It has been a long time and my recollection may be faulty - but I think the intent was to allow the NAK to have zero or one alternatives. The wording is certainly up for grabs, and I think the proposed change would be good, and would make it clearer to implementers. --On Thursday, January 02, 2003 9:56 AM -0800 Bernard Aboba wrote: > Here is the text from RFC 2284 that might support the conclusion that the > NAK Type might contain no alternatives: > > Section 2.2.1: > > When sending a Nak in response to a > Request, the peer MAY indicate an alternative desired > authentication Type which it supports. > > On the other hand, section 3.3 says: > > This field MUST contain a single octet indicating the desired > authentication type. > > John V. or Larry Blunk -- can you clarify the intent here? > > ------------------------------------------------------------ > Issue 54: Problem with NAK type > Submitter name: James Carlson > Submitter email address: james.d.carlson@sun.com. > Date first submitted: January 2, 2003 > Document: RFC2284bis > Comment type: T > Priority: 1 > Section: 5.3 > Rationale/Explanation of issue: > > This also breaks RFC 2284 compatibility. In the original RFC, the > type field was *required*. Systems implemented to RFC 2284 will > *discard* bogus Nak messages that don't have a suggested type field. > Instead, if "Nak with no alternative" is required (I don't think it > is), then I suggest either a reserved value (e.g., 0) or (better yet) > using the value 1 (Identity) to tell the peer to start over. > > Requested change: > > from: > > The Nak Type is valid only in Response messages. It is sent in reply > to a method proposal (the initial EAP Request for a given Type) where > the desired authentication Type is unacceptable. Authentication Types > are numbered 4 and above. The Response contains zero or one > authentication Type desired by the Peer. A Nak with no authentication > Type indicates that the Peer does not wish to authenticate using the > proposed method but is not proposing an alternative. > > to: > The Nak Type is valid only in Response messages. It is sent in reply > to a method proposal (the initial EAP Request for a given Type) where > the desired authentication Type is unacceptable. Authentication Types > are numbered 4 and above. The Response contains a single octet > authentication Type desired by the Peer. This value may be 1 > (Identity) to indicate that the sender has no viable alternatives, > or that the authentication attempt should be restarted. > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Thu Jan 2 23:08:35 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 2 Jan 2003 15:08:35 -0800 (PST) Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: <15892.48036.436050.22296@gargle.gargle.HOWL> Message-ID: > I think duplicate responses are indistinguishable from any other sort > of unwanted responses. They don't match the current ID. They're > junk. Is this always true? Once a Peer has sent a Response, until it receives a new Request, the current ID is the same. So a retransmission will match the current ID, no? Similarly, when an Authenticator receives a Response, but has not yet sent a Request, the current ID is the same. So if a duplicate Response arrives, it will match the current ID, no? > If the goal is to specify how all possible future MICs should work > with EAP, then I'd be inclined go with the 'silent discard' behavior > (despite what EAP TLS may say) since anything else will open fairly > obvious DoS vulnerabilities. I agree. The question is whether the correctly MIC'd frame would even be delivered to the EAP method or not. > c. The Real Request is processed and elicits a Response. The Bogus > Request fails the MIC and is silently ignored. No change in any > authenticatee state is made. No additional Response is generated. > It didn't happen. RFC 2284 Section 2.2.1 says: "Additionally, the peer must be prepared to silently discard received retransmissions while waiting for user input." I am assuming here that the Real Request was processed and elicited a Response *before* the bogus Request was received. If the bogus Request came in before the Response was sent, it will be silently discarded without even a MIC check, right? What if the bogus packet arrived first? The MIC check fails, so no Response is sent. Is this "waiting for user input" so that the real packet is discarded too? Or is it as though the Request never arrived, so that the real packet is processed, and elicits a Response? > Perhaps that's the bit that needs to be made clear. For canonical EAP > processing, once you receive a message with a given ID number, you're > done with that ID. Move on. Allocate a new ID for new messages. Any > duplicates still in flight that may arrive must be dumped on the > floor. (But see below.) But Responses can be lost, which means that a Peer needs to respond to retransmitted Requests, even if it has already seen a Request with that ID. And as you noted, Requests (and Responses) can fail validation, in which case it is like they never happened (silent discard). From james.d.carlson@east.sun.com Fri Jan 3 14:21:16 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Fri, 3 Jan 2003 09:21:16 -0500 Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: Bernard Aboba's message of 2 January 2003 15:08:35 References: <15892.48036.436050.22296@gargle.gargle.HOWL> Message-ID: <15893.40028.548743.553290@gargle.gargle.HOWL> Bernard Aboba writes: > > I think duplicate responses are indistinguishable from any other sort > > of unwanted responses. They don't match the current ID. They're > > junk. > > Is this always true? Once a Peer has sent a Response, until it receives a > new Request, the current ID is the same. So a retransmission will match > the current ID, no? On the authenticatee, yes. That's how received *Requests* are handled. I was talking about duplicate *Responses* above. Once an implementation has sent a Request and until it finally receives a Response for that Request, the current ID is the same. Once the first (of any number) of Response messages has been received, the transaction is done. The current ID is no longer valid. Any additional Response copies that arrive are garbage to be discarded -- just as would be any Response messages that bear any invalid ID number. This is just standard programming practice, and isn't called out specifically in the RFC. However, there is this text: 2.2.1. Request and Response Description The Request packet is sent by the authenticator to the peer. Each Request has a type field which serves to indicate what is being requested. The authenticator MUST transmit an EAP packet with the Code field set to 1 (Request). Additional Request packets MUST be sent until a valid Response packet is received, or an optional ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ retry counter expires. Retransmitted Requests MUST be sent with [...] Thus, by implication, once the valid Response packet is received, you're done. You don't need to send Request messages anymore -- you've got the answer you wanted -- and you don't need to do anything special with any duplicate Response messages that come in. Here's a useful thought experiment. The case that you seem to be concerned about looks like this in action: Authenticator Authenticatee Request #1 >-- \ (timeout) \ Request #1 >-- -----> Send Response #1 \ --< \ / -/---> Send Response #1 (dup) Got rep #1 <----- --< / / Got dup! <----- The "Send Response #1 (dup)" part isn't a problem -- the authenticatee can detect this easily (Request ID matches ID for last received Request) and can send the last Response. The "Got dup!" part on the authenticator side is the only remaining question, and it's the one I was addressing in my last message. Suppose, instead, that the EAP implementation does what comes naturally when that first reply comes in -- it generates a new request. In that case, the sequence looks like this: Authenticator Authenticatee Request #1 >-- \ (timeout) \ Request #1 >-- -----> Send Response #1 \ --< \ / -/---> Send Response #1 (dup) Got rep #1 <----- --< Request #2 >-- / \ / (not #2) <---\- (drop) -----> Send Response #2 In this case, the duplicate is dropped because the ID number is clearly wrong. Note that both peers keep track of *only* the most recent ID value in use. The fact that #1 was once somehow valid in the past is of absolutely no consequence once the authenticator sends Request #2. #1 is now junk, just as would be #5 or #240. Since this is the 'normal' case -- the EAP authenticator progress is basically clocked by the valid Response messages it receives -- it makes a great deal of design sense to make sure that there are no "special" cases. That is to say, if the authenticator (for any reason) has nothing more to say after a Response comes in, then it should make sure that any additional Response copies of that same ID are discarded as they would be ordinarily. Doing otherwise creates a strange corner case that need not exist and adds no benefit. How you choose to do this in implementation is your business. One way to do it would be to increment the ID number variable when you receive a valid Response to an outstanding Request, rather than when an "initial" Request is generated. Another way would be to set a "waiting for Response" flag when sending Request, and clearing that flag when a valid Response is seen. If a Response is received when the flag isn't set, then that Response is discarded without looking further. Not surprisingly (given EAP's pedigree), this is the same logic as employed by RFC 1661 PPP. The Configure-Request (section 5.1) description has this somewhat clearer description of how to set an identifier: Identifier The Identifier field MUST be changed whenever the contents of the Options field changes, and whenever a valid reply has been received for a previous request. For retransmissions, the Identifier MAY remain unchanged. > Similarly, when an Authenticator receives a Response, but has not yet sent > a Request, the current ID is the same. So if a duplicate Response arrives, > it will match the current ID, no? No. There is no current ID at that point. > > If the goal is to specify how all possible future MICs should work > > with EAP, then I'd be inclined go with the 'silent discard' behavior > > (despite what EAP TLS may say) since anything else will open fairly > > obvious DoS vulnerabilities. > > I agree. The question is whether the correctly MIC'd frame would even be > delivered to the EAP method or not. If it doesn't have an Identifier value equal to that assigned to the most recent *outstanding* Request, then it should be dropped silently. > > c. The Real Request is processed and elicits a Response. The Bogus > > Request fails the MIC and is silently ignored. No change in any > > authenticatee state is made. No additional Response is generated. > > It didn't happen. > > RFC 2284 Section 2.2.1 says: > > "Additionally, the peer must be prepared to > silently discard received retransmissions while waiting for > user input." Right. Note that this is on the authenticatee side -- it's talking about dropping duplicate Requests that are received before you're able generate a valid Response for the first of those Requests that you saw. In other words, when the first Request comes in with a particular novel ID number, you pop up a little dialog box asking the user for his password (or whatever). If you get a duplicate Request for that ID number before the human finishes typing, there's no way you could possibly respond -- you don't know what he's going to type. You have to continue to wait. This section says that you "wait" by dropping those duplicate Request messages. > I am assuming here that the Real Request was processed and elicited a > Response *before* the bogus Request was received. If the bogus Request > came in before the Response was sent, it will be silently discarded > without even a MIC check, right? That sounds like an implementation optimization. Since the MIC is likely to be computationally expensive, checking simple things (like sequence numbers) first would be an obvious bit of goodness. I don't think it affects correctness, though. > What if the bogus packet arrived first? The MIC check fails, so no > Response is sent. Is this "waiting for user input" so that the real packet > is discarded too? No. No Request has been received. It's the same *as if* the bogus Request message had a bad CRC, or was malformed in any of a half dozen other ways. Bad messages are discarded. > Or is it as though the Request never arrived, so that > the real packet is processed, and elicits a Response? Right. > > Perhaps that's the bit that needs to be made clear. For canonical EAP > > processing, once you receive a message with a given ID number, you're > > done with that ID. Move on. Allocate a new ID for new messages. Any > > duplicates still in flight that may arrive must be dumped on the > > floor. (But see below.) > > But Responses can be lost, which means that a Peer needs to respond to > retransmitted Requests, even if it has already seen a Request with that > ID. That's correct on the *authenticatee* side. The implementation issue for the authenticatee is that you need to keep a copy of the last Response you sent in case the peer times out and asks again. On the authenticator side, which is the side that's doing the ID checking and generation I'm referring to above, that's not true. All the authenticator ever does is send the same Request over and over until it sees a Response that it wants. The Request can be lost, or the Response can be lost -- neither matters. All that matters is that a matching Response eventually arrives. I think the confusion here might over the distinction in roles between the authenticator and authenticatee. The roles are different but complementary. The authenticator is completely uninterested in duplicates. Duplicates have nothing to do with the way the authenticator works. It merely sends (and resends) the same Request until it gets a matching Response. When the matching Response comes in, it moves on to a new Request. The authenticatee is interested only in detecting retransmitted Requests. If the Request ID number received is equal to the last one received, then one of two things happens: - The prior Response is resent. - There's no prior Response (the processing of the Request isn't complete), so nothing is done. If it's not equal, then this is a new Request to handle. In effect, it cancels any prior Request seen. Whether an implementation actually terminates an outstanding Request (abruptly closing the dialog box, for instance) is a local implementation issue. > And as you noted, Requests (and Responses) can fail validation, in > which case it is like they never happened (silent discard). Right. The handling of such cases doesn't seem to me to be significantly different from handling packets with truncated data, bad CRCs, mangled framing bits, or other fatal errors. They're counted, logged, archived, but not acted upon. The logic (borrowed from PPP, and leaving out a ton of error handling) looks something like this. Note that it can be implemented as a state machine as well, but you have to be careful to handle the Identifier values properly. int current_request_id; /* initialize to pseudorandom%256 value */ int last_handled_request = -1; eap_packet_t *copy_of_last_request = NULL; eap_packet_t *copy_of_last_response = NULL; /* authenticatee side */ void handle_request(eap_packet_t *req_pkt) { int pktid = eap_get_id(req_pkt); /* extract id number */ /* handle a retransmit */ if (pktid == last_handled_request) { if (copy_of_last_response != NULL) send_response(eap_copy_packet(copy_of_last_response)); free_eap_packet(req_pkt); return; } if (copy_of_last_response != NULL) { free_eap_packet(copy_of_last_response); copy_of_last_response = NULL; } else { /* xxx if you have a way of canceling requests, do it here */ } last_handled_request = pktid; process_request(req_pkt, formulated_response_callback); } /* called when the request processing is done; pop-up box 'ok' clicked */ void formulated_response_callback(eap_packet_t *resp_pkt) { copy_of_last_response = eap_copy_packet(resp_pkt); eap_send_packet(resp_pkt); } /* authenticator side */ void handle_response(eap_packet_t *resp_pkt) { int pktid = eap_get_id(resp_pkt); if (pktid != current_request_id) { free_eap_packet(resp_pkt); return; } current_request_id++; /* * This can generate a new Request. If it does, then a timer * is set, and a copy is placed in copy_of_last_request. If * it doesn't (i.e., Success or Failure), then nothing else is * done. */ process_response(resp_pkt); } /* authenticator only */ void handle_request_timeout(void) { /* this timeout can't happen if we haven't sent a Request */ assert(copy_of_last_request != NULL); eap_send_packet(eap_copy_packet(copy_of_last_request)); } -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Fri Jan 3 14:41:57 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 3 Jan 2003 06:41:57 -0800 (PST) Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: <30141971.1041528716@johnv-home> Message-ID: > I agree with James Carlson's point here. I think the on the wire protocol > is not affected by how the flushing is done. This implies that the exact > method for dealing with it should not be specified in the protocol. RFC 2284 contains the following language in Section 2.2.1: "Additionally, the peer must be prepared to silently discard received retransmissions while waiting for user input." and "If a peer receives a duplicate Request before it has sent a Response to the initial Request (i.e. it's waiting for user input), it MUST silently discard the duplicate Request." How are these paragraphs to be interpretted? Does the MUST regarding silently discard apply only to methods that take user input? Or does it apply to EAP in general? Are you recommending that these paragraphs be removed? From james.d.carlson@east.sun.com Fri Jan 3 16:02:59 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Fri, 3 Jan 2003 11:02:59 -0500 Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: Bernard Aboba's message of 3 January 2003 06:41:57 References: <30141971.1041528716@johnv-home> Message-ID: <15893.46131.261441.87201@gargle.gargle.HOWL> Bernard Aboba writes: > > I agree with James Carlson's point here. I think the on the wire protocol > > is not affected by how the flushing is done. This implies that the exact > > method for dealing with it should not be specified in the protocol. > > RFC 2284 contains the following language in Section 2.2.1: > > "Additionally, the peer must be prepared to silently discard received > retransmissions while waiting for user input." Right. That's specifying how received duplicate Request messages are handled in the case where a Response has not yet been generated. > and > > "If a peer receives a duplicate Request > before it has sent a Response to the initial Request (i.e. it's > waiting for user input), it MUST silently discard the duplicate > Request." That says the same thing. > How are these paragraphs to be interpretted? Does the MUST regarding > silently discard apply only to methods that take user input? Or does it > apply to EAP in general? Are you recommending that these paragraphs be > removed? The problem is with asynchronous methods -- ones that invoke some non-EAP activity (e.g., a dialog box or database query) that will complete at a later time. If you do this, then there's a 'limbo' state on the authenticatee: already received a Request, but no Response yet generated. In this one case, duplicate Request messages are silently discarded because no Response can possibly be generated. Once the Response has been generated (which is immediate for a synchronous handler), duplicate Requests are processed as usual: a duplicate Response is sent. As an implementation issue, *if* you return to your dispatcher after handling a received Request but before you generate a Response, *then* you must discard duplicate received Requests until you do generate a Response. Even so, it should be noted that this is "just" an optimization. Everything works fine if the EAP authenticatee queues all input messages (i.e., blocks while calling that dialog box handler) and then handles them synchronously after generating the Response. You'll generate lots of duplicate Response messages, but the authenticator doesn't care: he uses only the first one he gets and drops the others. Another way to state that is that there's no way that an outside observer can tell if the authenticatee (a) replied to the Request, but the reply has been delayed for a long time in some transmit queue or (b) blocks internally and does all the processing synchronously. The two cases look the same from the outside. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Fri Jan 3 15:22:32 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 3 Jan 2003 07:22:32 -0800 (PST) Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: <15893.40028.548743.553290@gargle.gargle.HOWL> Message-ID: > handled. I was talking about duplicate *Responses* above. > > Once an implementation has sent a Request and until it finally > receives a Response for that Request, the current ID is the same. > Once the first (of any number) of Response messages has been received, > the transaction is done. The current ID is no longer valid. Any > additional Response copies that arrive are garbage to be discarded -- > just as would be any Response messages that bear any invalid ID > number. Yes, I agree -- and I hope that the language is clear enough. > sent until a valid Response packet is received, or an optional > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > retry counter expires. Retransmitted Requests MUST be sent with > [...] > > Thus, by implication, once the valid Response packet is received, > you're done. Yes, although I think that the word "valid" might require elaboration. For example, failure of a MIC check would render an EAP packet invalid. > you've got the answer you wanted -- and you don't need to do anything > special with any duplicate Response messages that come in. Yes. > The "Send Response #1 (dup)" part isn't a problem -- the authenticatee > can detect this easily (Request ID matches ID for last received > Request) and can send the last Response. The "Got dup!" part on the > authenticator side is the only remaining question, and it's the one I > was addressing in my last message. Actually, this isn't the part that bothers me. My concern relates to RFC 2284, Section 2.2.1: "If a peer recieves a duplicate Request for which it has already sent a Response, it MUST resend it's Response. If a peer receives a duplicate Request before it has sent a Response to the initial Request (i.e. it's waiting for user input), it MUST silently discard the duplicate Request." This is neither a reliable transport service, nor a datagram service, but a wierd mixture of the two. According to your model, the Identifier hasn't changed until the peer receives a new Request, so why does it silently discard? > are discarded as they would be ordinarily. Doing otherwise creates a > strange corner case that need not exist and adds no benefit. Agreed. > The Identifier field MUST be changed whenever the contents of the > Options field changes, and whenever a valid reply has been > received for a previous request. For retransmissions, the > Identifier MAY remain unchanged. Are you recommending that this language be used instead? I do think it is clearer. > No. There is no current ID at that point. OK. > If it doesn't have an Identifier value equal to that assigned to the > most recent *outstanding* Request, then it should be dropped silently. OK. > Right. Note that this is on the authenticatee side -- it's talking > about dropping duplicate Requests that are received before you're able > generate a valid Response for the first of those Requests that you > saw. In other words, when the first Request comes in with a > particular novel ID number, you pop up a little dialog box asking the > user for his password (or whatever). If you get a duplicate Request > for that ID number before the human finishes typing, there's no way > you could possibly respond -- you don't know what he's going to type. > You have to continue to wait. This section says that you "wait" by > dropping those duplicate Request messages. Does this apply only to EAP methods taking user input, or to all EAP methods? > > I am assuming here that the Real Request was processed and elicited a > > Response *before* the bogus Request was received. If the bogus Request > > came in before the Response was sent, it will be silently discarded > > without even a MIC check, right? > > That sounds like an implementation optimization. Since the MIC is > likely to be computationally expensive, checking simple things (like > sequence numbers) first would be an obvious bit of goodness. I don't > think it affects correctness, though. I'm trying to figure out what behavior RFC 2284 is trying to mandate. Can an implementation decide not to silently discard in this case (e.g. it's not waiting for user input)? > No. No Request has been received. It's the same *as if* the bogus > Request message had a bad CRC, or was malformed in any of a half dozen > other ways. Bad messages are discarded. I agree. I'm just puzzled by the language in Section 2.2.1. > That's correct on the *authenticatee* side. The implementation issue > for the authenticatee is that you need to keep a copy of the last > Response you sent in case the peer times out and asks again. Where does RFC 2284 say that a copy Response is sent? If only the ID portion of the Request is checked, then we don't necessarily know that it is the same Request, even if the ID is the same. So a different Response could conceivably be generated. I realize that this is a corner case, but we want to understand the behavior under DoS attack. > Response can be lost -- neither matters. All that matters is that a > matching Response eventually arrives. Yes. > The authenticator is completely uninterested in duplicates. > Duplicates have nothing to do with the way the authenticator works. > It merely sends (and resends) the same Request until it gets a > matching valid Response. When the matching Response comes in, it moves > on > The authenticatee is interested only in detecting retransmitted > Requests. If the Request ID number received is equal to the last one > received, then one of two things happens: > > - The prior Response is resent. > > - There's no prior Response (the processing of the Request > isn't complete), so nothing is done. This is the part that's not clear in RFC 2284. Does "nothing is done" always mean silent discard? Does an invalid Request imply that there's no prior Response? > If it's not equal, then this is a new Request to handle. In effect, > it cancels any prior Request seen. Even if it has not yet sent a Response? Wouldn't this increase the vulnerability to DoS attacks? > Right. The handling of such cases doesn't seem to me to be > significantly different from handling packets with truncated data, bad > CRCs, mangled framing bits, or other fatal errors. They're counted, > logged, archived, but not acted upon. Makes sense. I think more language is needed to clarify this, though. From aboba@internaut.com Fri Jan 3 15:30:11 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 3 Jan 2003 07:30:11 -0800 (PST) Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: <15893.46131.261441.87201@gargle.gargle.HOWL> Message-ID: > Even so, it should be noted that this is "just" an optimization. If so, then I would suggest that the MUST be lowered to a MAY, with a caution about the DoS implications. > Everything works fine if the EAP authenticatee queues all input > messages (i.e., blocks while calling that dialog box handler) and then > handles them synchronously after generating the Response. You'll > generate lots of duplicate Response messages, but the authenticator > doesn't care: he uses only the first one he gets and drops the others. I'd argue that the peer will have more work to do in event of a DoS attack, but if there is no silent discard, then it will eventually get to the valid Request that passes the MIC check, amongst the sea of invalid Requests. What I don't like is the idea of silently discarding a valid Request packet as a result of receiving (and not yet responding to) an invalid Request. As you've pointed out, this doesn't happen on the authenticator side, because the term "valid Response" is used. From james.d.carlson@east.sun.com Fri Jan 3 17:19:20 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Fri, 3 Jan 2003 12:19:20 -0500 Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: Bernard Aboba's message of 3 January 2003 07:22:32 References: <15893.46131.261441.87201@gargle.gargle.HOWL> <15893.40028.548743.553290@gargle.gargle.HOWL> Message-ID: <15893.50712.564493.863610@gargle.gargle.HOWL> Bernard Aboba writes: > > The "Send Response #1 (dup)" part isn't a problem -- the authenticatee > > can detect this easily (Request ID matches ID for last received > > Request) and can send the last Response. The "Got dup!" part on the > > authenticator side is the only remaining question, and it's the one I > > was addressing in my last message. > > Actually, this isn't the part that bothers me. My concern relates to RFC > 2284, Section 2.2.1: > > "If a peer recieves a > duplicate Request for which it has already sent a Response, it > MUST resend it's Response. If a peer receives a duplicate Request > before it has sent a Response to the initial Request (i.e. it's > waiting for user input), it MUST silently discard the duplicate > Request." > > This is neither a reliable transport service, nor a datagram service, but > a wierd mixture of the two. I disagree. It's reliable, in-order, and unduplicated. It uses retransmissions to recover from errors, and it eliminates duplicates by use of a unique identifier. The fact that it's a simplex protocol means that it's pretty crude as a transport, but it's just fine for low-volume authentication data. > According to your model, the Identifier hasn't > changed until the peer receives a new Request, so why does it silently > discard? Because there's no plausible Response that it could possibly send. You've received Request ID number 1. You're working on a Response for that Request, but you don't have that Response ready yet. You get another Request ID number 1 in. What do you do? You can't "resend" the Response you don't have. So, you do *nothing*. That's the point. This language is there to alleviate the "but what if I can't resend?" concern. > > The Identifier field MUST be changed whenever the contents of the > > Options field changes, and whenever a valid reply has been > > received for a previous request. For retransmissions, the > > Identifier MAY remain unchanged. > > Are you recommending that this language be used instead? I do think it is > clearer. I do think that the language could be made clearer, but copying that language directly from PPP might not be the right answer because EAP has tighter constraints on the authenticator -- it requires the creator of IDs to reuse ID numbers on retransmission. (s/MAY/MUST/) It's a fair reference, though, because the same ideas are used. > > Right. Note that this is on the authenticatee side -- it's talking > > about dropping duplicate Requests that are received before you're able > > generate a valid Response for the first of those Requests that you > > saw. In other words, when the first Request comes in with a > > particular novel ID number, you pop up a little dialog box asking the > > user for his password (or whatever). If you get a duplicate Request > > for that ID number before the human finishes typing, there's no way > > you could possibly respond -- you don't know what he's going to type. > > You have to continue to wait. This section says that you "wait" by > > dropping those duplicate Request messages. > > Does this apply only to EAP methods taking user input, or to all EAP > methods? Any asynchronous method where EAP remains free to process future messages while a Response is being formulated. "User input" is one of those. A connection to some external database or client-side authentication service *might* be another, if the implementation is really sophisticated. > > That sounds like an implementation optimization. Since the MIC is > > likely to be computationally expensive, checking simple things (like > > sequence numbers) first would be an obvious bit of goodness. I don't > > think it affects correctness, though. > > I'm trying to figure out what behavior RFC 2284 is trying to mandate. Can > an implementation decide not to silently discard in this case (e.g. it's > not waiting for user input)? Certainly; it can queue all received messages following the Request and handle them after the one currently being dispatched is complete. Such behavior isn't distinguishable from a transmission delay. It might be suboptimal, but it can't be called "wrong" from the EAP protocol point of view. > > No. No Request has been received. It's the same *as if* the bogus > > Request message had a bad CRC, or was malformed in any of a half dozen > > other ways. Bad messages are discarded. > > I agree. I'm just puzzled by the language in Section 2.2.1. If you treat it as a bad message, you never get to the point of thinking about retransmitting a reply per 2.2.1. You wouldn't process a frame with a CRC error and then try to generate a reply based on that; similarly, if something fails MIC, there's no reason to try to generate any reply there. > > That's correct on the *authenticatee* side. The implementation issue > > for the authenticatee is that you need to keep a copy of the last > > Response you sent in case the peer times out and asks again. > > Where does RFC 2284 say that a copy Response is sent? If only the ID > portion of the Request is checked, then we don't necessarily know that it > is the same Request, even if the ID is the same. A really conservative authenticatee implementation would indeed check that the Response is *competely* identical in all respects. I agree with that. If it gets the same ID but the rest is different, then the peer is an idiot -- he's sent a 'retransmission' that isn't really a retransmission. Personally, I'd either discard the packet (and log it), or drop the connection cold. There's no use in talking to implementations that are this seriously flawed, and any implementation that could get this wrong likely has other (possibly even more serious) problems. In 2.2.1: [...] Any new (non-retransmission) Requests MUST modify the Identifier field. [...] There's no option to change the contents of the Request but use the same Identifier. > So a different Response > could conceivably be generated. No. > I realize that this is a corner case, but > we want to understand the behavior under DoS attack. [...] If a peer recieves a duplicate Request for which it has already sent a Response, it MUST resend it's Response. [...] Just resend the Response. > > The authenticatee is interested only in detecting retransmitted > > Requests. If the Request ID number received is equal to the last one > > received, then one of two things happens: > > > > - The prior Response is resent. > > > > - There's no prior Response (the processing of the Request > > isn't complete), so nothing is done. > > This is the part that's not clear in RFC 2284. Does "nothing is done" > always mean silent discard? The two are equivalent for the protocol. > Does an invalid Request imply that there's no > prior Response? I assume we're still talking about MICs here. An invalid packet means there's no point in processing it in any way. I would say that an "invalid Request" isn't even a Request. It's nothing but noise. > > If it's not equal, then this is a new Request to handle. In effect, > > it cancels any prior Request seen. > > Even if it has not yet sent a Response? Per 2284, yes. There's no requirement in there that an authenticator stick with the same Request forever. > Wouldn't this increase the > vulnerability to DoS attacks? Not exactly. You can do anything you like inside both peers. If, based on the environment you deploy into, you think it's likely that you'll be DoS'd by a bad authenticator, then the right thing to do might be to count the number of received unique EAP Request messages and forcibly shut the link down if the number is "too high." I think that's a quality-of-implementation issue. Bernard Aboba writes: > > Even so, it should be noted that this is "just" an optimization. > > If so, then I would suggest that the MUST be lowered to a MAY, with a > caution about the DoS implications. I think the fear is that someone might be tempted to send a completely bogus Response instead. It should say something like: If the receiving implementation has the capability of continuing to process newly-received EAP messages while a Request message is still being processed (and a corresponding Response has not yet been generated), then that implementation MUST silently discard any duplicate Request messages that it receives in the interval before the corresponding Response is generated. ... or some such. > > Everything works fine if the EAP authenticatee queues all input > > messages (i.e., blocks while calling that dialog box handler) and then > > handles them synchronously after generating the Response. You'll > > generate lots of duplicate Response messages, but the authenticator > > doesn't care: he uses only the first one he gets and drops the others. > > I'd argue that the peer will have more work to do in event of a DoS > attack, but if there is no silent discard, then it will > eventually get to the valid Request that passes the MIC check, amongst the > sea of invalid Requests. It's not clear to me whether there's any significantly greater amount of work to do, or if this is even near the weak point in the protocol. The additional work that it would have to do would be to check one byte (the Identifier) in a sea of messages that a "bad" peer could generate from whole cloth anyway. I don't think any of this is necessarily important from a DoS point of view. DoS concerns in security protocols usually revolve around the operations that invoke a "hard to do" function, such as computing MD5. Duplicate Requests don't do that. Having an authenticator that sends a flood of MD5-Challenge Request messages, each with a unique Identifier value, is much more credible threat, and EAP has no inherent protection against it. > What I don't like is the idea of silently discarding a > valid Request packet as a result of receiving (and not yet responding to) an > invalid Request. As you've pointed out, this doesn't happen on the > authenticator side, because the term "valid Response" is used. If you have some way to tell what a "valid" Request looks like -- such as a MIC or CRC or nonce -- then you can do what you suggest. Otherwise, you can't, and you need to return to first principles: if the peer is acting broken, then stop talking to it. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Fri Jan 3 16:44:42 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 3 Jan 2003 08:44:42 -0800 (PST) Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: <15893.50712.564493.863610@gargle.gargle.HOWL> Message-ID: > > > The Identifier field MUST be changed whenever the contents of the > > > Options field changes, and whenever a valid reply has been > > > received for a previous request. For retransmissions, the > > > Identifier MAY remain unchanged. > > > > Are you recommending that this language be used instead? I do think it is > > clearer. > > I do think that the language could be made clearer, but copying that > language directly from PPP might not be the right answer because EAP > has tighter constraints on the authenticator -- it requires the > creator of IDs to reuse ID numbers on retransmission. (s/MAY/MUST/) > > It's a fair reference, though, because the same ideas are used. How about: "The Identifier field MUST be changed whenever the contents of the Type-Data field changes, and whenever a valid Response has been received for a previous Request." > > I'm trying to figure out what behavior RFC 2284 is trying to mandate. Can > > an implementation decide not to silently discard in this case (e.g. it's > > not waiting for user input)? > > Certainly; it can queue all received messages following the Request > and handle them after the one currently being dispatched is complete. > Such behavior isn't distinguishable from a transmission delay. It > might be suboptimal, but it can't be called "wrong" from the EAP > protocol point of view. Right. > No. No Request has been received. It's the same *as if* the bogus > Request message had a bad CRC, or was malformed in any of a half dozen > other ways. Bad messages are discarded. > If you treat it as a bad message, you never get to the point of > thinking about retransmitting a reply per 2.2.1. Yes, but the invalid message does result in silent discard of potentially valid messages. > A really conservative authenticatee implementation would indeed check > that the Response is *completely* identical in all respects. I agree > with that. I don't think this distinction is material if the initial Request is a valid one. If it is invalid, it needs to be silently discarded, and state left as though it never arrived. > If it gets the same ID but the rest is different, then the > peer is an idiot -- he's sent a 'retransmission' that isn't really a > retransmission. Personally, I'd either discard the packet (and log > it), or drop the connection cold. There's no use in talking to > implementations that are this seriously flawed, and any implementation > that could get this wrong likely has other (possibly even more > serious) problems. This seems reasonable on physically secure media like PPP. However, on 802.11, an attacker only need be in range to have access to the media. So aborting the conversation on receiving invalid packets makes it easy for an attacker to abort the session. > [...] If a peer recieves a > duplicate Request for which it has already sent a Response, it > MUST resend it's Response. [...] > > Just resend the Response. Yes. > I assume we're still talking about MICs here. An invalid packet means > there's no point in processing it in any way. I would say that an > "invalid Request" isn't even a Request. It's nothing but noise. OK. How about this? "If a peer receives a duplicate Request before it has sent a Response to a valid initial Request (i.e. it's waiting for user input), it MUST silently discard the duplicate Request." That way, silent discard isn't mandated if the initial Request is determined to be invalid. From james.d.carlson@east.sun.com Fri Jan 3 18:21:45 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Fri, 3 Jan 2003 13:21:45 -0500 Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: Bernard Aboba's message of 3 January 2003 08:44:42 References: <15893.50712.564493.863610@gargle.gargle.HOWL> Message-ID: <15893.54458.105453.537817@gargle.gargle.HOWL> Bernard Aboba writes: > > I do think that the language could be made clearer, but copying that > > language directly from PPP might not be the right answer because EAP > > has tighter constraints on the authenticator -- it requires the > > creator of IDs to reuse ID numbers on retransmission. (s/MAY/MUST/) > > > > It's a fair reference, though, because the same ideas are used. > > How about: > > "The Identifier field MUST be changed whenever the contents of the > Type-Data field changes, and whenever a valid Response has been received > for a previous Request." That's good, and roughly equivalent to what was in RFC 2284. > > No. No Request has been received. It's the same *as if* the bogus > > Request message had a bad CRC, or was malformed in any of a half dozen > > other ways. Bad messages are discarded. > > > If you treat it as a bad message, you never get to the point of > > thinking about retransmitting a reply per 2.2.1. > > Yes, but the invalid message does result in silent discard of potentially > valid messages. How so? If you receive and process an invalid message, then shame on you. Sure, you'll end up discarding later valid messages. You might also cause all sorts of other problems. If you receive an invalid message and discard it, then I don't see how that discarded message can hurt you. Can you elaborate on that? > > A really conservative authenticatee implementation would indeed check > > that the Response is *completely* identical in all respects. I agree > > with that. > > I don't think this distinction is material if the initial Request is a > valid one. If it is invalid, it needs to be silently discarded, and state > left as though it never arrived. Right. Except that I would argue that Requests are not peculiar in this regard: all invalid packets of whatever nature need to be silently discarded. (Where "silently discared" also implies that the state is unaltered.) If we don't process packets with CRC errors, we ought not be processing packets that have other errors. > > If it gets the same ID but the rest is different, then the > > peer is an idiot -- he's sent a 'retransmission' that isn't really a > > retransmission. Personally, I'd either discard the packet (and log > > it), or drop the connection cold. There's no use in talking to > > implementations that are this seriously flawed, and any implementation > > that could get this wrong likely has other (possibly even more > > serious) problems. > > This seems reasonable on physically secure media like PPP. However, on > 802.11, an attacker only need be in range to have access to the media. So > aborting the conversation on receiving invalid packets makes it easy for > an attacker to abort the session. There's a subtle difference here: if the packet is something that only the peer could have generated, but the contents represent foolishness, such as a Request that passes MIC (or comes from a physically secure wire) and has a duplicate Identifier, but has altered contents, then the peer must be an idiot. Dropping him like a bad habit is a prudent response to protect the rest of the network. Only a human can defenestrate the offending equipment. If the packet could come from any source, including an attacker or just plain old noise, then you do need to discard without paying attention to the contents. Which one is true depends strongly on the deployment considerations -- as you're describing with 802.11. It's not just 802.11, though. Suppose that someone (in the future) replaced WEP with something that was cryptographically secure enough to rule out tampering. In that case, you'd want to be stricter about the sorts of things you're willing to tolerate out of a good peer. For another case, consider just CRCs. We would ordinarily say that packets with CRC errors are discarded silently, and no processing at all is performed, and that we don't treat these as problems with the peer, right? Consider a link where the CRC error rate is so high that only one in 10 packets makes it through. Such a link is probably completely unusable. EAP will eventually establish an authentication through patience. Is that a good thing? Certainly not if your point of view is centered on the health of the network -- a bad link forms a black hole in the network that will harm everyone else's performance (assuming it looks like an attractive route for some traffic -- if it's not, then why'd you even try to bring up the link?). This case would be similar in implementation. If the link is awful, either because of peer bugs or link errors or frequent attacks, you *might* be better off in some cases without that link. > > I assume we're still talking about MICs here. An invalid packet means > > there's no point in processing it in any way. I would say that an > > "invalid Request" isn't even a Request. It's nothing but noise. > > OK. How about this? > > "If a peer receives a duplicate Request > before it has sent a Response to a valid initial Request (i.e. > it's waiting for user input), it MUST silently discard the duplicate > Request." > > That way, silent discard isn't mandated if the initial Request is > determined to be invalid. I don't think that quite captures the idea. If MIC must be addressed at all, then I'd recommend a separate paragraph somewhere to handle it: If some sort of message integrity checking is employed, then implementations are REQUIRED to discard any message that fails this check silently. The types of checking that might be employed depend on the underlying communications medium and the threat model for the deployment. In all cases, the foregoing descriptions of EAP message handling assume that validation is effectively performed as though it occurs before examining any of the EAP message fields (such as 'Code'). I still don't think that this is necessary. Discarding errors is just plain good engineering sense. There's no way to predict what the message "might" have said if it didn't have an error, so there's no sensible way to act on an invalid message of any sort. I don't think that normal implementation practice needs to be described here. Further, someone skilled in the art should be able to tell that all that is necessary is that all checking is done "as if" performed logically before any state is changed. An implementation that parses individual bits as they stream off of the wire could (at least in theory) perform all of the EAP dispatching on each bit as it arrives using a copy of the current state. When the final bit of the message is clocked in, the resulting CRC (and other check bits) are verified, and if they're right, then the new EAP state is committed. Otherwise, it reverts to the old state. I don't think such optimizations (even where possible) need to be in the base document. A document that talks about implementing a particular MIC with EAP *might* need to discuss how best to optimize the order of operations to validate an incoming message ("first check the Identifier and discard if incorrect, else run MIC and discard if failed, else dispatch based on Code"), but I don't think that's relevant here. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Fri Jan 3 18:50:35 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 3 Jan 2003 10:50:35 -0800 (PST) Subject: [eap] Strawman rewrite of Section 4.1 Message-ID: Based on the recent discussion on EAP transport behavior, I'd like to propose the following text to replace the existing Section 4.1 Request and Response. Comments welcome (please indicate substitute text if you don't like something). 4.1. Request and Response Description The Request packet is sent by the authenticator to the peer. Each Request has a type field which serves to indicate what is being requested. The authenticator MUST transmit an EAP packet with the Code field set to 1 (Request). Additional Request packets MUST be sent until a valid Response packet is received, or an optional retry counter expires. In [IEEE8021X], the retry counter is effectively set to zero, so that retransmission never occurs, and instead the peer times out and authentication is restarted. Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests. The contents of the data field is dependent on the Request type. The peer MUST send a Response packet in reply to a Request packet. Responses MUST only be sent in reply to a received Request and never retransmitted on a timer. The Identifier field of the Response MUST match that of the Request; if it does not match, then the Response MUST be silently discarded. Authenticators receiving an EAP Response with a Type for which the authenticator has no outstanding Request MUST silently discard the Response. The authenticator MUST NOT send a new Request until a valid Response is received to an outstanding Request. Since the authenticator can retransmit before receiving a valid Response from the peer, the authenticator can receive duplicate Responses. The authenticator MUST silently discard these duplicate Responses. Implementation Note: Because the authentication process will often involve user input, some care must be taken when deciding upon retransmission strategies and authentication timeouts. By default, where EAP is run over an unreliable lower layer, the EAP retransmission timer (EAP_RTO) SHOULD be computed as described in [RFC2988]. This includes use of Karn's algorithm to filter RTT estimates resulting from retransmissions. A maximum of 3-5 retransmissions is suggested. When run over a reliable lower layer (e.g. EAP over ISAKMP/TCP, as within [PIC]), the EAP retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. Where the authentication process requires user input, the measured round trip times are largely be determined by user responsiveness rather than network characteristics, so that RTO estimation is not helpful. Instead, the retransmission timers SHOULD be set so as to provide sufficient time for the user to respond, with longer timeouts required in certain cases, such as where Token Cards are involved. In order to provide the EAP authenticator with guidance as to the appropriate timeout value, a hint can be communicated to the authenticator by the backend authentication server (such as via the RADIUS Session-Timeout attribute). A summary of the Request and Response packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Type-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Code 1 for Request 2 for Response Identifier The Identifier field is one octet. The Identifier field MUST be the same if a Request packet is retransmitted due to a timeout while waiting for a Response. Any new (non-retransmission) Requests MUST modify the Identifier field. In order to avoid confusion between new Requests and retransmissions, the Identifier value chosen for each new Request MUST be unique within the EAP conversation. One way to achieve this is to start the Identifier at an initial value and increment it for each new Request. The Identifier field need only be unique on a per-port basis, so that authenticators are not restricted to only 255 simultaneous authentication conversations. If a peer receives a valid duplicate Request for which it has already sent a Response, it MUST resend its original Response. If a peer receives a duplicate Request before it has sent a Response to a valid initial Request (i.e. it's waiting for user input), it MUST silently discard the duplicate Request. An EAP message may be found invalid for a variety of reasons: failed link layer CRC or checksum, malformed EAP packet, EAP method-specific MIC, etc. Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Type-Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. Type The Type field is one octet. This field indicates the Type of Request or Response. A single Type MUST be specified for each EAP Request or Response. Normally, the Type field of the Response will be the same as the Type of the Request. However, there is also a Nak Response Type for indicating that a Request type is unacceptable to the peer. An initial specification of Types follows in a later section of this document. Type-Data The Type-Data field varies with the Type of Request and the associated Response. From aboba@internaut.com Fri Jan 3 18:53:27 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 3 Jan 2003 10:53:27 -0800 (PST) Subject: [eap] Proposed strawman Section 3: Link Layer behavior Message-ID: I'd like to propose the following revision of Section 3 on Link Layer behavior. Comments welcome (please indicate substitute text if something is unsatisfactory). 3. Lower layer behavior 3.1. Lower layer requirements EAP makes the following assumptions about lower layers: [1] Link layer CRC or checksum. In EAP, the authenticator retransmits Requests that have not yet received Responses, so that EAP does not assume that lower layers are reliable. Since EAP defines its own retransmission behavior, when run over a reliable lower layer, it is possible (though undesirable) for retransmission to occur both in the lower layer and the EAP layer. If lower layers exhibit a high loss rate, then retransmissions are likely, and since EAP Success and Failure are not retransmitted, timeouts are also likely to result. EAP methods such as EAP TLS [RFC2716] include a message integrity check (MIC) and regard MIC errors as fatal. Therefore if a checksum or CRC is not provided by the link layer, then some methods may not behave well. [2] Known MTU. The EAP layer does not support fragmentation and reassembly. However, individual EAP methods SHOULD NOT make assumptions about the minimum MTU size and SHOULD be capable of handling fragmentation and reassembly. As a result, EAP is capable of functioning across a range of MTU sizes, as long as the MTU is known. [3] Possible duplication. Where the lower layer is reliable, it will provide the EAP layer with a non-duplicated stream of packets. However, while it is desirable that lower layers provide for non- duplication, this is not a requirement. The Identifier field provides both the peer and authenticator with the ability to detect duplicates. [4] Possible reordering. EAP provides its own mechanisms to detect reordering and so does not assume that the lower layer provides ordering guarantees. 3.2. EAP usage within PPP In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase. After the link has been established, PPP provides for an optional Authentication phase before proceeding to the Network-Layer Protocol phase. By default, authentication is not mandatory. If authentication of the link is desired, an implementation MUST specify the Authentication- Protocol Configuration Option during Link Establishment phase. The server can use the identification of the connecting host or router in the selection of options for network layer negotiations. When implemented within PPP, EAP does not select a specific authentication mechanism at PPP Link Control Phase, but rather postpones this until the Authentication Phase. This allows the authenticator to request more information before determining the specific authentication mechanism. This also permits the use of a "back-end" server which actually implements the various mechanisms while the PPP authenticator merely passes through the authentication exchange. The PPP Link Establishment and Authentication phases, and the Authentication-Protocol Configuration Option, are defined in The Point-to-Point Protocol (PPP) [RFC1661]. 3.2.1. PPP Configuration Option Format A summary of the PPP Authentication-Protocol Configuration Option format to negotiate the EAP Authentication Protocol is shown below. The fields are transmitted from left to right. Exactly one EAP packet is encapsulated in the Information field of a PPP Data Link Layer frame where the protocol field indicates type hex C227 (PPP EAP). 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 | Length | Authentication-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length 4 Authentication-Protocol C227 (Hex) for PPP Extensible Authentication Protocol (EAP) 3.3. EAP usage within IEEE 802 The encapsulation of EAP over IEEE 802 link layers is defined in [IEEE8021X]. The IEEE 802 encapsulation of EAP does not involve PPP, and IEEE 802.1X does not include support for link or network layer negotiations. As a result, within IEEE 802.1X it is not possible to negotiate non-EAP authentication mechanisms, such as PAP or CHAP [RFC1994]. 3.4. Link layer indications The reliability and security of link layer indications is dependent on the medium. Link layer failure indications accepted by the link layer and provided to EAP MUST be processed. However, link layer success indications MUST NOT result in an EAP implementation concluding that authentication has succeeded, since these indications are typically unauthenticated. In PPP, link layer indications are not authenticated and are therefore subject to spoofing, provided that the attacker can gain access to the physical medium. This includes LCP-Terminate (a link failure indication), NCP (a link success indication), and "link down" (a link failure indication). In 802.11, control and management frames are not authenticated and an attacker within range can gain access to the physical medium. Link layer indications include Disassociate and Deauthenticate frames (link failure indications), and Association and Reassociation Response frames (link success indications). In IEEE 802 wired networks, the IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames are not authenticated or integrity protected, whereas within 802.11, authentication and integrity protection is possible depending on when they are sent and the ciphersuite that has been negotiated. Therefore, depending on the circumstances, EAPOL-Start and EAPOL-Logoff frames may or may not be subject to authenticated and integrity protected. In 802.11 a "link down" indication is an unreliable indication of link failure, since wireless signal strength can come and go and may be influenced by radio frequency interference generated by an attacker. From aboba@internaut.com Fri Jan 3 18:55:55 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 3 Jan 2003 10:55:55 -0800 (PST) Subject: [eap] Proposed strawman Section 7.2, Security Terms Message-ID: The -08 Security Term definitions were fairly lame. Here is a strawman revised section which hopefully hits closer to the mark. Comments welcome. 7.2. Security terms Mutual authentication This refers to a method in which, within a single conversation, the authenticator authenticates the peer and the peer authenticates the authenticator. Two one-way conversations, running in opposite directions do not provide mutual authentication as defined here. Integrity protection This refers to authentication and integrity protection of EAP messages, including EAP Requests and Responses and success and failure indications. Replay protection This refers to protection against replay of EAP messages, including EAP Requests and success and failure indications. Confidentiality This refers to encryption of EAP messages, including EAP Requests and Responses, and success and failure indications. A method making this claim MUST include support for identity protection. Key derivation This refers to the ability of the EAP method to derive ciphersuite-independent master session keys, used only for further key derivation. Key strength This refers to the effective entropy of the derived master session keys, independent of their physical length. For example, a 128-bit key derived from a password might have an effective entropy much less than 128 bits. Dictionary attack resistance Where password authentication is used, users are notoriously prone to selection of poor passwords. A method may be said to be dictionary attack resistant if, when there is a weak password in the secret, the method does not allow an attack more efficient than brute force. Fast reconnect The ability, in the case where a security association has been previously established, to create a new or refreshed security association in a smaller number of round-trips. Man-in-the-Middle resistance The ability for the peer to demonstrate to the authenticator that it has acted as the peer for each method within a sequence of methods or tunnel. Similarly, the authenticator demonstrates to the peer that it has acted as the authenticator for each method within the sequence or tunnel. If this is not possible, then the authentication sequence or tunnel may be vulnerable to a man-in-the-middle attack. Acknowledged result indications The ability of the authenticator to provide the peer with an indication of whether the peer has successfully authenticated to it, and for the peer to acknowledge receipt, as well as providing an indication of whether the authenticator has successfully authenticated to the peer. Since cleartext success/failure indications can be spoofed, making this claim requires that the result exchange be integrity protected. From aboba@internaut.com Fri Jan 3 18:58:11 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 3 Jan 2003 10:58:11 -0800 (PST) Subject: [eap] Revised Section 5.7: Vendor-Specific Message-ID: Based on Paul Funk's comments, I've revised Section 5.7, Vendor-Specific. Here is the proposed strawman text. Comments welcome. I'm still working on the revisions to the Nak section; those will be ready for review in a day or two. 5.7. 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-Data The Vendor-Data field is defined by the vendor. Where a Vendor-Id of zero is present, the Vendor- Data field will be used for transporting the contents of EAP Methods of Types defined by the IETF. From james.d.carlson@east.sun.com Fri Jan 3 20:18:35 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Fri, 3 Jan 2003 15:18:35 -0500 Subject: [eap] Strawman rewrite of Section 4.1 In-Reply-To: Bernard Aboba's message of 3 January 2003 10:50:35 References: Message-ID: <15893.61467.438225.893942@gargle.gargle.HOWL> Bernard Aboba writes: > The Request packet is sent by the authenticator to the peer. Each > Request has a type field which serves to indicate what is being > requested. The authenticator MUST transmit an EAP packet with the > Code field set to 1 (Request). I'm not sure what the effect of the MUST is above. There are no other Request messages except those with Code field set to 1. Should this instead say that the authenticator MUST use Requests? Even so, I don't see that this is an actual requirement -- a hypothetical 'null authentication' implementation could start the conversation by sending a single Success message. (Noting that Identity is optional, and that no other messages are required.) > on the Request type. The peer MUST send a Response packet in reply to > a Request packet. This isn't quite true. The peer may discard the Request. What it MUST NOT do is send a Response message on its own. So, either reword as: The peer MUST send a Response packet only as a reply to a received Request packet. or just delete in favor of the next sentence: > Responses MUST only be sent in reply to a received > Request and never retransmitted on a timer. [...] > then the Response MUST be silently discarded. Authenticators > receiving an EAP Response with a Type for which the authenticator has > no outstanding Request MUST silently discard the Response. Type can be Nak. > The authenticator MUST NOT send a new Request until a valid Response > is received to an outstanding Request. That's an interesting new requirement; it's not in RFC 2284. Is this requirement necessary? What does an authenticatee do if it gets a Request with a new Identifier number despite this restriction? > Where the authentication process requires user input, the measured > round trip times are largely be determined by user responsiveness > rather than network characteristics, so that RTO estimation is not > helpful. How does the authenticator know when the authenticatee's processing requires user input (and thus no RTO is done) and when it does not (and RTO is done)? Does this come from the authentication server as well? > The Identifier field is one octet. The Identifier field MUST be the > same if a Request packet is retransmitted due to a timeout while > waiting for a Response. Any new (non-retransmission) Requests MUST > modify the Identifier field. In order to avoid confusion between new > Requests and retransmissions, the Identifier value chosen for each > new Request MUST be unique within the EAP conversation. One way to > achieve this is to start the Identifier at an initial value and > increment it for each new Request. That doesn't make the Identifier unique unless you assume that 256 or fewer EAP messages are ever sent on the link. That's almost certainly not the case if rechallenges are involved. The requirement on Identifiers is really much less than that: the Identifier number must not repeat within a full RTT on the link. Since the protocol is simplex, this is trivial to accomplish in practice. For what it's worth, initializing the first Identifier to be sent with a random number (rather than always using 0 and counting up) is a Good Practice and might be noted. > The Identifier field need only be > unique on a per-port basis, so that authenticators are not restricted > to only 255 simultaneous authentication conversations. I do not quite understand that statement. If they weren't specific to the authentication session (I would use "session" rather than "port"), then the limit would be far lower than 255 -- 128 would be the maximum (ping-ponging between two Identifiers on each link). -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From yohba@tari.toshiba.com Fri Jan 3 23:15:16 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Fri, 3 Jan 2003 18:15:16 -0500 Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: References: <15893.46131.261441.87201@gargle.gargle.HOWL> Message-ID: <20030103231516.GA4120@catfish> On Fri, Jan 03, 2003 at 07:30:11AM -0800, Bernard Aboba wrote: > I'd argue that the peer will have more work to do in event of a DoS > attack, but if there is no silent discard, then it will > eventually get to the valid Request that passes the MIC check, amongst the > sea of invalid Requests. What I don't like is the idea of silently discarding a > valid Request packet as a result of receiving (and not yet responding to) an > invalid Request. As you've pointed out, this doesn't happen on the > authenticator side, because the term "valid Response" is used. There would be two issues if there is no silent discard on detecting duplicate Request. First, each EAP method specification is required to have explicit description on the behavior when detecting duplicate Request, which might complicate the method design. Second, eliminating silent discard could introduce another type of DoS attack. A peer might have to spend its CPU resource for cryptographic calculation of many broken requests until it finally receives cryptographically valid request. The attack will be more "effective", especially if the cypher suites applied to the method is a type of doing encryption after adding sequence number and ICV fields (like TLS does) as replay protection cannot be performed before decrypting the packet. Yoshihiro Ohba > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Fri Jan 3 23:10:32 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 3 Jan 2003 15:10:32 -0800 (PST) Subject: [eap] Strawman rewrite of Section 4.1 In-Reply-To: <15893.61467.438225.893942@gargle.gargle.HOWL> Message-ID: > > The authenticator MUST NOT send a new Request until a valid Response > > is received to an outstanding Request. > > That's an interesting new requirement; it's not in RFC 2284. Is this > requirement necessary? What does an authenticatee do if it gets a > Request with a new Identifier number despite this restriction? Within EAP the Window size is only 1, so an authenticator can't send two Requests with different IDs, can it? It might seem obvious, but the question has come up. The authenticatee can't know if the authenticator has received a Response, but if it receives a packet with a new ID before sending a Response to the initial one, doesn't it silently discard the one with the new ID? > How does the authenticator know when the authenticatee's processing > requires user input (and thus no RTO is done) and when it does not > (and RTO is done)? Does this come from the authentication server as > well? Yes. The authentication server sends a Session-Timeout attribute to provide a hint. If no attribute is sent, the default behavior is used. > That doesn't make the Identifier unique unless you assume that 256 or > fewer EAP messages are ever sent on the link. That's almost certainly > not the case if rechallenges are involved. Yes, requiring uniqueness probably makes DoS attacks easier. I think this should say "need only be different from the previous request". > For what it's worth, initializing the first Identifier to be sent with > a random number (rather than always using 0 and counting up) is a Good > Practice and might be noted. Yes. Will add this. > > > The Identifier field need only be > > unique on a per-port basis, so that authenticators are not restricted > > to only 255 simultaneous authentication conversations. > > I do not quite understand that statement. If they weren't specific to > the authentication session (I would use "session" rather than "port"), > then the limit would be far lower than 255 -- 128 would be the maximum > (ping-ponging between two Identifiers on each link). This was added because some folks assumed that there could only be 256 EAP conversations in progress, because the Identifier space is 8 bits. The intent was to make clear that there is an independent Identifier space for each session. From aboba@internaut.com Fri Jan 3 23:13:27 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 3 Jan 2003 15:13:27 -0800 (PST) Subject: [eap] Proposed Resolution of Issue 56: Expanded Type Format Message-ID: I've take the liberty of splitting Paul Funk's contribution into two parts, one for the changes to the Expanded Type format (Issue 56), and the rest for the changes relating to vendor-specific Nak (Issue 41). My recommendation is that the proposed resolution of Issue 56 (enclosed below) be accepted. Issue 56: Expanded Type format Submitter name: Paul Funk Submitter email address: paul@funk.com Date first submitted: December 10, 2002 Document: RFC2284bis-08 Comment type: T Priority: S Section: 5.7 Rationale/Explanation of issue: 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. 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. Proposed Resolution: Accept From aboba@internaut.com Fri Jan 3 23:35:46 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 3 Jan 2003 15:35:46 -0800 (PST) Subject: [eap] Proposed Resolution to Issue 53: NAK of Identity messages Message-ID: RFC 2284 appears to support the notion that a NAK may not be sent in Response to an Identity Request. However, this leaves open the question of what an authenticator does if a NAK is sent anyway. While it can be argued that Peer with an unknown identity can send a NULL Identity Response, there are other cases where the Peer might want to terminate the conversation. For example, if an 802.11 STA sends an Identity Request to an AP (EAP is a Peer to Peer protocol so this is legal), the AP could silently discard the packet, but this will just result in a retransmission. So there is a need for a packet that a Peer can send that says "I don't want to authenticate, please stop." As a result, the proposed resolution is not to prohibit the sending of a NAK, but to make clear that this is not the preferred way to say "I don't have an Identity" -- sending a NULL Identity Response is preferred. Rather, the implication is "I am requesting Identity Protection" (if one or more alternate Types are provided) or "Please go away" (if no Types are provided). Proposed Text: "An optional displayable message MAY be included within an Identity Request, to prompt the Peer in the case where there is an expectation of interaction with a user. An Identity Response MUST be sent to an Identity Request. A peer with no known identity to offer SHOULD send a NULL Identity Response. If the peer requires identity protection (wants to negotiate a method that negotiates cryptographic protection before providing its Identity), then it MAY send a Nak, including one or more preferred Types. If the peer does not wish to authentiate via EAP, then it MAY send a NAK with no alternative authentication method." Issue 53: NAK of Identity message Submitter name: James Carlson Submitter email address: james.d.carlson@sun.com. Date first submitted: January 2, 2003 Document: RFC2284bis Comment type: T Priority: S Section: 5.1 Rationale/Explanation of issue: The change made in this draft breaks compatibility with the prior RFC, and doesn't appear to add any benefit. Worse, it means that there's now a completely undefined corner in the protocol: what do you do if the peer sends Nak for Identity anyway? Do you terminate? Try again? This was once well-defined (process as you would for any Nak), and is now undefined. Requested change: from: An optional displayable message MAY be included within an Identity Request, to prompt the Peer in the case where there is an expectation of interaction with a user. An Identity Response MUST be sent to an Identity Request. A Peer MUST NOT respond to an Identity Request with a NAK. to: An optional displayable message MAY be included within an Identity Request, to prompt the Peer in the case where there is an expectation of interaction with a user. An Identity Response MUST be sent to an Identity Request. A peer with no known identity to offer MAY send Nak instead. Response from Bernard Aboba: "Here is the text in RFC 2284 that lead to the conclusion that Identity Requests (and Notification Requests) can't be NAK'd: Section 3.3 "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." Since Identity is Type 1, and Notification is Type 2, the conclusion was drawn that NAKs cannot be sent in response to these requests. From james.d.carlson@east.sun.com Sun Jan 5 16:10:12 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Sun, 5 Jan 2003 11:10:12 -0500 Subject: [eap] Strawman rewrite of Section 4.1 In-Reply-To: Bernard Aboba's message of 3 January 2003 15:10:32 References: <15893.61467.438225.893942@gargle.gargle.HOWL> Message-ID: <15896.22756.608443.626644@gargle.gargle.HOWL> Bernard Aboba writes: > > > The authenticator MUST NOT send a new Request until a valid Response > > > is received to an outstanding Request. > > > > That's an interesting new requirement; it's not in RFC 2284. Is this > > requirement necessary? What does an authenticatee do if it gets a > > Request with a new Identifier number despite this restriction? > > Within EAP the Window size is only 1, so an authenticator can't send two > Requests with different IDs, can it? It might seem obvious, but the > question has come up. Of course it can. It just can't expect a Response to any of the prior Requests it may have sent. RFC 2284 does not have the restriction this draft now imposes. All it says is that *if* you send something other than a retransmission, then you must change the Identifier field: The Identifier field is one octet. The Identifier field MUST be the same if a Request packet is retransmitted due to a timeout while waiting for a Response. Any new (non-retransmission) Requests MUST modify the Identifier field. If a peer recieves a It doesn't say that you actually have to receive the Response. Fortunately, there's no way that the RFC could require this. There's no way to tell precisely if the Response was actually received by the authenticator -- it could still have been lost somewhere in the receiver's internal software before being seen by EAP, and no part of the subsequent Request has information from the prior Response from EAP's point of view -- though perhaps not so from the details of a particular method. > The authenticatee can't know if the authenticator has received a Response, > but if it receives a packet with a new ID before sending a Response > to the initial one, doesn't it silently discard the one with the new ID? I'd have to say "no." Where is that restriction in RFC 2284? Why is that restriction needed at all? I don't see the point. > > How does the authenticator know when the authenticatee's processing > > requires user input (and thus no RTO is done) and when it does not > > (and RTO is done)? Does this come from the authentication server as > > well? > > Yes. The authentication server sends a Session-Timeout attribute to > provide a hint. If no attribute is sent, the default behavior is used. This is all implementation advice. I think it should probably be made a little less prominent. I'm not even sure that it's the right advice. I understand the RFC 2865 RADIUS Session-Timeout attribute differently -- it's the maximum time-to-live for the entire user session, not for a specific message or prompt. Value The field is 4 octets, containing a 32-bit unsigned integer with the maximum number of seconds this user should be allowed to remain connected by the NAS. > > That doesn't make the Identifier unique unless you assume that 256 or > > fewer EAP messages are ever sent on the link. That's almost certainly > > not the case if rechallenges are involved. > > Yes, requiring uniqueness probably makes DoS attacks easier. I think this > should say "need only be different from the previous request". I was pointing out that uniqueness (good or bad) isn't actually possible. "Minimal reuse" is possible, though. > > I do not quite understand that statement. If they weren't specific to > > the authentication session (I would use "session" rather than "port"), > > then the limit would be far lower than 255 -- 128 would be the maximum > > (ping-ponging between two Identifiers on each link). > > This was added because some folks assumed that there could only be 256 EAP > conversations in progress, because the Identifier space is 8 bits. The > intent was to make clear that there is an independent Identifier space for > each session. In that case, removing the reference to "ports" (which aren't defined or used elsewhere in the document) might be good. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Sun Jan 5 16:21:24 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Sun, 5 Jan 2003 11:21:24 -0500 Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: Yoshihiro Ohba's message of 3 January 2003 18:15:16 References: <15893.46131.261441.87201@gargle.gargle.HOWL> <20030103231516.GA4120@catfish> Message-ID: <15896.23428.533894.526122@gargle.gargle.HOWL> Yoshihiro Ohba writes: > There would be two issues if there is no silent discard on > detecting duplicate Request. > > First, each EAP method specification is required to have explicit > description on the behavior when detecting duplicate Request, which > might complicate the method design. No. RFC 2284 EAP already describes what to do when you detect a duplicate Request at the authenticatee. EAP methods that choose to override this behavior by definition can do that, but they're certainly not required to do this. I'd additionally argue that any EAP method that goes so far as to redefine EAP's clear handling of duplicates to be flawed. I don't see what value such a method could add. If there are such methods, a much better way to guarantee recalculation (which is obviously what's wanted) is to change the Identifier and the contents of the Request for each Request sent. That's compatible with RFC 2284 and doesn't require magic behavior on the part of the authenticatee. > Second, eliminating silent discard could introduce another type of DoS > attack. A peer might have to spend its CPU resource for cryptographic > calculation of many broken requests until it finally receives > cryptographically valid request. That's incorrect per RFC 2284. If you receive a duplicate Request, you do *NO* additional calculation in any case. You instead resend the last Response, if you have one, or nothing if you don't: Requests MUST modify the Identifier field. If a peer recieves a duplicate Request for which it has already sent a Response, it MUST resend it's Response. If a peer receives a duplicate Request before it has sent a Response to the initial Request (i.e. it's waiting for user input), it MUST silently discard the duplicate Request. Note that it just says "resend it's [sic] Response." It doesn't say "recalculate the result based on the Request and then transmit that Response." > The attack will be more "effective", > especially if the cypher suites applied to the method is a type of > doing encryption after adding sequence number and ICV fields (like TLS > does) as replay protection cannot be performed before decrypting the > packet. Replay protection consists of making sure that the same saved Response value can never be a valid Response in a future session, nor a valid Response to a rechallenge in the same session. It's immaterial for repeats involved in retransmissions. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From npetroni@cs.umd.edu Sun Jan 5 20:46:02 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Sun, 5 Jan 2003 15:46:02 -0500 (EST) Subject: [eap] Strawman rewrite of Section 4.1 In-Reply-To: <15896.22756.608443.626644@gargle.gargle.HOWL> Message-ID: > > Within EAP the Window size is only 1, so an authenticator can't send two > > Requests with different IDs, can it? It might seem obvious, but the > > question has come up. > > Of course it can. It just can't expect a Response to any of the prior > Requests it may have sent. RFC 2284 does not have the restriction > this draft now imposes. All it says is that *if* you send something > other than a retransmission, then you must change the Identifier > field: Maybe I am misunderstanding the second sentence, but why can't the authenticator expect a response to prior requests if mutliple different ones can be sent (which I am not sure they can)? The Peer MUST respond to all requests, how should it know a new one is coming and that is shouldn't respond to the old one? Perhaps you mean the authenticator can choose to disregard responses to old requests? In that case, how will the peer know which track the conversation is following since the original requests could have arrived out of order? From james.d.carlson@east.sun.com Sun Jan 5 21:21:45 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Sun, 5 Jan 2003 16:21:45 -0500 Subject: [eap] Strawman rewrite of Section 4.1 In-Reply-To: Nick Petroni's message of 5 January 2003 15:46:02 References: <15896.22756.608443.626644@gargle.gargle.HOWL> Message-ID: <15896.41449.806785.993398@gargle.gargle.HOWL> Nick Petroni writes: > > Of course it can. It just can't expect a Response to any of the prior > > Requests it may have sent. RFC 2284 does not have the restriction > > this draft now imposes. All it says is that *if* you send something > > other than a retransmission, then you must change the Identifier > > field: > Maybe I am misunderstanding the second sentence, but > why can't the authenticator expect a response to prior requests if > mutliple different ones can be sent (which I am not sure they can)? Because the only Response that the authenticator can accept is one that has an Identifier that matches the current value. If I send Request ID=1 and then send Request with ID=2, I can receive only Response with ID=2. As RFC 2284 puts it: [...] The Identifier field of the Response MUST match that of the Request. I suppose as a design point, one could imagine having multiple outstanding Requests. Since the negotiation was patterned after PPP negotiation, I doubt that was the intent. > The > Peer MUST respond to all requests, how should it know a new one is coming > and that is shouldn't respond to the old one? It can't know in advance. But if an implementation receives a new Request with a new ID value, then it does not have to respond to any prior Requests to which it hasn't already responded. By definition, a properly implemented EAP authenticator would discard them anyway. > Perhaps you mean the authenticator can choose to disregard responses to > old requests? I would argue that it *must* disregard responses to old requests. > In that case, how will the peer know which track the > conversation is following since the original requests could have arrived > out of order? EAP was originally defined to run on PPP and RFC 1661 has the necessary ordering requirement: 1. Introduction The Point-to-Point Protocol is designed for simple links which transport packets between two peers. These links provide full-duplex simultaneous bi-directional operation, and are assumed to deliver packets in order. It is intended that PPP provide a common solution Any other transport of EAP *must* respect the ordering requirements of PPP. All that any EAP authenticatee has to do is to respond to the Request messages that come in. It doesn't have to "track" any conversations. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From npetroni@cs.umd.edu Sun Jan 5 21:46:39 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Sun, 5 Jan 2003 16:46:39 -0500 (EST) Subject: [eap] Strawman rewrite of Section 4.1 In-Reply-To: <15896.41449.806785.993398@gargle.gargle.HOWL> Message-ID: > > In that case, how will the peer know which track the > > conversation is following since the original requests could have arrived > > out of order? > > EAP was originally defined to run on PPP and RFC 1661 has the > necessary ordering requirement: Originally, yes. But, 2284bis extends the applicability of EAP. From section 3 of 2284bis: [4] Possible reordering. EAP provides its own mechanisms to detect reordering and so does not assume that the lower layer provides ordering guarantees. EAP is a "lockstep" protocol, so that the Authenticator MUST NOT send a new Request until a Response is received to an outstanding Request. Since the Peer should not expect a new Request until it has sent a Response, if it receives a new Request with a different Identifier before sending a Response to the outstanding Request, the new Request MUST be silently discarded. Similarly, if the Authenticator receives a Response with an Identifier that does not match the Identifier in the outstanding Request, the Response MUST be silently discarded. > All that any EAP authenticatee has to do is to respond to the Request > messages that come in. It doesn't have to "track" any conversations. Methods may rely on messages being presented to them in a certain order, if EAP does not guarantee this order much more work needs to be put into method design. I don't think the case can be made that EAP just shouldn't be run over out-of-order protocols. Perhaps method designers can weigh-in on this a little, but I would think problems do arise without in-order presentation. nick From yohba@tari.toshiba.com Mon Jan 6 02:35:41 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Sun, 5 Jan 2003 21:35:41 -0500 Subject: [eap] Re: Survey: handling of retransmissions In-Reply-To: <15896.23428.533894.526122@gargle.gargle.HOWL> References: <15893.46131.261441.87201@gargle.gargle.HOWL> <20030103231516.GA4120@catfish> <15896.23428.533894.526122@gargle.gargle.HOWL> Message-ID: <20030106023541.GA6274@catfish> I agree with James' commment. Please see my additional comment in line. On Sun, Jan 05, 2003 at 11:21:24AM -0500, James Carlson wrote: > Yoshihiro Ohba writes: > > There would be two issues if there is no silent discard on > > detecting duplicate Request. > > > > First, each EAP method specification is required to have explicit > > description on the behavior when detecting duplicate Request, which > > might complicate the method design. > > No. RFC 2284 EAP already describes what to do when you detect a > duplicate Request at the authenticatee. EAP methods that choose to > override this behavior by definition can do that, but they're > certainly not required to do this. > > I'd additionally argue that any EAP method that goes so far as to > redefine EAP's clear handling of duplicates to be flawed. I don't see > what value such a method could add. > > If there are such methods, a much better way to guarantee > recalculation (which is obviously what's wanted) is to change the > Identifier and the contents of the Request for each Request sent. > That's compatible with RFC 2284 and doesn't require magic behavior on > the part of the authenticatee. > > > Second, eliminating silent discard could introduce another type of DoS > > attack. A peer might have to spend its CPU resource for cryptographic > > calculation of many broken requests until it finally receives > > cryptographically valid request. > > That's incorrect per RFC 2284. If you receive a duplicate Request, > you do *NO* additional calculation in any case. You instead resend > the last Response, if you have one, or nothing if you don't: > > Requests MUST modify the Identifier field. If a peer recieves a > duplicate Request for which it has already sent a Response, it > MUST resend it's Response. If a peer receives a duplicate Request > before it has sent a Response to the initial Request (i.e. it's > waiting for user input), it MUST silently discard the duplicate > Request. I agree. I think the above text in RFC2284 is now missing in the recent strawman rewrite of section 4.1 recently posted on the mailing list and should be included in RFC2284bis, thinking much about compatibility with RFC2284 than trying to modify the EAP protocol behavior just to deal with the TLS problem. > > Note that it just says "resend it's [sic] Response." It doesn't say > "recalculate the result based on the Request and then transmit that > Response." > > > The attack will be more "effective", > > especially if the cypher suites applied to the method is a type of > > doing encryption after adding sequence number and ICV fields (like TLS > > does) as replay protection cannot be performed before decrypting the > > packet. > > Replay protection consists of making sure that the same saved Response > value can never be a valid Response in a future session, nor a valid > Response to a rechallenge in the same session. It's immaterial for > repeats involved in retransmissions. > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Yoshihiro Ohba From jesse.walker@intel.com Mon Jan 6 15:49:24 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Mon, 6 Jan 2003 07:49:24 -0800 Subject: [eap] RE: Request for feedback Message-ID: Bernard, Here is a response to your request for feedback on draft rfs2284bis rev 8. Major Issues: Page 5 includes the text: 7. Since EAP is a Peer-to-Peer protocol, after authentication in one direction is complete, the direction of authentication MAY reverse, with the endpoint previously serving as the Authenticator assuming the Peer role, and the former Peer now taking on the Authenticator role. As with the original conversation, the reversal is signaled by the (new) Authenticator sending a Request. Support for bi-directional authentication requires that each endpoint implement both the Peer and Authenticator roles. and page 31 continues in this theme with In EAP there is no requirement that authentication be full duplex or that the same protocol be used in both directions. It is perfectly acceptable for different protocols to be used in each direction. This will, of course, depend on the specific protocols negotiated. However, in general, completing a single, mutual authentication is preferable to two one-way authentications, one in each direction. These two texts appear to have been written under the misapprehension that two unrelated unilateral authentications glued together in arbitrary undefined ways can result in multual authentication. It does not and cannot; in general the two unilateral authentications remain simply unilateral authentications. It is in general not feasible to defeat man-in-the-middle attacks--and hence in general it is not feasible to rely on the unilateral authentication for any useful assertion--without relating the two cryptographically in very specific ways. Allowing reversal of roles is a recipe for disaster unless very great care is taken to relate the two authentications, and there is no evidence such a task is even feasible for all but a few legacy unilateral authentication mechanisms. We have already seen a variant of this problem with PEAP and TTLS, both of which are much stronger than the construction this text seems to sanction. To correct this problems, I suggest adding text at the end of that cited on page 5 such as "In environments where man-in-the-middle attacks are possible, at least one of the two concrete Authentications MUST rely on an algorithm that performs a mutual authentication. This obviates the need for reversing the roles of Authenticator and Peer." To the end of the text cited from page 31, as text something like "This is because using separate authentications that are not bound cryptographically to demonstrate they are part of the same session are always subject to man-in-the-middle attacks." Or better yet, explicitly ban role reversal of the kind indicated here. That is simpler, and simplicity almost always leads to better security. Page 6: There is a sentence that begins Unless protected by an underlying link layer ciphersuite In the case where the Authentication Server is not the Authenticator, this suffers from a similar problem. Relying on a link layer ciphersuite between the Authenticator and the Peer to protect messages between the Authentication Server and the Peer is subject to man-in-the-middle abuses; if the protections are not applied end-to-end, then they cannot necessarily be effective. I think what is really intended is that the EAP messages be protected by a ciphersuite associated with the concrete authentication method, and the text should be updated to reflect this. Minor Issues: Pages 1 (Abstract), 3 (Introduction): The text still speaks of EAP as an "authentication protocol". It is not since in and of itself it performs no authentication. How about "authentication protocol transport"? Page 3: In the defintion of "Silently Discard, a sentence begins: The implementation SHOULD provide the capability of logging the error There is an implicit assumption in this sentence that silently discard occurs only in response to an error. This should be made explicit or else the assumption removed. Page 6: "Protected success/failure" is never defined. Page 6: There is a sentence which says: Where a protected success/failure indication has been received at the EAP layer by an EAP Peer, it MUST accept and process the protected indication. This is a vacuous requirement, because there is no definition of what it means to "process" the "protected indication". At the very least this should indicate that "to process" means something like (a) apply all the protections of whatever ciphersuite that one believes to have been applied to the message to (b) extract a success/failure message, which is then handled according to the normal rules for EAP success/failure messages, and (c) received EAP success/failure messages that arrive unprotected are silently discarded if protection is expected. Page 16: The phrase "and and" appears. Pages 20, 21, and 22 use the phrase "IEEE 802" as a synonym for "IEEE 802 wired networks" Please clean this up. Page 23 has the language "application specific" which is not wrong per se but does appear to be misleading. Can we replace this with "vendor specific", since that is what the text is talking about? Page 32 Clause 7.11 says that This specification does not provide guidance on how EAP methods are to derive keys. I think it is possible to give some general but practical guidelines: a. the key MUST be a fresh, never-before used key, because otherwise it is in general infeasible to use the key to detect messages replayed from prior sessions. b. there MUST be some way to name the key, to determine whether it belongs to this or to some other session. c. the key is an authorization token (use of the key demonstrates authorization to access the channel), so the relation of the key to the authentication that authorized this key MUST be made explicit to understand the security relationship of the key to the EAP method. d. in the case where more than authentication method is used (think of PEAP or TTLS, not the approach complained about on page 5 and 31) and more than one method derives keys, then the method description MUST indicate which keys are distributed for use by the Authenticator and Peer, and how. For instance, in the PEAP/TTLS case, the key derived by the inner method could be combined using a pseudo-random function with the TLS key to cryptographically bind the inner and outer keys, and this combined key would be used by the Authenticator and Peer. I would also like to see the following two additional guidelines, but they may be more controversial, so I will not insist: e. When the purpose of the authentication is to authorize use of the data link channel between the Peer and the Authenticator, to understand its security one needs to know how the derived key is bound to the channel, so that (ab)use of it in other contexts can be detected. It would be nice if the method could (SHOULD?) provide guidance on this issue, e.g., specify the assumptions it makes about how this binding occurs. f. When the Authenticator and Authentication Server are not the same party, one needs to understand how the key is distributed to the Authenticator (and to the Peer, if it needs to be transported) to understand the security properties of the key. It would be nice if the method could (SHOULD?) provide guidance about this, e.g., specify the assumptions it makes about how key distribution is effected. -- Jesse > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Saturday, December 21, 2002 11:18 AM > To: Walker, Jesse > Subject: Request for feedback > > > Since you will be taking a vacation during the holidays, may I > suggest that you consider reading and commenting on an EAP WG > draft during > your downtime. > > EAP WG drafts make excellent reading material, particularly before bed > time, taken with spiced egg nog. For your consideration, I > would like to > recommend the following drafts: > > http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284b is-08.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 james.d.carlson@east.sun.com Mon Jan 6 16:03:31 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Mon, 6 Jan 2003 11:03:31 -0500 Subject: [eap] Strawman rewrite of Section 4.1 In-Reply-To: Nick Petroni's message of 5 January 2003 16:46:39 References: <15896.41449.806785.993398@gargle.gargle.HOWL> Message-ID: <15897.43219.520135.258707@gargle.gargle.HOWL> Nick Petroni writes: > > > In that case, how will the peer know which track the > > > conversation is following since the original requests could have arrived > > > out of order? > > > > EAP was originally defined to run on PPP and RFC 1661 has the > > necessary ordering requirement: > Originally, yes. But, 2284bis extends the applicability of EAP. From > section 3 of 2284bis: > [4] Possible reordering. EAP provides its own mechanisms to detect > reordering and so does not assume that the lower layer provides > ordering guarantees. This part is false. EAP as defined in the draft simply cannot detect all possible cases of reordering. Consider the following case: Authenticator Authenticatee Request ID=1 >--------> (got req 1) ----< Response ID=1 (timeout) / Request ID=1 >--/ /\ (got resp 1) <- | Request ID=2 >--------> (got req 2) | --< Response ID=2 | / (got resp 2) <----- \ ---> (got req 1) (disc bad id) <-------< Response ID=1 At this point, the session is completely scrazzled. Authenticatee is unable to tell that the second "Request ID=1" message it got was actually just a retransmission, so it must treat it as a new Request, and must reinvoke whatever process was used to generate the Response. Besides being just wasteful, this also means that (1) any saved state on the Authenticatee side (e.g., values used to compute shared keys) is now trashed and (2) the actual Response data may differ from the original Response data, leading to chaos. EAP as currently defined can't do what you want here. If the RFC had defined a sequence space with a "less than" comparison operation, then you could probably do it, but that's no longer the same as RFC 2284 EAP. > EAP is a "lockstep" protocol, so that the > Authenticator MUST NOT send a new Request until a Response is > received to an outstanding Request. Since the Peer should not > expect a new Request until it has sent a Response, if it receives a > new Request with a different Identifier before sending a Response > to the outstanding Request, the new Request MUST be silently > discarded. That's not compatible with 2284, which has no such restriction. > > All that any EAP authenticatee has to do is to respond to the Request > > messages that come in. It doesn't have to "track" any conversations. > Methods may rely on messages being presented to them in a certain order, > if EAP does not guarantee this order much more work needs to be put into > method design. I don't think the case can be made that EAP just shouldn't > be run over out-of-order protocols. Really? Why not? That was the original intent of RFC 2284. It was modeled on PPP negotiation, and PPP negotiation most explicitly does *not* survive out-of-order delivery. If there's some transport being planned for EAP that does present the possibility of out-of-order delivery, then I think that probably needs a little more careful examination. > Perhaps method designers can weigh-in > on this a little, but I would think problems do arise without in-order > presentation. Those problems certainly do arise. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Mon Jan 6 16:25:51 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Mon, 6 Jan 2003 11:25:51 -0500 Subject: [eap] RE: Request for feedback In-Reply-To: Walker, Jesse's message of 6 January 2003 07:49:24 References: Message-ID: <15897.44559.119293.544433@gargle.gargle.HOWL> Walker, Jesse writes: > These two texts appear to have been written under the misapprehension that > two unrelated unilateral authentications glued together in arbitrary > undefined ways can result in multual authentication. It does not and cannot; Agreed. > To correct this problems, I suggest adding text at the end of that cited on > page 5 such as "In environments where man-in-the-middle attacks are > possible, at least one of the two concrete Authentications MUST rely on an s/MUST/SHOULD/ -- there's no way to *require* that the peer somehow implement authentication mechanisms that it doesn't. An implementation that chooses to proceed without such a method available does so at its own risk. (And various implementation-dependent mechanisms might be appropriate -- a configuration flag allowing such use, an interactive dialog authorizing the use, a set of reduced capabilities under such a regime, et cetera.) > Or better yet, explicitly ban role reversal of the kind indicated here. That > is simpler, and simplicity almost always leads to better security. I don't think that can be done explicitly. EAP also runs on PPP, and PPP's LCP allows independent negotiation of the authentication protocol to be used in each direction on a link. What you could do would be to include more 'security considerations' advice that indicates why use of a mutual authentication protocol should be preferred over simultaneous authentication. (The obvious cart-before- horse problem: at Establish [LCP] time, there's no way to know what EAP methods are known to the peer. At Authentication [EAP] time, you're already committed to the direction[s] of authentication.) I suppose we could propose extending the LCP option for PPP to list the algorithms [Type numbers] supported so that the peer can tell what it might be able to do. That seems slightly radical to me, though, since it admits a problem with EAP's original design goals. > b. there MUST be some way to name the key, to determine whether it belongs > to this or to some other session. Isn't that really just an issue for media where reliable disconnection indication isn't possible? > f. When the Authenticator and Authentication Server are not the same party, > one needs to understand how the key is distributed to the Authenticator (and > to the Peer, if it needs to be transported) to understand the security > properties of the key. It would be nice if the method could (SHOULD?) > provide guidance about this, e.g., specify the assumptions it makes about > how key distribution is effected. I'd think that's an issue for documents that discuss the protocols used for authentication servers, such as RADIUS and DIAMETER, and the EAP methods themselves. I don't see what value repetition of that information here would provide. (Perhaps a separate BCP on writing EAP methods could contain advice like this ...) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Mon Jan 6 16:16:11 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 6 Jan 2003 08:16:11 -0800 (PST) Subject: [eap] RE: Request for feedback In-Reply-To: Message-ID: Thanks for your feedback, Jesse. I will file this as Issue 57. On Mon, 6 Jan 2003, Walker, Jesse wrote: > Bernard, > > Here is a response to your request for feedback on draft rfs2284bis rev 8. > > Major Issues: Page 5 includes the text: > > 7. Since EAP is a Peer-to-Peer protocol, after > authentication in one direction is complete, the direction > of authentication MAY reverse, with the endpoint > previously serving as the Authenticator assuming the Peer > role, and the former Peer now taking on the Authenticator > role. As with the original conversation, the reversal is > signaled by the (new) Authenticator sending a Request. > Support for bi-directional authentication requires that > each endpoint implement both the Peer and Authenticator > roles. > > and page 31 continues in this theme with > > In EAP there is no requirement that authentication be full > duplex or that the same protocol be used in both > directions. It is perfectly acceptable for different > protocols to be used in each direction. This will, of > course, depend on the specific protocols negotiated. > However, in general, completing a single, mutual > authentication is preferable to two one-way > authentications, one in each direction. > > These two texts appear to have been written under the misapprehension that > two unrelated unilateral authentications glued together in arbitrary > undefined ways can result in multual authentication. It does not and cannot; > in general the two unilateral authentications remain simply unilateral > authentications. It is in general not feasible to defeat man-in-the-middle > attacks--and hence in general it is not feasible to rely on the unilateral > authentication for any useful assertion--without relating the two > cryptographically in very specific ways. Allowing reversal of roles is a > recipe for disaster unless very great care is taken to relate the two > authentications, and there is no evidence such a task is even feasible for > all but a few legacy unilateral authentication mechanisms. We have already > seen a variant of this problem with PEAP and TTLS, both of which are much > stronger than the construction this text seems to sanction. > > To correct this problems, I suggest adding text at the end of that cited on > page 5 such as "In environments where man-in-the-middle attacks are > possible, at least one of the two concrete Authentications MUST rely on an > algorithm that performs a mutual authentication. This obviates the need for > reversing the roles of Authenticator and Peer." To the end of the text cited > from page 31, as text something like "This is because using separate > authentications that are not bound cryptographically to demonstrate they are > part of the same session are always subject to man-in-the-middle attacks." > Or better yet, explicitly ban role reversal of the kind indicated here. That > is simpler, and simplicity almost always leads to better security. > > Page 6: There is a sentence that begins > > Unless protected by an underlying link layer ciphersuite > > In the case where the Authentication Server is not the Authenticator, this > suffers from a similar problem. Relying on a link layer ciphersuite between > the Authenticator and the Peer to protect messages between the > Authentication Server and the Peer is subject to man-in-the-middle abuses; > if the protections are not applied end-to-end, then they cannot necessarily > be effective. I think what is really intended is that the EAP messages be > protected by a ciphersuite associated with the concrete authentication > method, and the text should be updated to reflect this. > > Minor Issues: > > Pages 1 (Abstract), 3 (Introduction): The text still speaks of EAP as an > "authentication protocol". It is not since in and of itself it performs no > authentication. How about "authentication protocol transport"? > > Page 3: In the defintion of "Silently Discard, a sentence begins: > > The implementation SHOULD provide the capability of logging > the error > > There is an implicit assumption in this sentence that silently discard > occurs only in response to an error. This should be made explicit or else > the assumption removed. > > Page 6: "Protected success/failure" is never defined. > > Page 6: There is a sentence which says: > > Where a protected success/failure indication has been > received at the EAP layer by an EAP Peer, it MUST accept > and process the protected indication. > > This is a vacuous requirement, because there is no definition of what it > means to "process" the "protected indication". At the very least this should > indicate that "to process" means something like (a) apply all the > protections of whatever ciphersuite that one believes to have been applied > to the message to (b) extract a success/failure message, which is then > handled according to the normal rules for EAP success/failure messages, and > (c) received EAP success/failure messages that arrive unprotected are > silently discarded if protection is expected. > > Page 16: The phrase "and and" appears. > > Pages 20, 21, and 22 use the phrase "IEEE 802" as a synonym for "IEEE 802 > wired networks" Please clean this up. > > Page 23 has the language "application specific" which is not wrong per se > but does appear to be misleading. Can we replace this with "vendor > specific", since that is what the text is talking about? > > Page 32 Clause 7.11 says that > > This specification does not provide guidance on how EAP > methods are to derive keys. > > I think it is possible to give some general but practical guidelines: > > a. the key MUST be a fresh, never-before used key, because otherwise it is > in general infeasible to use the key to detect messages replayed from prior > sessions. > > b. there MUST be some way to name the key, to determine whether it belongs > to this or to some other session. > > c. the key is an authorization token (use of the key demonstrates > authorization to access the channel), so the relation of the key to the > authentication that authorized this key MUST be made explicit to understand > the security relationship of the key to the EAP method. > > d. in the case where more than authentication method is used (think of PEAP > or TTLS, not the approach complained about on page 5 and 31) and more than > one method derives keys, then the method description MUST indicate which > keys are distributed for use by the Authenticator and Peer, and how. For > instance, in the PEAP/TTLS case, the key derived by the inner method could > be combined using a pseudo-random function with the TLS key to > cryptographically bind the inner and outer keys, and this combined key would > be used by the Authenticator and Peer. > > I would also like to see the following two additional guidelines, but they > may be more controversial, so I will not insist: > > e. When the purpose of the authentication is to authorize use of the data > link channel between the Peer and the Authenticator, to understand its > security one needs to know how the derived key is bound to the channel, so > that (ab)use of it in other contexts can be detected. It would be nice if > the method could (SHOULD?) provide guidance on this issue, e.g., specify the > assumptions it makes about how this binding occurs. > > f. When the Authenticator and Authentication Server are not the same party, > one needs to understand how the key is distributed to the Authenticator (and > to the Peer, if it needs to be transported) to understand the security > properties of the key. It would be nice if the method could (SHOULD?) > provide guidance about this, e.g., specify the assumptions it makes about > how key distribution is effected. > > -- Jesse > > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Saturday, December 21, 2002 11:18 AM > > To: Walker, Jesse > > Subject: Request for feedback > > > > > > Since you will be taking a vacation during the holidays, may I > > suggest that you consider reading and commenting on an EAP WG > > draft during > > your downtime. > > > > EAP WG drafts make excellent reading material, particularly before bed > > time, taken with spiced egg nog. For your consideration, I > > would like to > > recommend the following drafts: > > > > http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284b > is-08.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 aboba@internaut.com Mon Jan 6 16:23:47 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 6 Jan 2003 08:23:47 -0800 (PST) Subject: [eap] Re: [Issue 50] lower layer ordering requirement In-Reply-To: <200301061519.h06FJae01530@internaut.com> Message-ID: > EAP was originally defined to run on PPP and RFC 1661 has the > necessary ordering requirement: > > 1. Introduction > > The Point-to-Point Protocol is designed for simple links which > transport packets between two peers. These links provide full-duplex > simultaneous bi-directional operation, and are assumed to deliver > packets in order. It is intended that PPP provide a common solution > > Any other transport of EAP *must* respect the ordering requirements of > PPP. > Since this snippet relates to link layer requirements (another issue), I've taken the liberty of changing the subject line. Since both the PPP and IEEE 802 link layers provide ordering guarantees, this issue is not directly relevant to those encapsulations of EAP. But we have seen proposals for EAP over UDP or even ICMP, where ordering guarantees would *not* be provided. L2TP is OK, because it does provide ordering guarantees. I had been under the impression that the ACK/NAK nature of EAP provided implicit ordered delivery, so that if the lower layer did *not* provide ordering guarantees, EAP could compensate. Is this not the case? What bad things could happen in an EAP over UDP encapsulation, for example? From yohba@tari.toshiba.com Mon Jan 6 18:11:37 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Mon, 6 Jan 2003 13:11:37 -0500 Subject: [eap] Re: [Issue 50] lower layer ordering requirement In-Reply-To: References: <200301061519.h06FJae01530@internaut.com> Message-ID: <20030106181137.GA1711@catfish> In RFC2284, identifier assignment rule does not mandate the use of monotonically increasing value, which would result in Peer side accepting any Requests that do not have the identifier of the last responded Request. This would make DoS attack easily by randomly sending bogus packets to break authentication exchange. If EAP runs on reliable transport with stricter sequence number rule (e.g., TCP), such a random attack is not possible since the attacker needs to synchronize on the TCP sequence number. BTW, how IEEE 802 link layers provide ordering guarantees? Yoshihiro Ohba On Mon, Jan 06, 2003 at 08:23:47AM -0800, Bernard Aboba wrote: > > EAP was originally defined to run on PPP and RFC 1661 has the > > necessary ordering requirement: > > > > 1. Introduction > > > > The Point-to-Point Protocol is designed for simple links which > > transport packets between two peers. These links provide full-duplex > > simultaneous bi-directional operation, and are assumed to deliver > > packets in order. It is intended that PPP provide a common solution > > > > Any other transport of EAP *must* respect the ordering requirements of > > PPP. > > > > Since this snippet relates to link layer requirements (another issue), > I've taken the liberty of changing the subject line. > > Since both the PPP and IEEE 802 link layers provide ordering guarantees, > this issue is not directly relevant to those encapsulations of EAP. But we > have seen proposals for EAP over UDP or even ICMP, where ordering > guarantees would *not* be provided. L2TP is OK, because it does provide > ordering guarantees. > > I had been under the impression that the ACK/NAK nature of EAP provided > implicit ordered delivery, so that if the lower layer did *not* provide > ordering guarantees, EAP could compensate. > > Is this not the case? What bad things could happen in an EAP over UDP > encapsulation, for example? > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Mon Jan 6 17:29:45 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 6 Jan 2003 09:29:45 -0800 (PST) Subject: [eap] Re: [Issue 50] lower layer ordering requirement In-Reply-To: <20030106181137.GA1711@catfish> Message-ID: A good reference on IEEE 802 link invariants is "The Switch Book" by Rich Seifert. Section 2.2.1 discusses "hard" invariants (non duplication and sequential delivery) and "soft" invariants (low error rate, high bandwidth, low delay). While IEEE 802 has no sequence numbers, and does not require receivers to check for proper ordering, non duplication and sequential delivery are requirements in the design of bridges. The guarantee is that re-ordering will not occur in frames sent between a given Source-Destination pair, at a given level of 802.1p priority. I'd note that IEEE 802.1X *does* mandate monotonically increasing value, but since the Identifier space isn't large (only 256 possible values), it isn't hard for an attacker to go through the entire space. In discussing duplication, we've talked about how a MIC check is processed; the language suggested by James requires no state change as the result of a failed MIC. So a method can be written that would discard all the bogus packets, regardless of sequence number. But it is true that requiring monotically increasing values for the Identifier would throw away 255 out of 256 possible values before the MIC check was even done. On Mon, 6 Jan 2003, Yoshihiro Ohba wrote: > In RFC2284, identifier assignment rule does not mandate the use of > monotonically increasing value, which would result in Peer side > accepting any Requests that do not have the identifier of the last > responded Request. This would make DoS attack easily by randomly > sending bogus packets to break authentication exchange. > > If EAP runs on reliable transport with stricter sequence number rule > (e.g., TCP), such a random attack is not possible since the attacker > needs to synchronize on the TCP sequence number. > > BTW, how IEEE 802 link layers provide ordering guarantees? > > Yoshihiro Ohba > From yohba@tari.toshiba.com Mon Jan 6 20:31:17 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Mon, 6 Jan 2003 15:31:17 -0500 Subject: [eap] Re: [Issue 50] lower layer ordering requirement In-Reply-To: References: <20030106181137.GA1711@catfish> Message-ID: <20030106203117.GB1711@catfish> OK, I have overlooked the strawman text for section 4.1 which already captures the behavior of discarding invalid Request. And thanks for the pointer to the book. Yoshihiro Ohba On Mon, Jan 06, 2003 at 09:29:45AM -0800, Bernard Aboba wrote: > A good reference on IEEE 802 link invariants is "The Switch Book" by Rich > Seifert. Section 2.2.1 discusses "hard" invariants (non duplication and > sequential delivery) and "soft" invariants (low error rate, high > bandwidth, low delay). > > While IEEE 802 has no sequence numbers, and does not require receivers to > check for proper ordering, non duplication and sequential delivery are > requirements in the design of bridges. The guarantee is that re-ordering > will not occur in frames sent between a given Source-Destination pair, at > a given level of 802.1p priority. > > I'd note that IEEE 802.1X *does* mandate monotonically increasing value, > but since the Identifier space isn't large (only 256 possible values), it > isn't hard for an attacker to go through the entire space. > > In discussing duplication, we've talked about how a MIC check is > processed; the language suggested by James requires no state change as the > result of a failed MIC. > > So a method can be written that would discard all > the bogus packets, regardless of sequence number. But it is true that > requiring monotically increasing values for the Identifier would throw > away 255 out of 256 possible values before the MIC check was even done. > > > On Mon, 6 Jan 2003, Yoshihiro Ohba wrote: > > > In RFC2284, identifier assignment rule does not mandate the use of > > monotonically increasing value, which would result in Peer side > > accepting any Requests that do not have the identifier of the last > > responded Request. This would make DoS attack easily by randomly > > sending bogus packets to break authentication exchange. > > > > If EAP runs on reliable transport with stricter sequence number rule > > (e.g., TCP), such a random attack is not possible since the attacker > > needs to synchronize on the TCP sequence number. > > > > BTW, how IEEE 802 link layers provide ordering guarantees? > > > > Yoshihiro Ohba > > > > From aboba@internaut.com Tue Jan 7 18:56:42 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 Jan 2003 10:56:42 -0800 (PST) Subject: [eap] Review of draft-puthenkulam-eap-binding-01.txt (fwd) Message-ID: ---------- Forwarded message ---------- Date: Fri, 3 Jan 2003 16:57:32 -0800 From: Dan Simon To: Bernard Aboba Subject: Review of draft-puthenkulam-eap-binding-01.txt My main concern with the document is that it doesn't seem to say anything about the legacy/rollback issue. If both fixed and legacy "clients (authenticators) and "servers" (verifiers) have to interoperate with each other, then a signaling mechanism *incorporated into, and detectable in, legacy instances* is necessary to allow fixed clients and servers to recognize each other and avoid a rollback. Moreover, this signaling mechanism has the additional advantage of solving the MITM problem completely, all by itself, since it can be used to distinguish tunnelled from untunnelled authentications. Now, if one side of the authentication can be assumed not to include legacy instances (e.g., all servers being upgraded simultaneously), then a carefully designed fixed protocol may suffice, without any signaling (e.g., an extra MAC is thrown into the protocol in both directions, and the fixed client will detect an attempted rollback attack when it doesn't receive the expected returned MAC from the fixed server). But if both sides must interoperate with both fixed and legacy counterparts, then signaling within the legacy protocol must be used if rollback is to be prevented. For example, if, say, a compound key derivation solution is used, then in the presence of both fixed and legacy clients and servers, some mechanism has to be found to negotiate whether to use the "pure" tunnel keys or compound keys. That mechanism needs to be such that, say, fixed clients' messages can't be fiddled with to make them look like legacy clients' messages, or the MITM can do the conversion and force the server to roll back to the legacy protocol. On the other hand, the fixed clients' messages must look enough like legacy clients' messages that legacy servers can accept and respond to them according to the legacy protocol. Hence the fixed clients' messages have to be legacy-compatible messages with an indelible "signal" in them that a fixed server will recognize as indicating a fixed client. But the presence of this signal also obviates the need for the compound key negotiation altogether; if fixed clients simply use the signal whenever not tunnelling, then a tunnelling protocol server can reject all tunnelled authentications containing the signal, thus protecting the fixed client from MITM attacks even without any other protocol change. Do you agree that the legacy problem is a real one? If so, then the solution approach needs to be changed, because the proposals presented so far don't solve it. Thoughts? Dan From aboba@internaut.com Tue Jan 7 19:16:20 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 Jan 2003 11:16:20 -0800 (PST) Subject: [eap] Re: [Issue 59] Does failed authentication required a Failure? In-Reply-To: Message-ID: > If I understand this comment, you are saying that one could fail a method > and not send a failure? Maybe this has changed, but I thought prior > conversations ruled this out. I have searched through the esteem doc and > the EAP issues, but I am having trouble finding the resolution. I've opened Issue 59 to deal with this. Issue 59: Failed authentication and EAP Failure Submitter name: Nick Petroni Submitter email address: npetroni@cs.umd.edu Date first submitted: January 7, 2003 Document: RFC2284bis-08 Comment type: T Priority: S Section: 2 Rationale/Explanation of issue: Section 2 says: [6] The sequence of authentication methods proceeds until either an authentication method fails (in which case the Authenticator sends an EAP Failure packet to the Peer) or the final authentication method completes successfully, in which case the Authenticator sends an EAP Success packet to the Peer. Is this always true? Is it possible for a failed authentication to result in a Success? Maybe this has changed, but I thought prior conversations ruled this out. I have searched through the esteem doc and the EAP issues, but I am having trouble finding the resolution. From aboba@internaut.com Tue Jan 7 19:22:42 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 Jan 2003 11:22:42 -0800 (PST) Subject: [eap] Re: [Issue 59] Does failed authentication required a Failure? In-Reply-To: Message-ID: Here's what RFC 2284 has to say about this: Section 2.2.2 If the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests) then the implementation MUST transmit an EAP packet with the Code field set to 4 (Failure). An authenticator MAY wish to issue multiple Requests before sending a Failure response in order to allow for human typing mistakes. So while multiple Requests are possible, if the authenticator cannot authenticate the Peer, RFC 2284 doesn't leave much room for interpretation -- a Failure MUST be sent. > Issue 59: Failed authentication and EAP Failure > Submitter name: Nick Petroni > Submitter email address: npetroni@cs.umd.edu > Date first submitted: January 7, 2003 > Document: RFC2284bis-08 > Comment type: T > Priority: S > Section: 2 > Rationale/Explanation of issue: > > Section 2 says: > > [6] The sequence of authentication methods proceeds until either an > authentication method fails (in which case the Authenticator sends > an EAP Failure packet to the Peer) or the final authentication > method completes successfully, in which case the Authenticator > sends an EAP Success packet to the Peer. > > Is this always true? Is it possible for a failed authentication to result > in a Success? Maybe this has changed, but I thought prior > conversations ruled this out. I have searched through the esteem doc and > the EAP issues, but I am having trouble finding the resolution. > > From james.d.carlson@east.sun.com Tue Jan 7 20:35:14 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Tue, 7 Jan 2003 15:35:14 -0500 Subject: [eap] Re: [Issue 59] Does failed authentication required a Failure? In-Reply-To: Bernard Aboba's message of 7 January 2003 11:16:20 References: Message-ID: <15899.14850.348271.195713@gargle.gargle.HOWL> Bernard Aboba writes: > [6] The sequence of authentication methods proceeds until either an > authentication method fails (in which case the Authenticator sends > an EAP Failure packet to the Peer) or the final authentication > method completes successfully, in which case the Authenticator > sends an EAP Success packet to the Peer. > > Is this always true? Is it possible for a failed authentication to result > in a Success? Maybe this has changed, but I thought prior > conversations ruled this out. I have searched through the esteem doc and > the EAP issues, but I am having trouble finding the resolution. Wouldn't this be an internal implementation detail? Whether the authentication method itself has "failed" or not is known only to the authenticator; the only information that the authenticatee has is whether it has gotten the EAP Success or EAP Failure message. I don't think the document really needs to describe internal implementation details. The most obvious implementation is one in which each method must succeed ("logical AND") in order for the authenticator to send a Success message, but since this is entirely determined by the implementation itself, I don't see why other possible choices should be excluded. To the extent that there's a state machine document, I think it ought to restrict itself to the items necessary to produce the messages on the wire, and not those that are quirks of policy. One possible way out of the problem would be to define four outputs from the method: - "Continue to next method, if any. Fail if no next method." - "Continue to next method, if any. Succeed if none left." - "Fail now." - "Succeed now." Obviously, this could get arbitrarily complex ... -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Tue Jan 7 20:37:31 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Tue, 7 Jan 2003 15:37:31 -0500 Subject: [eap] Re: [Issue 59] Does failed authentication required a Failure? In-Reply-To: Bernard Aboba's message of 7 January 2003 11:22:42 References: Message-ID: <15899.14987.722786.430141@gargle.gargle.HOWL> Bernard Aboba writes: > Here's what RFC 2284 has to say about this: > > Section 2.2.2 > > If the authenticator cannot authenticate the peer (unacceptable > Responses to one or more Requests) then the implementation MUST > transmit an EAP packet with the Code field set to 4 (Failure). An > authenticator MAY wish to issue multiple Requests before sending a > Failure response in order to allow for human typing mistakes. > > So while multiple Requests are possible, if the authenticator cannot > authenticate the Peer, RFC 2284 doesn't leave much room for interpretation > -- a Failure MUST be sent. The RFC (rightly, in my opinion) doesn't distinguish between a single method returning failure and the *authenticator* itself returning failure. The two are not necessarily the same. Once the authenticator has determined that there is failure, I agree that it must send the Failure message. The question of how it determines "failure" (whether that's the failure of some crucial method, the joint failure of multiple methods, or even the success of a "bad" method) is not specified. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Tue Jan 7 19:44:38 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 Jan 2003 11:44:38 -0800 (PST) Subject: [eap] Re: [Issue 59] Does failed authentication required a Failure? In-Reply-To: <15899.14987.722786.430141@gargle.gargle.HOWL> Message-ID: How about this: [6] The sequence of authentication methods proceeds until the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests), in which case the implementation MUST transmit an EAP packet with the Code field set to 4 (Failure). Alternatively, the authentication sequence can continue until the authenticator determines that successful authentication has occurred, in which case the authenticator MUST transmit an EAP packet with the Code field set to 3 (Success). On Tue, 7 Jan 2003, James Carlson wrote: > Bernard Aboba writes: > > Here's what RFC 2284 has to say about this: > > > > Section 2.2.2 > > > > If the authenticator cannot authenticate the peer (unacceptable > > Responses to one or more Requests) then the implementation MUST > > transmit an EAP packet with the Code field set to 4 (Failure). An > > authenticator MAY wish to issue multiple Requests before sending a > > Failure response in order to allow for human typing mistakes. > > > > So while multiple Requests are possible, if the authenticator cannot > > authenticate the Peer, RFC 2284 doesn't leave much room for interpretation > > -- a Failure MUST be sent. > > The RFC (rightly, in my opinion) doesn't distinguish between a single > method returning failure and the *authenticator* itself returning > failure. The two are not necessarily the same. Once the > authenticator has determined that there is failure, I agree that it > must send the Failure message. The question of how it determines > "failure" (whether that's the failure of some crucial method, the > joint failure of multiple methods, or even the success of a "bad" > method) is not specified. > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > From james.d.carlson@east.sun.com Tue Jan 7 21:01:55 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Tue, 7 Jan 2003 16:01:55 -0500 Subject: [eap] Re: [Issue 59] Does failed authentication required a Failure? In-Reply-To: Bernard Aboba's message of 7 January 2003 11:44:38 References: <15899.14987.722786.430141@gargle.gargle.HOWL> Message-ID: <15899.16451.657729.930973@gargle.gargle.HOWL> Bernard Aboba writes: > How about this: > > [6] The sequence of authentication methods proceeds until the > authenticator cannot authenticate the peer (unacceptable > Responses to one or more Requests), in which case the > implementation MUST transmit an EAP packet with the Code field > set to 4 (Failure). Alternatively, the authentication sequence > can continue until the authenticator determines > that successful authentication has occurred, in which case the > authenticator MUST transmit an EAP packet with the > Code field set to 3 (Success). That looks good to me. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From yohba@tari.toshiba.com Tue Jan 7 21:02:56 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Tue, 7 Jan 2003 16:02:56 -0500 Subject: [eap] Re: [Issue 59] Does failed authentication required a Failure? In-Reply-To: <15899.14850.348271.195713@gargle.gargle.HOWL> References: <15899.14850.348271.195713@gargle.gargle.HOWL> Message-ID: <20030107210256.GA1569@catfish> I agree with James. I also have an impression that text [6] is specifying too much, while one important purpose of EAP is to provide flexibility in authentication. Yoshihiro Ohba On Tue, Jan 07, 2003 at 03:35:14PM -0500, James Carlson wrote: > Bernard Aboba writes: > > [6] The sequence of authentication methods proceeds until either an > > authentication method fails (in which case the Authenticator sends > > an EAP Failure packet to the Peer) or the final authentication > > method completes successfully, in which case the Authenticator > > sends an EAP Success packet to the Peer. > > > > Is this always true? Is it possible for a failed authentication to result > > in a Success? Maybe this has changed, but I thought prior > > conversations ruled this out. I have searched through the esteem doc and > > the EAP issues, but I am having trouble finding the resolution. > > Wouldn't this be an internal implementation detail? Whether the > authentication method itself has "failed" or not is known only to the > authenticator; the only information that the authenticatee has is > whether it has gotten the EAP Success or EAP Failure message. > > I don't think the document really needs to describe internal > implementation details. The most obvious implementation is one in > which each method must succeed ("logical AND") in order for the > authenticator to send a Success message, but since this is entirely > determined by the implementation itself, I don't see why other > possible choices should be excluded. > > To the extent that there's a state machine document, I think it ought > to restrict itself to the items necessary to produce the messages on > the wire, and not those that are quirks of policy. > > One possible way out of the problem would be to define four outputs > from the method: > > - "Continue to next method, if any. Fail if no next method." > - "Continue to next method, if any. Succeed if none left." > - "Fail now." > - "Succeed now." > > Obviously, this could get arbitrarily complex ... > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Tue Jan 7 20:27:36 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 Jan 2003 12:27:36 -0800 (PST) Subject: [eap] Issue 60: Ordering guarantees Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: January 7, 2003 Document: RFC2284bis-08 Comment type: T Priority: S Section: 3.1 Rationale/Explanation of issue: As noted by James Carlson, there is an implicit ordering requirement in EAP due to its PPP heritage. This is not recognized in the current draft. Change Section 3.1 from: "[4] Possible reordering. EAP provides its own mechanisms to detect reordering and so does not assume that the lower layer provides ordering guarantees. EAP is a "lockstep" protocol, so that the Authenticator MUST NOT send a new Request until a Response is received to an outstanding Request. Since the Peer should not expect a new Request until it has sent a Response, if it receives a new Request with a different Identifier before sending a Response to the outstanding Request, the new Request MUST be silently discarded. Similarly, if the Authenticator receives a Response with an Identifier that does not match the Identifier in the outstanding Request, the Response MUST be silently discarded." To: "Ordering guarantees. EAP was originally defined to run on PPP and [RFC1661] Section 1 has an ordering requirement: "The Point-to-Point Protocol is designed for simple links which transport packets between two peers. These links provide full-duplex simultaneous bi-directional operation, and are assumed to deliver packets in order." As a result, any other lower lower transport for EAP MUST preserve ordering between a source and destination, at a given priority level (the ordering guarantee provided by IEEE 802)." From hzhou@cisco.com Tue Jan 7 21:46:46 2003 From: hzhou@cisco.com (Hao Zhou) Date: Tue, 7 Jan 2003 16:46:46 -0500 Subject: [eap] Re: [Issue 59] Does failed authentication required a Failure? References: <15899.14987.722786.430141@gargle.gargle.HOWL> Message-ID: <014a01c2b696$46dd40d0$a4c16540@amer.cisco.com> I agree. The current 2284bis doesn't distinguish FAILURE and SUCCESS from individual method and the final one from Authenticator, which makes it hard to support sequence of EAP methods. I assume it is preferred that the existing EAP methods will require no change to be supported for sequences. They currently send out EAP-SUCCESS and EAP-FAILURE by themselves. On the other end, authenticator sometimes send out "canned " SUCCESS and FAILURE messages after receiving Accept/Reject from the server [IEEE8021X]. Obviously, we need to distinguish those two types of success and failure to continue the sequence. I wonder if extending the EAP-SUCCESS and EAP-FAILURE message to include a EAP method type would solve this. There would be two types of EAP-SUCCESS and FAILURE: 1. The current EAP-SUCCESS and EAP-FAILURE with no data to indicate final success and failure; 2. The extended EAP-SUCCESS and EAP-FAILURE include extra eap method type to indicate individual eap method success and failure. Without requiring changes in the existing individual methods to be used in the sequence, they would keep sending out EAP-SUCCESS and EAP-FAILURE messages. The EAP layer would append the EAP type to the success and failure packets if the individual methods are chained. Otherwise, send the message out without modifying it, which indicates final success and failure. In addition to above, an acknowledgment of receiving the success and failure message might be needed to support sequence. For example, after EAP method 1 received EAP-SUCCESS, it sends out acknowledge to the backend server, so backend server can start EAP method 2. This is due to unreliable transmission of lower layer, success or failure message might not reach the client. Server should not start method 2 until peer acknowledges that it finishes with method 1. ----- Original Message ----- From: "James Carlson" To: "Bernard Aboba" Cc: Sent: Tuesday, January 07, 2003 3:37 PM Subject: Re: [eap] Re: [Issue 59] Does failed authentication required a Failure? > Bernard Aboba writes: > > Here's what RFC 2284 has to say about this: > > > > Section 2.2.2 > > > > If the authenticator cannot authenticate the peer (unacceptable > > Responses to one or more Requests) then the implementation MUST > > transmit an EAP packet with the Code field set to 4 (Failure). An > > authenticator MAY wish to issue multiple Requests before sending a > > Failure response in order to allow for human typing mistakes. > > > > So while multiple Requests are possible, if the authenticator cannot > > authenticate the Peer, RFC 2284 doesn't leave much room for interpretation > > -- a Failure MUST be sent. > > The RFC (rightly, in my opinion) doesn't distinguish between a single > method returning failure and the *authenticator* itself returning > failure. The two are not necessarily the same. Once the > authenticator has determined that there is failure, I agree that it > must send the Failure message. The question of how it determines > "failure" (whether that's the failure of some crucial method, the > joint failure of multiple methods, or even the success of a "bad" > method) is not specified. > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Tue Jan 7 20:48:54 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 Jan 2003 12:48:54 -0800 (PST) Subject: [eap] Re: [Issue 59] Does failed authentication required a Failure? In-Reply-To: <014a01c2b696$46dd40d0$a4c16540@amer.cisco.com> Message-ID: Filed as Issue 61: Support for EAP Sequences. On Tue, 7 Jan 2003, Hao Zhou wrote: > I agree. > > The current 2284bis doesn't distinguish FAILURE and SUCCESS from individual > method and the final one from Authenticator, which makes it hard to support > sequence of EAP methods. > > I assume it is preferred that the existing EAP methods will require no > change to be supported for sequences. They currently send out EAP-SUCCESS > and EAP-FAILURE by themselves. On the other end, authenticator sometimes > send out "canned " SUCCESS and FAILURE messages after receiving > Accept/Reject from the server [IEEE8021X]. Obviously, we need to distinguish > those two types of success and failure to continue the sequence. > > I wonder if extending the EAP-SUCCESS and EAP-FAILURE message to include a > EAP method type would solve this. > > There would be two types of EAP-SUCCESS and FAILURE: > 1. The current EAP-SUCCESS and EAP-FAILURE with no data to indicate final > success and failure; > 2. The extended EAP-SUCCESS and EAP-FAILURE include extra eap method type to > indicate individual eap method success and failure. Without requiring > changes in the existing individual methods to be used in the sequence, they > would keep sending out EAP-SUCCESS and EAP-FAILURE messages. The EAP layer > would append the EAP type to the success and failure packets if the > individual methods are chained. Otherwise, send the message out without > modifying it, which indicates final success and failure. > > In addition to above, an acknowledgment of receiving the success and failure > message might be needed to support sequence. For example, after EAP method 1 > received EAP-SUCCESS, it sends out acknowledge to the backend server, so > backend server can start EAP method 2. This is due to unreliable > transmission of lower layer, success or failure message might not reach the > client. Server should not start method 2 until peer acknowledges that it > finishes with method 1. > > ----- Original Message ----- > From: "James Carlson" > To: "Bernard Aboba" > Cc: > Sent: Tuesday, January 07, 2003 3:37 PM > Subject: Re: [eap] Re: [Issue 59] Does failed authentication required a > Failure? > > > > Bernard Aboba writes: > > > Here's what RFC 2284 has to say about this: > > > > > > Section 2.2.2 > > > > > > If the authenticator cannot authenticate the peer (unacceptable > > > Responses to one or more Requests) then the implementation MUST > > > transmit an EAP packet with the Code field set to 4 (Failure). An > > > authenticator MAY wish to issue multiple Requests before sending a > > > Failure response in order to allow for human typing mistakes. > > > > > > So while multiple Requests are possible, if the authenticator cannot > > > authenticate the Peer, RFC 2284 doesn't leave much room for > interpretation > > > -- a Failure MUST be sent. > > > > The RFC (rightly, in my opinion) doesn't distinguish between a single > > method returning failure and the *authenticator* itself returning > > failure. The two are not necessarily the same. Once the > > authenticator has determined that there is failure, I agree that it > > must send the Failure message. The question of how it determines > > "failure" (whether that's the failure of some crucial method, the > > joint failure of multiple methods, or even the success of a "bad" > > method) is not specified. > > > > -- > > James Carlson, Solaris Networking > > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Tue Jan 7 21:03:26 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 Jan 2003 13:03:26 -0800 (PST) Subject: [eap] Re: [Issue 61] Support for EAP Sequences In-Reply-To: <014a01c2b696$46dd40d0$a4c16540@amer.cisco.com> Message-ID: > The current 2284bis doesn't distinguish FAILURE and SUCCESS from individual > method and the final one from Authenticator, which makes it hard to support > sequence of EAP methods. I think it's fair to say that RFC 2284 didn't anticipate use of sequences at all, other than Identity followed by a method. > I assume it is preferred that the existing EAP methods will require no > change to be supported for sequences. They currently send out EAP-SUCCESS > and EAP-FAILURE by themselves. This appears to be implementation specific. In some implementations they are sent by the EAP layer, not by the method (Windows is an example). > On the other end, authenticator sometimes > send out "canned " SUCCESS and FAILURE messages after receiving > Accept/Reject from the server [IEEE8021X]. Support for "canned" Success and Failure messages has been removed from IEEE 802.1aa, for the most part. > Obviously, we need to distinguish > those two types of success and failure to continue the sequence. Are you saying that the current RFC 2284bis text would break an existing implementation? One of the mandates of the EAP WG is to retain backwards compatibility if at all possible, particularly if the change doesn't represent a "grey area" of RFC 2284. > There would be two types of EAP-SUCCESS and FAILURE: > 1. The current EAP-SUCCESS and EAP-FAILURE with no data to indicate final > success and failure; > 2. The extended EAP-SUCCESS and EAP-FAILURE include extra eap method type to > indicate individual eap method success and failure. Without requiring > changes in the existing individual methods to be used in the sequence, they > would keep sending out EAP-SUCCESS and EAP-FAILURE messages. The EAP layer > would append the EAP type to the success and failure packets if the > individual methods are chained. Otherwise, send the message out without > modifying it, which indicates final success and failure. How are the new messages to be sent? As new codes? A new EAP type? How will backwards compatibility be maintained? From james.d.carlson@east.sun.com Tue Jan 7 22:26:58 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Tue, 7 Jan 2003 17:26:58 -0500 Subject: [eap] Re: [Issue 61] Support for EAP Sequences In-Reply-To: Bernard Aboba's message of 7 January 2003 13:03:26 References: <014a01c2b696$46dd40d0$a4c16540@amer.cisco.com> Message-ID: <15899.21554.770583.678905@gargle.gargle.HOWL> Bernard Aboba writes: > > The current 2284bis doesn't distinguish FAILURE and SUCCESS from individual > > method and the final one from Authenticator, which makes it hard to support > > sequence of EAP methods. > > I think it's fair to say that RFC 2284 didn't anticipate use of sequences > at all, other than Identity followed by a method. That's only roughly fair. RFC 2284 did anticipate the use, but said that it probably wasn't a good idea on the balance: In practice, within or associated with each PPP server, it is not anticipated that a particular named user would be authenticated by multiple methods. This would make the user vulnerable to attacks which negotiate the least secure method from among a set (such as PAP rather than EAP). Instead, for each named user there should be an indication of exactly one method used to authenticate that user name. If a user needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. Is suspect that fear need not be true for an implementation that was exceedingly careful (that is, one that ran each authentication method regardless of the intermediate result of each, and then sent Success after *all* had been run only if all had passed). But given the tendency for mistakes, and the likely uselessness of the "feature," it seems reasonable to suggest that it's not a good idea. > > I assume it is preferred that the existing EAP methods will require no > > change to be supported for sequences. They currently send out EAP-SUCCESS > > and EAP-FAILURE by themselves. > > This appears to be implementation specific. In some implementations they > are sent by the EAP layer, not by the method (Windows is an example). As long as the EAP implementation sends out EAP Success or EAP Failure when it has completely finished its authentication (rather than part way through), it doesn't matter how it's implemented internally. > > Obviously, we need to distinguish > > those two types of success and failure to continue the sequence. > > Are you saying that the current RFC 2284bis text would break an existing > implementation? One of the mandates of the EAP WG is to retain backwards > compatibility if at all possible, particularly if the change doesn't > represent a "grey area" of RFC 2284. Why is it obvious that this is needed at all? What would the authenticatee do if told the equivalent of "you've passed two hurdles; now just one more to go?" If nothing else, this "method success" message would clearly present serious security problems, since it would allow divide and conquer. It also doesn't seem to help in the slightest because nobody has identified a use for them, other than perhaps as signaling *entirely* internal to an implementation with a particular EAP+method architecture. > How are the new messages to be sent? As new codes? A new EAP type? How > will backwards compatibility be maintained? And what would the peer do with them? They seem to be the protocol equivalent of having the peer say, "yes, yes, I see; do go on." -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Tue Jan 7 22:25:38 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 Jan 2003 14:25:38 -0800 (PST) Subject: [eap] Re: [Issue 61] Support for EAP Sequences In-Reply-To: <15899.21554.770583.678905@gargle.gargle.HOWL> Message-ID: > That's only roughly fair. RFC 2284 did anticipate the use, but said > that it probably wasn't a good idea on the balance: > > In practice, within or associated with each PPP server, it is not > anticipated that a particular named user would be authenticated by > multiple methods. This would make the user vulnerable to attacks > which negotiate the least secure method from among a set (such as PAP > rather than EAP). Instead, for each named user there should be an > indication of exactly one method used to authenticate that user name. > If a user needs to make use of different authentication methods under > different circumstances, then distinct identities SHOULD be employed, > each of which identifies exactly one authentication method. The question has been whether this referred to sequences, or merely to choices in the use of a single authentication method. > Is suspect that fear need not be true for an implementation that was > exceedingly careful (that is, one that ran each authentication method > regardless of the intermediate result of each, and then sent Success > after *all* had been run only if all had passed). But given the > tendency for mistakes, and the likely uselessness of the "feature," it > seems reasonable to suggest that it's not a good idea. So you're suggesting that sequences SHOULD NOT be used? > As long as the EAP implementation sends out EAP Success or EAP Failure > when it has completely finished its authentication (rather than part > way through), it doesn't matter how it's implemented internally. Yes. > > > Obviously, we need to distinguish > > > those two types of success and failure to continue the sequence. > > Why is it obvious that this is needed at all? It's not obvious to me :) From jrv@umich.edu Wed Jan 8 00:18:44 2003 From: jrv@umich.edu (jrv@umich.edu) Date: Tue, 7 Jan 2003 19:18:44 -0500 Subject: [eap] Re: [Issue 61] Support for EAP Sequences In-Reply-To: <15899.21554.770583.678905@gargle.gargle.HOWL> References: <014a01c2b696$46dd40d0$a4c16540@amer.cisco.com> <15899.21554.770583.678905@gargle.gargle.HOWL> Message-ID: <1041985124.3e1b6e640e442@floatingbottle.mail.umich.edu> Quoting James Carlson : > Bernard Aboba writes: > > > The current 2284bis doesn't distinguish FAILURE and SUCCESS from > individual > > > method and the final one from Authenticator, which makes it hard to > support > > > sequence of EAP methods. > > > > I think it's fair to say that RFC 2284 didn't anticipate use of sequences > > at all, other than Identity followed by a method. > > That's only roughly fair. RFC 2284 did anticipate the use, but said > that it probably wasn't a good idea on the balance: > > In practice, within or associated with each PPP server, it is not > anticipated that a particular named user would be authenticated by > multiple methods. This would make the user vulnerable to attacks > which negotiate the least secure method from among a set (such as PAP > rather than EAP). Instead, for each named user there should be an > indication of exactly one method used to authenticate that user name. > If a user needs to make use of different authentication methods under > different circumstances, then distinct identities SHOULD be employed, > each of which identifies exactly one authentication method. > > Is suspect that fear need not be true for an implementation that was > exceedingly careful (that is, one that ran each authentication method > regardless of the intermediate result of each, and then sent Success > after *all* had been run only if all had passed). But given the > tendency for mistakes, and the likely uselessness of the "feature," it > seems reasonable to suggest that it's not a good idea. > I think the idea of sequences is useful when doing something in addition to authentication. E.g. a method that negotiates QOS. Then the negotiation for authenication method can be done, and if that method succeeds, an attempt to do the QOS method can be made. If the peer accepts the method, it will get to negotiate - if not it gets some default settings. This concept was at least part of the thinking at the time the initial EAP draft was written. > > > I assume it is preferred that the existing EAP methods will require no > > > change to be supported for sequences. They currently send out > EAP-SUCCESS > > > and EAP-FAILURE by themselves. > > > > This appears to be implementation specific. In some implementations they > > are sent by the EAP layer, not by the method (Windows is an example). > > As long as the EAP implementation sends out EAP Success or EAP Failure > when it has completely finished its authentication (rather than part > way through), it doesn't matter how it's implemented internally. > seems true to me > > > Obviously, we need to distinguish > > > those two types of success and failure to continue the sequence. > > > > Are you saying that the current RFC 2284bis text would break an existing > > implementation? One of the mandates of the EAP WG is to retain backwards > > compatibility if at all possible, particularly if the change doesn't > > represent a "grey area" of RFC 2284. > > Why is it obvious that this is needed at all? > > What would the authenticatee do if told the equivalent of "you've > passed two hurdles; now just one more to go?" If nothing else, this > "method success" message would clearly present serious security > problems, since it would allow divide and conquer. It also doesn't > seem to help in the slightest because nobody has identified a use for > them, other than perhaps as signaling *entirely* internal to an > implementation with a particular EAP+method architecture. > > > How are the new messages to be sent? As new codes? A new EAP type? How > > will backwards compatibility be maintained? > > And what would the peer do with them? They seem to be the protocol > equivalent of having the peer say, "yes, yes, I see; do go on." > I agree again. I think a success or failure should end a sequence. If methods are implemented to send success or failure, then these implementations can't do method sequences for the reasons that James Carlson suggests. John Vollbrecht From aboba@internaut.com Wed Jan 8 02:38:21 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 Jan 2003 18:38:21 -0800 (PST) Subject: [eap] Proposed resolution to Issue 23: Reject Message-ID: Issue 23 relates to the contents of the identity request payload. In RFC 2284, Section 3.1, it says: "An optional displayable message MAY be included to prompt the peer in the case where there expectation of interaction with a user." and "optionally, the failure MAY be indicated within the message of the new Identity Request itself" I read this as indicating that the primary purpose of the Identity Request is for user display, and that it is treated as undistinguished octets, rather than interpretted by the protocol itself. My recommendation is therefore that the proposed change be REJECTED. Comments welcome: Further information on the issue and subsequent discussion can be found at: http://www.drizzle.com/~aboba/EAP/eapissues.html ================================================================== Issue 23: Contents of Identity Request Payload 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: 5.1 Rationale/Explanation of issue: Section 5.1 page 13 describes the Identity Type thusly: The Identity Type is used to query the identity of the peer. Generally, the Authenticator will issue this as the initial Request. An optional displayable message MAY be included to prompt the Peer in the case where there expectation of interaction with a user. A Response MUST be sent to this Request with a Type of 1 (Identity). This language is good as far as it goes, but I wonder if more formal rules should be specified to enable the more mobile enviroments where EAP is being applied? What I have in mind is that it is likely that many (most?) users/devices will have different sets of credentials for many of the security domains they visit. Each of these credentials will assign to the user/device a different artificial and arbitrary "identity". In the wireless roaming case, it is likely that a user will sometimes cross domain boundaries without even knowing it, so the commonly cited industry goal of "seamless" roaming would imply that the Identity Request from the Authenticator should provide some hint as to which "identity" it is expecting, i.e., which domain is in use. While the cited language above does not preclude this, it does not specify any interoperable way of accomplishing this goal. The obvious suggestion would be to insert the domain name portion of the NAI of the Authenticator in some standard way into the Identity Request. The Peer could parse and then attempt to map this to the credentials it should present to this particular Authenticator. From aboba@internaut.com Wed Jan 8 02:52:32 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 Jan 2003 18:52:32 -0800 (PST) Subject: [eap] Proposed resolution to Issue 54: Accept Message-ID: Issue 54, listed below, proposes to clarify the specification so as to make clear that a NAK with no Type is unacceptable. My proposal is that this change is accepted. ================================= Issue 54: Problem with NAK type Submitter name: James Carlson Submitter email address: james.d.carlson@sun.com. Date first submitted: January 2, 2003 Document: RFC2284bis Comment type: T Priority: 1 Section: 5.3 Rationale/Explanation of issue: This also breaks RFC 2284 compatibility. In the original RFC, the type field was *required*. Systems implemented to RFC 2284 will *discard* bogus Nak messages that don't have a suggested type field. Instead, if "Nak with no alternative" is required (I don't think it is), then I suggest either a reserved value (e.g., 0) or (better yet) using the value 1 (Identity) to tell the peer to start over. Requested change: from: The Nak Type is valid only in Response messages. It is sent in reply to a method proposal (the initial EAP Request for a given Type) where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains zero or one authentication Type desired by the Peer. A Nak with no authentication Type indicates that the Peer does not wish to authenticate using the proposed method but is not proposing an alternative. to: The Nak Type is valid only in Response messages. It is sent in reply to a method proposal (the initial EAP Request for a given Type) where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains a single octet authentication Type desired by the Peer. This value may be 1 (Identity) to indicate that the sender has no viable alternatives, or that the authentication attempt should be restarted. From aboba@internaut.com Wed Jan 8 05:52:35 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 7 Jan 2003 21:52:35 -0800 (PST) Subject: [eap] Proposed Resolution of Issue 57 Message-ID: Issue 51 also deals with the role-reversal issue. I believe that the fix adopted for that issue also resolves parts of Issue 57. The section cited on page 6 requires a complete rewrite, so the best thing to do is probably to work on that rather than trying to patch up the current text. Note that RFC 2284bis deals only with the protocol run between the authenticator and peer; security between the authenticator and authentication server is the subject of RFC 2869bis and Diameter EAP. Here is the proposed text for section 7.8: Change: "In EAP there is no requirement that authentication be full duplex or that the same protocol be used in both directions. It is perfectly acceptable for different protocols to be used in each direction. This will, of course, depend on the specific protocols negotiated. However, in general, completing a single, mutual authentication is preferable to two one-way authentications, one in each direction." To: "In EAP there is no requirement that authentication be full duplex or that the same protocol be used in both directions. It is perfectly acceptable for different protocols to be used in each direction. This will, of course, depend on the specific protocols negotiated. However, in general, completing a single, mutual authentication is preferable to two one-way authentications, one in each direction. This is because separate authentications that are not bound cryptographically to demonstrate they are part of the same session are subject to man-in-the-middle attacks." ----------------------------------------------- Issue 57: Mutual vs. bi-direction authentication Submitter name: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: January 3, 2003 Document: RFC2284bis-08 Comment type: T Priority: S Section: 2, pp. 5 Rationale/Explanation of issue: Major Issues: Page 5 includes the text: 7. Since EAP is a Peer-to-Peer protocol, after authentication in one direction is complete, the direction of authentication MAY reverse, with the endpoint previously serving as the Authenticator assuming the Peer role, and the former Peer now taking on the Authenticator role. As with the original conversation, the reversal is signaled by the (new) Authenticator sending a Request. Support for bi-directional authentication requires that each endpoint implement both the Peer and Authenticator roles. and page 31 continues in this theme with In EAP there is no requirement that authentication be full duplex or that the same protocol be used in both directions. It is perfectly acceptable for different protocols to be used in each direction. This will, of course, depend on the specific protocols negotiated. However, in general, completing a single, mutual authentication is preferable to two one-way authentications, one in each direction. These two texts appear to have been written under the misapprehension that two unrelated unilateral authentications glued together in arbitrary undefined ways can result in multual authentication. It does not and cannot; in general the two unilateral authentications remain simply unilateral authentications. It is in general not feasible to defeat man-in-the-middle attacks--and hence in general it is not feasible to rely on the unilateral authentication for any useful assertion--without relating the two cryptographically in very specific ways. Allowing reversal of roles is a recipe for disaster unless very great care is taken to relate the two authentications, and there is no evidence such a task is even feasible for all but a few legacy unilateral authentication mechanisms. We have already seen a variant of this problem with PEAP and TTLS, both of which are much stronger than the construction this text seems to sanction. To correct this problems, I suggest adding text at the end of that cited on page 5 such as "In environments where man-in-the-middle attacks are possible, at least one of the two concrete Authentications MUST rely on an algorithm that performs a mutual authentication. This obviates the need for reversing the roles of Authenticator and Peer." To the end of the text cited from page 31, as text something like "This is because using separate authentications that are not bound cryptographically to demonstrate they are part of the same session are always subject to man-in-the-middle attacks." Or better yet, explicitly ban role reversal of the kind indicated here. That is simpler, and simplicity almost always leads to better security. Page 6: There is a sentence that begins Unless protected by an underlying link layer ciphersuite In the case where the Authentication Server is not the Authenticator, this suffers from a similar problem. Relying on a link layer ciphersuite between the Authenticator and the Peer to protect messages between the Authentication Server and the Peer is subject to man-in-the-middle abuses; if the protections are not applied end-to-end, then they cannot necessarily be effective. I think what is really intended is that the EAP messages be protected by a ciphersuite associated with the concrete authentication method, and the text should be updated to reflect this. -- Jesse From aboba@internaut.com Wed Jan 8 11:34:13 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 8 Jan 2003 03:34:13 -0800 (PST) Subject: [eap] Proposed Resolution to Issue 58: Accept Message-ID: Here are the proposed changes to resolve Issue 58: Miscellaneous -08 NITs: "protocol" to "framework" in the Abstract and Section 1. "error" to "event" in Section 1.2 under "silent discard" Sentence involving "and and" has been struck due to rewrite of that section. Change "IEEE 802" to "IEEE 802 wired media" throughout the document, where wired LANs are intended to be referenced (many places). Text involving "application specific" is removed in -09, due to rewrite of vendor specific section. Add the following text at the end of section 7.11: However, some general guidelines can be provided: 1. Master Session Keys and Transient Session Keys MUST be a fresh. Otherwise it is infeasible to detect messages replayed from prior sessions. 2. The Master Key is for use only by the EAP authenticator and peer and MUST NOT be exported by the EAP method or provided to a third party. 3. Session keys used for different purposes MUST be cryptographically independent from each other so that if an attacker obtains one of the session keys, it will not have gained information useful in determining other ones. 4. There MUST be a way to determine whether transient session keys belong to this or to some other session. 5. It is important that MSKs derived by EAP methods be bound to the peers as well as to the authentication method, so as to avoid a man-in-the-middle attack (see Section 7.5). ---------------------------------------------------------------- Issue 58: Miscellaneous -08 NITs Submitter name: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: January 3, 2003 Document: RFC2284bis-08 Comment type: T,E Priority: S Section: Various Rationale/Explanation of issue: Pages 1 (Abstract), 3 (Introduction): The text still speaks of EAP as an "authentication protocol". It is not since in and of itself it performs no authentication. How about "authentication protocol transport"? Page 3: In the definition of "Silently Discard, a sentence begins: The implementation SHOULD provide the capability of logging the error There is an implicit assumption in this sentence that silently discard occurs only in response to an error. This should be made explicit or else the assumption removed. Page 16: The phrase "and and" appears. Pages 20, 21, and 22 use the phrase "IEEE 802" as a synonym for "IEEE 802 wired networks" Please clean this up. Page 23 has the language "application specific" which is not wrong per se but does appear to be misleading. Can we replace this with "vendor specific", since that is what the text is talking about? Page 32 Clause 7.11 says that This specification does not provide guidance on how EAP methods are to derive keys. I think it is possible to give some general but practical guidelines: a. the key MUST be a fresh, never-before used key, because otherwise it is in general infeasible to use the key to detect messages replayed from prior sessions. b. there MUST be some way to name the key, to determine whether it belongs to this or to some other session. c. the key is an authorization token (use of the key demonstrates authorization to access the channel), so the relation of the key to the authentication that authorized this key MUST be made explicit to understand the security relationship of the key to the EAP method. d. in the case where more than authentication method is used (think of PEAP or TTLS, not the approach complained about on page 5 and 31) and more than one method derives keys, then the method description MUST indicate which keys are distributed for use by the Authenticator and Peer, and how. For instance, in the PEAP/TTLS case, the key derived by the inner method could be combined using a pseudo-random function with the TLS key to cryptographically bind the inner and outer keys, and this combined key would be used by the Authenticator and Peer. I would also like to see the following two additional guidelines, but they may be more controversial, so I will not insist: e. When the purpose of the authentication is to authorize use of the data link channel between the Peer and the Authenticator, to understand its security one needs to know how the derived key is bound to the channel, so that (ab)use of it in other contexts can be detected. It would be nice if the method could (SHOULD?) provide guidance on this issue, e.g., specify the assumptions it makes about how this binding occurs. f. When the Authenticator and Authentication Server are not the same party, one needs to understand how the key is distributed to the Authenticator (and to the Peer, if it needs to be transported) to understand the security properties of the key. It would be nice if the method could (SHOULD?) provide guidance about this, e.g., specify the assumptions it makes about how key distribution is effected. -- Jesse From jesse.walker@intel.com Wed Jan 8 14:56:12 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Wed, 8 Jan 2003 06:56:12 -0800 Subject: [eap] Proposed Resolution of Issue 57 Message-ID: Bernard, I am satisfied with the suggested language. -- Jesse > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, January 07, 2003 9:53 PM > To: eap@frascone.com > Subject: [eap] Proposed Resolution of Issue 57 > > > Issue 51 also deals with the role-reversal issue. > I believe that the fix adopted for that issue also > resolves parts of Issue 57. > > The section cited on page 6 requires a complete rewrite, > so the best thing to do is probably to work on that rather > than trying to patch up the current text. Note that RFC 2284bis > deals only with the protocol run between the authenticator and > peer; security between the authenticator and authentication > server is the subject of RFC 2869bis and Diameter EAP. > > Here is the proposed text for section 7.8: > > Change: > > "In EAP there is no requirement that authentication be full duplex or > that the same protocol be used in both directions. It is perfectly > acceptable for different protocols to be used in each direction. This > will, of course, depend on the specific protocols negotiated. However, > in general, completing a single, mutual authentication is > preferable to > two one-way authentications, one in each direction." > > To: > > "In EAP there is no requirement that authentication be full duplex or > that the same protocol be used in both directions. It is perfectly > acceptable for different protocols to be used in each direction. This > will, of course, depend on the specific protocols negotiated. However, > in general, completing a single, mutual authentication is > preferable to > two one-way authentications, one in each direction. > This is because separate authentications that are not > bound cryptographically to demonstrate they are part of the > same session are subject to man-in-the-middle attacks." > > ----------------------------------------------- > Issue 57: Mutual vs. bi-direction authentication > Submitter name: Jesse Walker > Submitter email address: jesse.walker@intel.com > Date first submitted: January 3, 2003 > Document: RFC2284bis-08 > Comment type: T > Priority: S > Section: 2, pp. 5 > Rationale/Explanation of issue: > Major Issues: Page 5 includes the text: > > 7. Since EAP is a Peer-to-Peer protocol, after > authentication in one direction is complete, the direction > of authentication MAY reverse, with the endpoint > previously serving as the Authenticator assuming the Peer > role, and the former Peer now taking on the Authenticator > role. As with the original conversation, the reversal is > signaled by the (new) Authenticator sending a Request. > Support for bi-directional authentication requires that > each endpoint implement both the Peer and Authenticator > roles. > > and page 31 continues in this theme with > > In EAP there is no requirement that authentication be full > duplex or that the same protocol be used in both > directions. It is perfectly acceptable for different > protocols to be used in each direction. This will, of > course, depend on the specific protocols negotiated. > However, in general, completing a single, mutual > authentication is preferable to two one-way > authentications, one in each direction. > > These two texts appear to have been written under the > misapprehension that > two unrelated unilateral authentications glued together in arbitrary > undefined ways can result in multual authentication. It does not and > cannot; in general the two unilateral authentications remain simply > unilateral authentications. It is in general not feasible to defeat > man-in-the-middle attacks--and hence in general it is not > feasible to rely > on the unilateral authentication for any useful assertion--without > relating the two cryptographically in very specific ways. Allowing > reversal of roles is a recipe for disaster unless very great > care is taken > to relate the two > authentications, and there is no evidence such a task is even > feasible for > all but a few legacy unilateral authentication mechanisms. We > have already > seen a variant of this problem with PEAP and TTLS, both of > which are much > stronger than the construction this text seems to sanction. > > To correct this problems, I suggest adding text at the end of > that cited > on > page 5 such as "In environments where man-in-the-middle attacks are > possible, at least one of the two concrete Authentications > MUST rely on an > algorithm that performs a mutual authentication. This > obviates the need > for > reversing the roles of Authenticator and Peer." To the end of the text > cited > from page 31, as text something like "This is because using separate > authentications that are not bound cryptographically to > demonstrate they > are > part of the same session are always subject to > man-in-the-middle attacks." > Or better yet, explicitly ban role reversal of the kind > indicated here. > That > is simpler, and simplicity almost always leads to better security. > > Page 6: There is a sentence that begins > > Unless protected by an underlying link layer ciphersuite > > In the case where the Authentication Server is not the > Authenticator, this > suffers from a similar problem. Relying on a link layer ciphersuite > between > the Authenticator and the Peer to protect messages between the > Authentication Server and the Peer is subject to > man-in-the-middle abuses; > if the protections are not applied end-to-end, then they cannot > necessarily be effective. I think what is really intended is > that the EAP > messages be > protected by a ciphersuite associated with the concrete authentication > method, and the text should be updated to reflect this. > -- Jesse > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jesse.walker@intel.com Wed Jan 8 14:58:06 2003 From: jesse.walker@intel.com (Walker, Jesse) Date: Wed, 8 Jan 2003 06:58:06 -0800 Subject: [eap] Proposed Resolution to Issue 58: Accept Message-ID: Bernard, These changes are satisfactory to me. Thanks. -- Jesse > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Wednesday, January 08, 2003 3:34 AM > To: eap@frascone.com > Subject: [eap] Proposed Resolution to Issue 58: Accept > > > Here are the proposed changes to resolve Issue 58: > Miscellaneous -08 NITs: > > "protocol" to "framework" in the Abstract and Section 1. > > "error" to "event" in Section 1.2 under "silent discard" > > Sentence involving "and and" has been struck due to rewrite > of that section. > > Change "IEEE 802" to "IEEE 802 wired media" throughout the > document, where wired LANs are intended to be referenced > (many places). > > Text involving "application specific" is removed in -09, due > to rewrite of vendor specific section. > > Add the following text at the end of section 7.11: > > However, some general guidelines can be provided: > > 1. Master Session Keys and Transient Session Keys MUST be a fresh. > Otherwise it is infeasible to detect messages replayed from prior > sessions. > > 2. The Master Key is for use only by the EAP authenticator > and peer and > MUST NOT be exported by the EAP method or provided to a third party. > > 3. Session keys used for different purposes MUST be cryptographically > independent from each other so that if an attacker obtains > one of the session keys, it will not have gained information useful > in determining other ones. > > 4. There MUST be a way to determine whether transient session > keys belong > to this or to some other session. > > 5. It is important that MSKs derived by EAP methods be bound to the > peers as well as to the authentication method, so as to avoid a > man-in-the-middle attack (see Section 7.5). > > ---------------------------------------------------------------- > Issue 58: Miscellaneous -08 NITs > Submitter name: Jesse Walker > Submitter email address: jesse.walker@intel.com > Date first submitted: January 3, 2003 > Document: RFC2284bis-08 > Comment type: T,E > Priority: S > Section: Various > Rationale/Explanation of issue: > Pages 1 (Abstract), 3 (Introduction): The text still speaks > of EAP as an > "authentication protocol". It is not since in and of itself > it performs no > authentication. How about "authentication protocol transport"? > > Page 3: In the definition of "Silently Discard, a sentence begins: > > The implementation SHOULD provide the capability of logging > the error > > There is an implicit assumption in this sentence that silently discard > occurs only in response to an error. This should be made > explicit or else > the assumption removed. > > Page 16: The phrase "and and" appears. > Pages 20, 21, and 22 use the phrase "IEEE 802" as a synonym > for "IEEE 802 > wired networks" Please clean this up. > > Page 23 has the language "application specific" which is not > wrong per se > but does appear to be misleading. Can we replace this with "vendor > specific", since that is what the text is talking about? > > Page 32 Clause 7.11 says that > > This specification does not provide guidance on how EAP > methods are to derive keys. > > I think it is possible to give some general but practical guidelines: > > a. the key MUST be a fresh, never-before used key, because > otherwise it is > in general infeasible to use the key to detect messages replayed from > prior sessions. > > b. there MUST be some way to name the key, to determine > whether it belongs > to this or to some other session. > > c. the key is an authorization token (use of the key demonstrates > authorization to access the channel), so the relation of the > key to the > authentication that authorized this key MUST be made explicit to > understand the security relationship of the key to the EAP method. > > d. in the case where more than authentication method is used (think of > PEAP or TTLS, not the approach complained about on page 5 and > 31) and more > than one method derives keys, then the method description > MUST indicate > which keys are distributed for use by the Authenticator and > Peer, and how. > For instance, in the PEAP/TTLS case, the key derived by the > inner method > could be combined using a pseudo-random function with the TLS key to > cryptographically bind the inner and outer keys, and this combined key > would be used by the Authenticator and Peer. > > I would also like to see the following two additional > guidelines, but they > may be more controversial, so I will not insist: > > e. When the purpose of the authentication is to authorize use > of the data > link channel between the Peer and the Authenticator, to understand its > security one needs to know how the derived key is bound to > the channel, so > that (ab)use of it in other contexts can be detected. It > would be nice if > the method could (SHOULD?) provide guidance on this issue, > e.g., specify > the assumptions it makes about how this binding occurs. > > f. When the Authenticator and Authentication Server are not the same > party, one needs to understand how the key is distributed to the > Authenticator (and to the Peer, if it needs to be transported) to > understand the security properties of the key. It would be nice if the > method could (SHOULD?) provide guidance about this, e.g., specify the > assumptions it makes about how key distribution is effected. > > -- Jesse > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Wed Jan 8 14:52:19 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 8 Jan 2003 06:52:19 -0800 (PST) Subject: [eap] Issue 62: Protected success/failure Message-ID: I've created a new issue to deal with this particular problem, which was formerly part of Issue 58. We will need to deal with it when the section that it refers to is rewritten from scratch (in progress), but there is no proposed fix at the moment. --------------------------------------------------------------------- Issue 62: Protected success/failure Submitter name: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: January 3, 2003 Document: RFC2284bis-08 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Page 6: "Protected success/failure" is never defined. Page 6: There is a sentence which says: Where a protected success/failure indication has been received at the EAP layer by an EAP Peer, it MUST accept and process the protected indication. This is a vacuous requirement, because there is no definition of what it means to "process" the "protected indication". At the very least this should indicate that "to process" means something like (a) apply all the protections of whatever ciphersuite that one believes to have been applied to the message to (b) extract a success/failure message, which is then handled according to the normal rules for EAP success/failure messages, and (c) received EAP success/failure messages that arrive unprotected are silently discarded if protection is expected. From aboba@internaut.com Wed Jan 8 16:31:45 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 8 Jan 2003 08:31:45 -0800 (PST) Subject: [eap] Issue 63: Identifier space advice Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: January 8, 2003 Document: RFC2869bis-05 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: AAA protocols may not preserve ordering. For example, RADIUS runs over UDP, an unordered transport. Diameter runs over reliable, ordered transports, yet ordering may not be preserved in the event of failover. Even though RFC 2284bis requires that EAP runs over an ordered transport, given possible AAA reordering, it is possible for retransmissions to be reordered in way that will confuse the EAP authenticator residing on the AAA server. To fix this, the following language needs to be inserted: "AAA protocols may not preserve ordering. For example, RADIUS runs over UDP, an unordered transport. Even where a AAA protocols runs over reliable, ordered transports, ordering may not be preserved in the event of failover, where proxies are present. As a result, where the NAS does not eliminate duplicate responses, and the EAP Identifier space is not monotonically increasing, it is possible for the RADIUS server to incorrectly act upon a duplicate EAP Response. To avoid this, RADIUS servers acting as EAP servers SHOULD implement a monotonically increasing EAP Identifier space, so as to be able to silently discard EAP Responses that arrive out of order." From james.d.carlson@east.sun.com Wed Jan 8 18:04:10 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Wed, 8 Jan 2003 13:04:10 -0500 Subject: [eap] Issue 63: Identifier space advice In-Reply-To: Bernard Aboba's message of 8 January 2003 08:31:45 References: Message-ID: <15900.26650.608896.524604@gargle.gargle.HOWL> Bernard Aboba writes: > "AAA protocols may not preserve ordering. For example, RADIUS runs > over UDP, an unordered transport. Even where a AAA protocols runs > over reliable, ordered transports, ordering may not be preserved > in the event of failover, where proxies are present. > > As a result, where the NAS does not eliminate duplicate responses, > and the EAP Identifier space is not monotonically increasing, > it is possible for the RADIUS server to incorrectly act upon a > duplicate EAP Response. To avoid this, RADIUS servers acting as > EAP servers SHOULD implement a monotonically increasing EAP > Identifier space, so as to be able to silently discard > EAP Responses that arrive out of order." As I've said in the meeting, I think this is sliding in exactly the wrong direction. EAP has a perfectly good invalid response (including duplication) detection mechanism on the authenticator side (where the RADIUS connection would necessarily be; RADIUS doesn't handle authenticatees). The EAP mechanism should be used. As long as you can detect duplicates, the packets going from authenticatee to authenticator have no problem. The only remaining issue is that of generating the duplicates in the first place. Perhaps one of the underlying assumptions here might be that retransmission of EAP Request messages would be driven by the RADIUS server. I think that's a bad plan, because it's unnecessary, exposes the RADIUS server to retransmission timers based on a EAP peer-to-peer link about which it knows exactly nothing, exposes the RADIUS server to retransmission timers and duplicate elimination that draft-ietf-aaa-eap-00 doesn't discuss, increases network traffic, and doesn't seem to help solve any identifiable problem. Assuming the duplicates are generated in the same place (the NAS sending and resending the same EAP Request over and over to provoke a Response), I think the duplicates should be eliminated in the same place so that the NAS presents a simple request/response interface to any backend service. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From yohba@tari.toshiba.com Wed Jan 8 19:10:28 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 8 Jan 2003 14:10:28 -0500 Subject: [eap] Issue 63: Identifier space advice In-Reply-To: <15900.26650.608896.524604@gargle.gargle.HOWL> References: <15900.26650.608896.524604@gargle.gargle.HOWL> Message-ID: <20030108191028.GA797@catfish> On Wed, Jan 08, 2003 at 01:04:10PM -0500, James Carlson wrote: > As I've said in the meeting, I think this is sliding in exactly the > wrong direction. > > EAP has a perfectly good invalid response (including duplication) > detection mechanism on the authenticator side (where the RADIUS > connection would necessarily be; RADIUS doesn't handle > authenticatees). The EAP mechanism should be used. As long as you > can detect duplicates, the packets going from authenticatee to > authenticator have no problem. Based on this, authenticatee also needs additional rule for not accepting Requests with non-monotonically increasing Identifier when the authenticator is operating in monotonically increasing Identifier. Then my concern is how the authenticatee and authenticator can tell whether ordered delivery is provided over the entire authentication path between the two entities or not, which seems to me be a hard thing to do. > > The only remaining issue is that of generating the duplicates in the > first place. Perhaps one of the underlying assumptions here might be > that retransmission of EAP Request messages would be driven by the > RADIUS server. I think that's a bad plan, because it's unnecessary, > exposes the RADIUS server to retransmission timers based on a EAP > peer-to-peer link about which it knows exactly nothing, exposes the > RADIUS server to retransmission timers and duplicate elimination that > draft-ietf-aaa-eap-00 doesn't discuss, increases network traffic, and > doesn't seem to help solve any identifiable problem. > > Assuming the duplicates are generated in the same place (the NAS > sending and resending the same EAP Request over and over to provoke a > Response), I think the duplicates should be eliminated in the same > place so that the NAS presents a simple request/response interface to > any backend service. I agree. > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > Yoshihiro Ohba From james.d.carlson@east.sun.com Wed Jan 8 19:24:07 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Wed, 8 Jan 2003 14:24:07 -0500 Subject: [eap] Issue 63: Identifier space advice In-Reply-To: Yoshihiro Ohba's message of 8 January 2003 14:10:28 References: <15900.26650.608896.524604@gargle.gargle.HOWL> <20030108191028.GA797@catfish> Message-ID: <15900.31447.727024.450305@gargle.gargle.HOWL> Yoshihiro Ohba writes: > > EAP has a perfectly good invalid response (including duplication) > > detection mechanism on the authenticator side (where the RADIUS > > connection would necessarily be; RADIUS doesn't handle > > authenticatees). The EAP mechanism should be used. As long as you > > can detect duplicates, the packets going from authenticatee to > > authenticator have no problem. > > Based on this, authenticatee also needs additional rule for not > accepting Requests with non-monotonically increasing Identifier when > the authenticator is operating in monotonically increasing Identifier. No, I don't think it does. If the underlying layer does not reorder, then there's only the "current request" and a "new request." There's no reason to require this. (Indeed, requiring this breaks compatibility with RFC 2284, which does *not* place restrictions on Identifier choice by the authenticator. I agree that this, along with some definiton of windowed ID comparision, is necessary if you allow reordering. 2284 didn't and I don't think we should or even can without writing essentially a new protocol.) > Then my concern is how the authenticatee and authenticator can tell > whether ordered delivery is provided over the entire authentication > path between the two entities or not, which seems to me be a hard > thing to do. Agreed. So, you break it into two components: there's the EAP peer-to-peer (L2) connection, and the EAP authenticator-to-AAA-server connection. The EAP peer-to-peer connection cannot result in processing of duplicates, because the Identifier and the non-reordering requirement together don't allow that to happen. The EAP authenticator-to-AAA-server connection is just out of scope. There's clearly a requirement that a AAA protocol must somehow describe how it will support the EAP authentication "as if" the authenticator were a single integrated system (including any AAA-related ordering), but I don't see how that's an issue for EAP itself. The connection between these two isn't exactly EAP; it's encapsulated EAP messages within a AAA transport. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From hzhou@cisco.com Wed Jan 8 21:58:51 2003 From: hzhou@cisco.com (Hao Zhou) Date: Wed, 8 Jan 2003 16:58:51 -0500 Subject: [eap] Re: [Issue 61] Support for EAP Sequences References: <014a01c2b696$46dd40d0$a4c16540@amer.cisco.com> <15899.21554.770583.678905@gargle.gargle.HOWL> <1041985124.3e1b6e640e442@floatingbottle.mail.umich.edu> Message-ID: <029401c2b761$21fdff40$a4c16540@amer.cisco.com> ----- Original Message ----- From: To: "James Carlson" Cc: "Bernard Aboba" ; "Hao Zhou" ; Sent: Tuesday, January 07, 2003 7:18 PM Subject: Re: [eap] Re: [Issue 61] Support for EAP Sequences > Quoting James Carlson : > > > Bernard Aboba writes: > > > > The current 2284bis doesn't distinguish FAILURE and SUCCESS from > > individual > > > > method and the final one from Authenticator, which makes it hard to > > support > > > > sequence of EAP methods. > > > > > > I think it's fair to say that RFC 2284 didn't anticipate use of sequences > > > at all, other than Identity followed by a method. > > > > That's only roughly fair. RFC 2284 did anticipate the use, but said > > that it probably wasn't a good idea on the balance: > > > > In practice, within or associated with each PPP server, it is not > > anticipated that a particular named user would be authenticated by > > multiple methods. This would make the user vulnerable to attacks > > which negotiate the least secure method from among a set (such as PAP > > rather than EAP). Instead, for each named user there should be an > > indication of exactly one method used to authenticate that user name. > > If a user needs to make use of different authentication methods under > > different circumstances, then distinct identities SHOULD be employed, > > each of which identifies exactly one authentication method. > > > > Is suspect that fear need not be true for an implementation that was > > exceedingly careful (that is, one that ran each authentication method > > regardless of the intermediate result of each, and then sent Success > > after *all* had been run only if all had passed). But given the > > tendency for mistakes, and the likely uselessness of the "feature," it > > seems reasonable to suggest that it's not a good idea. > > > I think the idea of sequences is useful when doing something in addition to > authentication. E.g. a method that negotiates QOS. Then the negotiation for > authenication method can be done, and if that method succeeds, an attempt to do > the QOS method can be made. If the peer accepts the method, it will get to > negotiate - if not it gets some default settings. > > This concept was at least part of the thinking at the time the initial EAP > draft was written. > > > > > I assume it is preferred that the existing EAP methods will require no > > > > change to be supported for sequences. They currently send out > > EAP-SUCCESS > > > > and EAP-FAILURE by themselves. > > > > > > This appears to be implementation specific. In some implementations they > > > are sent by the EAP layer, not by the method (Windows is an example). > > > > As long as the EAP implementation sends out EAP Success or EAP Failure > > when it has completely finished its authentication (rather than part > > way through), it doesn't matter how it's implemented internally. > > > seems true to me > > > > > Obviously, we need to distinguish > > > > those two types of success and failure to continue the sequence. > > > > > > Are you saying that the current RFC 2284bis text would break an existing > > > implementation? One of the mandates of the EAP WG is to retain backwards > > > compatibility if at all possible, particularly if the change doesn't > > > represent a "grey area" of RFC 2284. > > > > Why is it obvious that this is needed at all? > > > > What would the authenticatee do if told the equivalent of "you've > > passed two hurdles; now just one more to go?" If nothing else, this > > "method success" message would clearly present serious security > > problems, since it would allow divide and conquer. It also doesn't > > seem to help in the slightest because nobody has identified a use for > > them, other than perhaps as signaling *entirely* internal to an > > implementation with a particular EAP+method architecture. > > > > > How are the new messages to be sent? As new codes? A new EAP type? How > > > will backwards compatibility be maintained? > > > > And what would the peer do with them? They seem to be the protocol > > equivalent of having the peer say, "yes, yes, I see; do go on." > > > > I agree again. I think a success or failure should end a sequence. If methods > are implemented to send success or failure, then these implementations can't do > method sequences for the reasons that James Carlson suggests. > > John Vollbrecht Are we saying there should be only one success or failure message in the whole eap session, which should end the session? For methods that send out success and failure message (or the equivalent of result code to EAP layer signaling the same) to be used in a sequence, EAP layer should intercept them and change them into something else (new code/or new EAP type, such as EAP-TLV) to indicate to the peer the finishing of the first method. Peer would also need send back same indication to the backend server to acknowledge the receipt of the success so second method can start. Since backward compatibility with existing RFC2284 is needed, then a new code is not desirable. RFC 2284bis states sequences of EAP methods is supported in Page 5 Section 2.0, [6]. But it doesn't get into detail how the sequences is supported and what mechanism is used to link sequences of method together. Does this get too much into implementation or is it still part of the EAP spec? I was hoping a general mechanism or guidelines can be given to support the sequences of eap methods. Hao Zhou From james.d.carlson@east.sun.com Wed Jan 8 22:06:50 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Wed, 8 Jan 2003 17:06:50 -0500 Subject: [eap] Re: [Issue 61] Support for EAP Sequences In-Reply-To: Hao Zhou's message of 8 January 2003 16:58:51 References: <014a01c2b696$46dd40d0$a4c16540@amer.cisco.com> <15899.21554.770583.678905@gargle.gargle.HOWL> <1041985124.3e1b6e640e442@floatingbottle.mail.umich.edu> <029401c2b761$21fdff40$a4c16540@amer.cisco.com> Message-ID: <15900.41210.409588.362152@gargle.gargle.HOWL> Hao Zhou writes: > Are we saying there should be only one success or failure message in the > whole eap session, which should end the session? Yes, precisely. That's what RFC 2284 *requires*: 3. The authenticator ends the authentication phase with a Success or Failure packet. and also: Implementation Note: Because the Success and Failure packets are not acknowledged, they may be potentially lost. A peer MUST allow for this circumstance. The peer can use a Network Protocol packet as an alternative indication of Success. Likewise, the receipt of a LCP Terminate-Request can be taken as a Failure. They're "not acknowledged" in part because when you get to this point, EAP is done. > For methods that send out > success and failure message (or the equivalent of result code to EAP layer > signaling the same) to be used in a sequence, EAP layer should intercept > them and change them into something else (new code/or new EAP type, such as > EAP-TLV) to indicate to the peer the finishing of the first method. Peer > would also need send back same indication to the backend server to > acknowledge the receipt of the success so second method can start. Since > backward compatibility with existing RFC2284 is needed, then a new code is > not desirable. That's entirely an internal design issue. The communication (if any!) between methods and EAP within an implementation doesn't hit the wire and thus can't be part of any Standards Track IETF document. The only requirement is on what appears on the wire. That has to look like this: Zero or more Requests -> <- As many as one Response per Request Success or Failure -> Those codes, if they indeed do exist for some reason, must not appear on the wire. Indeed, they need not appear on the wire -- there's nothing sensible that an EAP peer could possibly do with a "partial Success" message. The authenticatee doesn't start anything -- he doesn't start the current method and he cannot start the next method. It's not his problem. > RFC 2284bis states sequences of EAP methods is supported in Page 5 Section > 2.0, [6]. But it doesn't get into detail how the sequences is supported and > what mechanism is used to link sequences of method together. Does this get > too much into implementation or is it still part of the EAP spec? I was > hoping a general mechanism or guidelines can be given to support the > sequences of eap methods. It's implementation. None of it appears on the wire between the two EAP-speaking peers. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Jan 9 00:38:59 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 8 Jan 2003 16:38:59 -0800 (PST) Subject: [eap] Issue 63: Identifier space advice In-Reply-To: <15900.26650.608896.524604@gargle.gargle.HOWL> Message-ID: > As I've said in the meeting, I think this is sliding in exactly the > wrong direction. > > EAP has a perfectly good invalid response (including duplication) > detection mechanism on the authenticator side (where the RADIUS > connection would necessarily be; RADIUS doesn't handle > authenticatees). The EAP mechanism should be used. As long as you > can detect duplicates, the packets going from authenticatee to > authenticator have no problem. The question was whether the requirements on the authenticator apply to the NAS when it operates in passthrough, or to the AAA server. While IEEE 802.1X *does* do duplicate elimination on the NAS, it is not clear whether that is mandated by the current RFC 2284bis text. If we can require the NAS to fulfill the obligations of an authenticator whether it is doing pass-through or not, then you are correct. > The only remaining issue is that of generating the duplicates in the > first place. Perhaps one of the underlying assumptions here might be > that retransmission of EAP Request messages would be driven by the > RADIUS server. No. RFC 2865 is very clear that RADIUS retransmission is driven by the NAS. > Assuming the duplicates are generated in the same place (the NAS > sending and resending the same EAP Request over and over to provoke a > Response), I think the duplicates should be eliminated in the same > place so that the NAS presents a simple request/response interface to > any backend service. Yes, I would agree. The question in my mind is whether this is an RFC 2284bis obligation on an authenticator, or whether it is a AAA client obligation. My sense is that it is a AAA client obligation. I'd note that this is not the only case in which the obligations of "authenticators" are unclear. Another example is the obligation to implement the mandatory to implement method (EAP MD5). Is this an obligation of a NAS that always acts as a pass through or a AAA server obligation? From aboba@internaut.com Thu Jan 9 02:31:15 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 8 Jan 2003 18:31:15 -0800 (PST) Subject: [eap] Issue 66: Mandatory for who? Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: January 8, 2003 Document: Comment type: T Priority: S Section: 3.4 Rationale/Explanation of issue: RFC 2284, Section 3.4 states: "All EAP implementations MUST support the MD5-Challenge mechanism." Does this obligation extend to NASes operating in passthrough mode? For example, MUST they be able to authenticate a local user via EAP MD5? Going further, do obligations of authenticators (such as dropping duplicate Requests) extend to NASes operating in passthrough? Who is the authenticator in this case? The NAS? The AAA server? Both? From aboba@internaut.com Thu Jan 9 04:23:00 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 8 Jan 2003 20:23:00 -0800 (PST) Subject: [eap] Issue 63: Identifier space advice Message-ID: > Assuming the duplicates are generated in the same place (the NAS > sending and resending the same EAP Request over and over to provoke a > Response), I think the duplicates should be eliminated in the same > place so that the NAS presents a simple request/response interface to > any backend service. Looking through RFC 2284bis again, I believe that the requirements on authenticators apply whether the authenticator is operating in pass through mode or not. The definition of an authenticator makes no such destinction. Maybe we should say that explicitly: that the "mode" of operation is irrelevant. Also, the definition of an RFC 2284bis authenticator is identical to that in IEEE 802.1X -- nowhere in the document does it use the term "authenticator" where "backend authentication server" is meant. So there's no terminology disconnect that I can see. Given this, there is an obligation of the NAS to drop duplicate Responses, whether it is talking to a backend authentication server or not. If made clear, this resolves the issue. However, I will say that there appears to be widespread confusion on this issue (as well as on whether the mandatory-to-implement method needs to be implemented by a NAS in passthrough -- the answer seems to be yes). So clarification is needed. From jari.arkko@piuha.net Thu Jan 9 07:59:06 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 09 Jan 2003 09:59:06 +0200 Subject: [eap] Issue 66: Mandatory for who? References: Message-ID: <3E1D2BCA.4070408@piuha.net> Bernard Aboba wrote: > RFC 2284, Section 3.4 states: > > "All EAP implementations MUST support the MD5-Challenge mechanism." > > Does this obligation extend to NASes operating in passthrough mode? > For example, MUST they be able to authenticate a local user via > EAP MD5? I'd say no. > Going further, do obligations of authenticators (such as dropping > duplicate Requests) extend to NASes operating in passthrough? Who > is the authenticator in this case? The NAS? The AAA server? > Both? This specific issue is related to the discussion on ordering. I don't have an opinion yet on that. However, I believe it would be very useful indicate for each requirement for which node it applies, and treat AAA servers, passthroughs, and peers separately. Hmm.. Do we talk about passthroughs here or in 2869bis? Would it be sufficient for us to define authenticator == AAA server in case EAP is not directly terminated in the NAS? Anyway, here's a my check of all the MUSTs in the spec: o Section 1.2 (terms): General MUSTs which appear OK. o Section 2 (intro): Two MUSTs for passthrough NASes. o Section 2.1 (mux): One peer MUST, one general MUST which appears OK. o Section 3.2 (PPP): One general MUST which appears OK because it is for PPP peers and therefore unambiguous. o Section 3.4 (ll inds): Two general MUSTs, appears OK. o Section 4 (format): One general MUST, explicitly says applies to authenticators and peers. Ok. o Section 4.1 (r&r): - One authenticator MUST, one peer MUST for who sends requests. Is it unclear whether the passthrough should check something here? I guess the passthrough does not know whether we are running EAP in two directions. Hence, it MUST allow both requests and responses from both directions. Should this be stated somewhere? - Two MUSTs on additional requests. From the context this is the authenticator sending them, but this isn't explicitly stated. Maybe we should do that. - One MUST on peer's response behaviour. Ok. - Two MUSTs on general response-request matching; this would benefit from explicitly stating who does what. - Three MUSTs for authenticators. o Section 4.1 (id) - Two general MUSTs for retransmissions; should explictly say these are for the authenticator? - Two peer MUSTs for duplicates: OK. o Section 4.1 (type): - One general MUST, apparently OK (?) o Section 4.2 (succ): - Two authenticator MUSTs. - One general MUST, OK. - One MUST which states that the Id for a Succ/Fail must be unique over the *whole* conversation. I fail to see how this can be implemented... what if you already cycled through all the numbers?! Or are we reserving one (or more?) Id numbers for o Section 4.2.1 (prot): - One peer MUST. - One authenticator MUST. - One peer MUST - Two general MUSTs in bullet item e, but since they talk about discarding Failures and Successes, isn't this for the peer? o Section 5 (types): - 4 general MUSTs, I guess these are OK. o Section 5.1 (identity): - 2 general MUSTs, hmm.. maybe OK. - 1 authenticator MUST - 1 general MUST, OK. o Section 5.2 (notif): - 3 peer MUSTs. - 2 general MUSTs. Hmm... I think we said earlier somewhere that the authenticator must discard requests. Maybe it would make sense to change the 2 requirements here to apply for peers only, otherwise there's a contradiction since they say MUST respond. o Section 5.3 (nak): - One general MUST. Ok. - One general MUST dealing with sending this; I guess this should be for peer only? - Two general MUSTs, Ok. o Section 5.4 (md5): - One general MUST but again this should hold for authenticators only? - One general MUST, Ok. o Section 5.5 (otp): - Two general MUSTs. The first should be again for peer only? o Section 5.6 (gtc): - One general MUST, again for peer only? Also, all the other sections explain carefully that you can either respond with the Response or Nak; 5.6 does not! o Section 5.7 (vend): - One general MUST, Ok. - One peer MUST. There's some potential things to fix in the following sections: - 4.1 (4 times) - 4.2.1 (1 time) - 5.2 (1 time) - 5.3 (1 time) - 5.4 (1 time) - 5.5 (1 time) - 5.6 (1 time) And a potential new issues to file from Section 4.2 and from Section 5.6. Jari ---- P.S. In bis-09, change is implemented within the EAP layer. peers MUST respond to an EAP to is implemented within the EAP layer. Peers MUST respond to an EAP From james.d.carlson@east.sun.com Thu Jan 9 13:59:58 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 08:59:58 -0500 Subject: [eap] Issue 63: Identifier space advice In-Reply-To: Bernard Aboba's message of 8 January 2003 20:23:00 References: Message-ID: <15901.32862.456696.758781@gargle.gargle.HOWL> Bernard Aboba writes: > > Assuming the duplicates are generated in the same place (the NAS > > sending and resending the same EAP Request over and over to provoke a > > Response), I think the duplicates should be eliminated in the same > > place so that the NAS presents a simple request/response interface to > > any backend service. > > Looking through RFC 2284bis again, I believe that the requirements on > authenticators apply whether the authenticator is operating in pass > through mode or not. The definition of an authenticator makes no such > destinction. Maybe we should say that explicitly: that the "mode" of > operation is irrelevant. Right. I fully agree with that -- whether it's a "pass-through" or not is irrelevant. This document describes how EAP has to behave on the wire between two EAP speakers, and, for interoperability, the that part of the behavior must *not* change depending on factors outside of this link. The linkage between the authenticator and any backend authentication services -- whether using AAA pass-through, translation to foreign protocol (such as, say, LDAP), proprietary database, or random number generation -- must be invisible to the authenticatee. > Also, the definition of an RFC 2284bis authenticator is identical to that > in IEEE 802.1X -- nowhere in the document does it use the term > "authenticator" where "backend authentication server" is meant. So there's > no terminology disconnect that I can see. > > Given this, there is an obligation of the NAS to drop duplicate > Responses, whether it is talking to a backend authentication server or > not. If made clear, this resolves the issue. > > However, I will say that there appears to be widespread confusion on this > issue (as well as on whether the mandatory-to-implement method needs to be > implemented by a NAS in passthrough -- the answer seems to be yes). So > clarification is needed. That sounds like a reasonable plan. The text should say that the EAP Authenticator is responsible for retransmitting the Request messages, and that if it got the Request message from someone else (i.e., via AAA), then it will have to save a copy in order to do this, and that the Authenticator is responsible for discarding Response messages with the wrong Identifier value before acting on them in any way, including passing along to an outside party for verification. Similarly, the EAP Authenticatee is responsible for detecting and handling duplicate Request messages before processing them in any way, including passing along to any outside party for fetching data. Of course, I still think this is just internal design advice. It should not be normative because it still doesn't describe on the wire behavior. We probably need a term to disambiguate the "ultimate authenticator" (which might be a AAA server) from the EAP Authenticator (peer-to-peer) role. Any suggestions? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Thu Jan 9 14:11:38 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 09:11:38 -0500 Subject: [eap] Issue 66: Mandatory for who? In-Reply-To: Jari Arkko's message of 9 January 2003 09:59:06 References: <3E1D2BCA.4070408@piuha.net> Message-ID: <15901.33562.130285.177155@gargle.gargle.HOWL> Jari Arkko writes: > Bernard Aboba wrote: > > "All EAP implementations MUST support the MD5-Challenge mechanism." > > > > Does this obligation extend to NASes operating in passthrough mode? > > For example, MUST they be able to authenticate a local user via > > EAP MD5? > > I'd say no. I'd also say no -- but that it forms a part of the requirements for choosing a backend service when doing any sort of pass-through. If the backend service cannot support MD5-Challenge, then it cannot be a backend for EAP, because it would make the EAP Authenticator incompatible with RFC 2284. > > Going further, do obligations of authenticators (such as dropping > > duplicate Requests) extend to NASes operating in passthrough? Who > > is the authenticator in this case? The NAS? The AAA server? > > Both? > > This specific issue is related to the discussion on ordering. I > don't have an opinion yet on that. However, I believe it would > be very useful indicate for each requirement for which node it > applies, and treat AAA servers, passthroughs, and peers separately. I think an EAP implementation in the Authenticator role must appear to be the same from the EAP Authenticatee's point of view no matter what sort of backend its using. That's sort of the point of having a standard here. If you want to have a separate text to describe how you might accomplish that within the EAP Authenticator implementation using a pass-through mechanism, that sounds like reasonable implementation advice, but I'd question whether it even belongs here. I think it should probably go in a separate Informational "using EAP with AAA" document. Clearly, AAA servers and the protocols used to talk to AAA clients (such as EAP Authenticators) need to be in separate documents. Duplicating RADIUS or DIAMETER work here would be a bad thing. > Hmm.. Do we talk about passthroughs here or in 2869bis? Would > it be sufficient for us to define authenticator == AAA server in > case EAP is not directly terminated in the NAS? No, I don't think that definition is good. I think we need clearly separate terms for the EAP-speaking peer that is in the Authenticator role (the "NAS" in many architectures) and the EAP-capable system that is in the ultimate authentication role (the "AAA server"). The two are clearly quite different. In particular, the fact that, if you're doing pass-through, the AAA server sees EAP messages does *NOT* mean that the AAA server itself speaks EAP. In particular, it doesn't do the Identifier-related blood-and-chicken dances. It's using EAP message formats to convey authentication data, not EAP the authentication transport protocol. > P.S. In bis-09, change > is implemented within the EAP layer. peers MUST respond to an EAP > to > is implemented within the EAP layer. Peers MUST respond to an EAP Personally, and I might be in the minority here, I find the usage of capitalization to delimit a term d'art to be quite baroque, especially as it's applied in this document. In particular, the term "peer" has well-known usage in IETF circles. Does EAP need its own private definition to survive? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Thu Jan 9 14:25:21 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 09:25:21 -0500 Subject: [eap] Issue 66: Mandatory for who? In-Reply-To: Bernard Aboba's message of 8 January 2003 18:31:15 References: Message-ID: <15901.34385.296721.792172@gargle.gargle.HOWL> Bernard Aboba writes: > "All EAP implementations MUST support the MD5-Challenge mechanism." > > Does this obligation extend to NASes operating in passthrough mode? In a sense, yes. The EAP Authenticator *plus* the backend server together have to arrange to support MD5-Challenge in order for the EAP Authenticator to pass RFC 2284 muster. How this actually takes place really isn't our problem -- it's the problem of the definition of the AAA linkage. If the AAA service to be used supports MD5-Challenge, then that'd be great. If it doesn't, then other arrangements will have to be made. None of that affects what's on the wire for EAP -- the EAP implementation must be able to support this authentication mechanism. Another way to document it is that from the EAP Authenticatee's point of view, there's no way to distinguish between what the EAP Authenticator implements, and what some backend service implements. It's a null issue. From the Authenticatee's point of view, MD5-Challenge must be supported. > Going further, do obligations of authenticators (such as dropping > duplicate Requests) Authenticators do not drop duplicate Requests. Authenticatees do. > extend to NASes operating in passthrough? Who > is the authenticator in this case? The NAS? The AAA server? > Both? As before, I'd argue that the entity that generates the duplicate Requests should also have responsibility to discard invalid Responses. If, in a given AAA scenario, the NAS is responsible for retransmitting, then it should eliminate the bad responses (which would include, but not be limited to, duplicates). If it's not retransmitting, then the NAS wouldn't be eliminating bad responses. We can possibly give guidance here, but I don't think it's wise for the EAP working group to do the work of the AAA working group. The boundary is at the implementation level: there's a description of what has to appear on the wire between two EAP speakers, which is this working group's job, and there's a description of what has to appear on the wire between a AAA client (i.e., EAP Authenticator) and AAA server, and that's the AAA's responsibility. The impedance matching between those to is mostly an implementation issue. So, at best, I think we should have a recommendation that says that if you're using a back-end authentication service that is designed using encapsulated EAP messages, then this working group believes that the AAA protocol should be designed assuming that the NAS should retransmit and eliminate duplicates. Since the choice of whether to eliminate those duplicates or not does *not* appear on the wire between the EAP peers, we should not (and I would argue *cannot*) provide a normative specification for that part of the behavior. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From henry.haverinen@nokia.com Thu Jan 9 14:25:25 2003 From: henry.haverinen@nokia.com (henry.haverinen@nokia.com) Date: Thu, 9 Jan 2003 16:25:25 +0200 Subject: [eap] EAP SIM and EAP AKA status and key derivation Message-ID: Hello, Here's a short status update on EAP SIM and EAP AKA. We submitted to be draft-arkko-pppext-eap-aka-07.txt and draft-haverinen-pppext-eap-sim-08.txt to the RFC editor to be considered as informational RFCs. However, based on comments from Bernard there is a problem in the key derivation section and some missing security claim considerations as required by the latest RFC 2284bis that we need to fix, so we'll=20 have to revise the drafts and submit them again. In short, the key derivation sections will be changed so that we'll always generate the same amount of "application specific keying" material (probably 192 bytes, just as in RFC 2716). When RFC 2548 RADIUS key attributes are used to communicate=20 application keys then only the 64 bytes are needed, the first=20 32 bytes as the MS-MPPE-RECV-KEY and the second 32 bytes as the=20 MS-MPPE-SEND-KEY. Note that this is different from the=20 key derivation annexes of the current draft versions, where the=20 MS-MPPE-SEND-KEY is generated first when WEP is being used. So the only technical change will be the order of the derived application specific keys in the EAP SIM annex B and EAP AKA annex A when WEP is used. For 802.11i, the PMK is still the first 32 bytes from the application specific key stream. This change is needed=20 to make key distribution independent from ciphersuite. Regards, Henry From james.d.carlson@east.sun.com Thu Jan 9 14:35:58 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 09:35:58 -0500 Subject: [eap] Issue 63: Identifier space advice In-Reply-To: Bernard Aboba's message of 8 January 2003 16:38:59 References: <15900.26650.608896.524604@gargle.gargle.HOWL> Message-ID: <15901.35022.476598.442831@gargle.gargle.HOWL> Bernard Aboba writes: > > EAP has a perfectly good invalid response (including duplication) > > detection mechanism on the authenticator side (where the RADIUS > > connection would necessarily be; RADIUS doesn't handle > > authenticatees). The EAP mechanism should be used. As long as you > > can detect duplicates, the packets going from authenticatee to > > authenticator have no problem. > > The question was whether the requirements on the authenticator apply to > the NAS when it operates in passthrough, or to the AAA server. While IEEE > 802.1X *does* do duplicate elimination on the NAS, it is not clear whether > that is mandated by the current RFC 2284bis text. If we can > require the NAS to fulfill the obligations of an authenticator whether it > is doing pass-through or not, then you are correct. I think the issue has more to do with the definition of the AAA server and client responsibilities that are designed into the AAA architecture itself. In other words, it's just not our problem. > > The only remaining issue is that of generating the duplicates in the > > first place. Perhaps one of the underlying assumptions here might be > > that retransmission of EAP Request messages would be driven by the > > RADIUS server. > > No. RFC 2865 is very clear that RADIUS retransmission is driven by the > NAS. I'm trying to guess at why it's even considered an issue. The idea that there's some sort of a problem here is rather foreign to me. I can't think of a plausible system architecture in which an EAP Authenticator implementation passes along garbage to its backend authentication server. That makes no sense, so I'm trying to guess at how it might have been considered an issue. If someone here thinks that bad responses (there are no distinguishable "duplicates" at the Authenticator side; they're just lumped together with all Responses that have the wrong, non-current Identifier value) should be passed along to the AAA service, please speak up and explain. > > Assuming the duplicates are generated in the same place (the NAS > > sending and resending the same EAP Request over and over to provoke a > > Response), I think the duplicates should be eliminated in the same > > place so that the NAS presents a simple request/response interface to > > any backend service. > > Yes, I would agree. The question in my mind is whether this is an RFC > 2284bis obligation on an authenticator, or whether it is a AAA client > obligation. My sense is that it is a AAA client obligation. Exactly. > I'd note that this is not the only case in which the obligations of > "authenticators" are unclear. Another example is the obligation to > implement the mandatory to implement method (EAP MD5). Is this an > obligation of a NAS that always acts as a pass through or a AAA server > obligation? The EAP Authenticator has an obligation to provide this. If the chosen AAA server can't do it, then either the EAP Authenticator cannot use that AAA server, or the EAP implementation needs a proprietary work-around. The only issue we should care about is the messages between EAP Authenticator and EAP Authenticatee. For instance, suppose the EAP Authenticator is implemented on a system using NIS for "user" authentication. I don't know of any feasible way to make that interface work with MD5-Challenge. So, as an EAP implementor, I'm stuck with a problem: I must support MD5-Challenge, and my chosen backend doesn't support that requirement. Thus, I have to kludge something together, like a separate text file with MD5-Challenge credentials. Now, is that an RFC issue? I don't think so. The responsibility for the EAP implementor is clear. How you might achieve that through implementation choices is your problem. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From jrv@umich.edu Thu Jan 9 14:58:58 2003 From: jrv@umich.edu (jrv@umich.edu) Date: Thu, 9 Jan 2003 09:58:58 -0500 Subject: [eap] Issue 66: Mandatory for who? In-Reply-To: <15901.33562.130285.177155@gargle.gargle.HOWL> References: <3E1D2BCA.4070408@piuha.net> <15901.33562.130285.177155@gargle.gargle.HOWL> Message-ID: <1042124338.3e1d8e323c6bd@ponyexpress.mail.umich.edu> Quoting James Carlson : > Jari Arkko writes: > > Bernard Aboba wrote: > > > "All EAP implementations MUST support the MD5-Challenge mechanism." > > > > > > Does this obligation extend to NASes operating in passthrough mode? > > > For example, MUST they be able to authenticate a local user via > > > EAP MD5? > > > > I'd say no. > > I'd also say no -- but that it forms a part of the requirements for > choosing a backend service when doing any sort of pass-through. If > the backend service cannot support MD5-Challenge, then it cannot be a > backend for EAP, because it would make the EAP Authenticator > incompatible with RFC 2284. > > > > Going further, do obligations of authenticators (such as dropping > > > duplicate Requests) extend to NASes operating in passthrough? Who > > > is the authenticator in this case? The NAS? The AAA server? > > > Both? > > > > This specific issue is related to the discussion on ordering. I > > don't have an opinion yet on that. However, I believe it would > > be very useful indicate for each requirement for which node it > > applies, and treat AAA servers, passthroughs, and peers separately. > > I think an EAP implementation in the Authenticator role must appear to > be the same from the EAP Authenticatee's point of view no matter what > sort of backend its using. That's sort of the point of having a > standard here. > > If you want to have a separate text to describe how you might > accomplish that within the EAP Authenticator implementation using a > pass-through mechanism, that sounds like reasonable implementation > advice, but I'd question whether it even belongs here. I think it > should probably go in a separate Informational "using EAP with AAA" > document. > > Clearly, AAA servers and the protocols used to talk to AAA clients > (such as EAP Authenticators) need to be in separate documents. > Duplicating RADIUS or DIAMETER work here would be a bad thing. > > > Hmm.. Do we talk about passthroughs here or in 2869bis? Would > > it be sufficient for us to define authenticator == AAA server in > > case EAP is not directly terminated in the NAS? > > No, I don't think that definition is good. I think we need clearly > separate terms for the EAP-speaking peer that is in the Authenticator > role (the "NAS" in many architectures) and the EAP-capable system that > is in the ultimate authentication role (the "AAA server"). The two > are clearly quite different. In particular, the fact that, if you're > doing pass-through, the AAA server sees EAP messages does *NOT* mean > that the AAA server itself speaks EAP. In particular, it doesn't do > the Identifier-related blood-and-chicken dances. It's using EAP > message formats to convey authentication data, not EAP the > authentication transport protocol. this is an interesting distinction. could you expand on what you see the difference between doing EAP the transport protocol and using EAP message formats to convey authentication data? I think there is a distinction here, but it seems to me the AAA server is in fact the one doing EAP protocol, and the AP initiates and provided the connection between Client and AAA. I think this is an area where the same vocabulary can have different meanings, and conversations go off in peculiar directions. Anyway, I think you raise an important point. I think the "passthru" method might provide solution, where the passthru acts as Authenticator to the Client, and Client to the AAA. Doing EAP in both connections. > > > P.S. In bis-09, change > > is implemented within the EAP layer. peers MUST respond to an EAP > > to > > is implemented within the EAP layer. Peers MUST respond to an EAP > > Personally, and I might be in the minority here, I find the usage of > capitalization to delimit a term d'art to be quite baroque, especially > as it's applied in this document. In particular, the term "peer" has > well-known usage in IETF circles. Does EAP need its own private > definition to survive? > John Vollbrecht From james.d.carlson@east.sun.com Thu Jan 9 15:08:11 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 10:08:11 -0500 Subject: [eap] Re: [Issue 61] Support for EAP Sequences In-Reply-To: jrv@umich.edu's message of 7 January 2003 19:18:44 References: <014a01c2b696$46dd40d0$a4c16540@amer.cisco.com> <15899.21554.770583.678905@gargle.gargle.HOWL> <1041985124.3e1b6e640e442@floatingbottle.mail.umich.edu> Message-ID: <15901.36955.244588.228248@gargle.gargle.HOWL> jrv@umich.edu writes: > > Is suspect that fear need not be true for an implementation that was > > exceedingly careful (that is, one that ran each authentication method > > regardless of the intermediate result of each, and then sent Success > > after *all* had been run only if all had passed). But given the > > tendency for mistakes, and the likely uselessness of the "feature," it > > seems reasonable to suggest that it's not a good idea. > > > I think the idea of sequences is useful when doing something in addition to > authentication. E.g. a method that negotiates QOS. Then the negotiation for > authenication method can be done, and if that method succeeds, an attempt to do > the QOS method can be made. If the peer accepts the method, it will get to > negotiate - if not it gets some default settings. Despite the fact that I'm a little uncomfortable with putting authorization negotiation (such as QoS) into the middle of an authentication protocol, hat's a good example because it shows the depth of the problem in trying to define *anything* about sequences in a "generic" way in this draft. Let's suppose you have a QoS negotiation, and the EAP Authenticatee has never heard of it. Is failure of the "QoS method" a problem? Almost certainly not -- it just means that the peer gets a default QoS treatment. Does the unexpected method at the Authenticatee side pose a problem? No, the Authenticatee just sends back a suitable Nak, and the Authenticator (and the designer of this new method) must be smart enough to know what to do next. While the concept is useful in implementation, and it's certainly useful in designing particularly squirrelly methods, I don't see that it has any place in the EAP specification itself. The EAP Authenticator holds its cards pretty closely; all it reveals is the sequence of Request messages it sends. More to the point, the EAP Authenticatee cannot assume anything about method sequencing, because it's not in control of the conversation. So, since the Authenticator doesn't reveal its intentions except by Request messages, and the Authenticatee, which is required to respond to all requests, cannot care about those intentions, I think the issue is irrelevant at this level. Clearly, useful methods will likely have to address issues here, but EAP itself doesn't. (For instance, an EAP method should probably describe what, if anything, a client must store between Requests, and what, if anything, an intervening Request with a different Type might mean. I think that well-written methods would not change internal state based on the activities of any other Types seen, but other method designers are free to be strange. Additionally, a method designer must describe what, if anything special, an implementation is required to do on seeing Success. If the method includes mutual authentication, then the definition of the method should say something like this: "the link MUST be terminated if the peer sends EAP Success and the client method state machine is not in final state AuthGood.") What meanful generic requirements on EAP could be imposed with regard to sequencing? Since it's all so dependent on what the method does and how, I'm at a loss to describe what that requirement must be. Saying "MUST NOT send a Request with a new Type until the last method is done" seems vacuous to me. It only means something with a method that has a state like that, and the general truth of it seems pretty sketchy. > > And what would the peer do with them? They seem to be the protocol > > equivalent of having the peer say, "yes, yes, I see; do go on." > > > > I agree again. I think a success or failure should end a sequence. If methods > are implemented to send success or failure, then these implementations can't do > method sequences for the reasons that James Carlson suggests. Since "methods" are entirely internal to an EAP implementation, one could imagine that the "Success" message is filtered out at the EAP level and sent only when the "sequence" is complete. Needless to say, this is just an implementation strategy and has nothing to do with the protocol on the wire. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Thu Jan 9 15:50:17 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 10:50:17 -0500 Subject: [eap] Issue 66: Mandatory for who? In-Reply-To: jrv@umich.edu's message of 9 January 2003 09:58:58 References: <3E1D2BCA.4070408@piuha.net> <15901.33562.130285.177155@gargle.gargle.HOWL> <1042124338.3e1d8e323c6bd@ponyexpress.mail.umich.edu> Message-ID: <15901.39481.121551.313364@gargle.gargle.HOWL> jrv@umich.edu writes: > > No, I don't think that definition is good. I think we need clearly > > separate terms for the EAP-speaking peer that is in the Authenticator > > role (the "NAS" in many architectures) and the EAP-capable system that > > is in the ultimate authentication role (the "AAA server"). The two > > are clearly quite different. In particular, the fact that, if you're > > doing pass-through, the AAA server sees EAP messages does *NOT* mean > > that the AAA server itself speaks EAP. In particular, it doesn't do > > the Identifier-related blood-and-chicken dances. It's using EAP > > message formats to convey authentication data, not EAP the > > authentication transport protocol. > > this is an interesting distinction. could you expand on what you see the > difference between doing EAP the transport protocol and using EAP message > formats to convey authentication data? The difference is in the way the protocols behave. The AAA protocol is a reliable transport -- it has its own retransmission behavior and error recovery. It would thus be senseless to implement any of EAP's retransmission and duplicate handling strategy over a AAA protocol. In fact, for DIAMETER and RADIUS, it would be strictly impossible because there's no way to drive retransmission in that direction. (The Requests come to the EAP Authenticator by way of AAA *RESPONSES*, not commands.) So, to put this in context, here's what I see: 1. NAS (EAP Authenticator) receives a new link (a "call"). 2. NAS determines that this link uses EAP, and that DIAMETER is needed for the backend. (L2-specific and proprietary policy mechanism here.) 3. NAS sends Diameter-EAP-Request with NULL EAP-Payload AVP to DIAMETER server. 4. Server responds with Diameter-EAP-Answer containing EAP message to send. 5. NAS sends EAP Request with the given payload. 6. NAS waits for Response from peer. It retransmits the same Request periodically based on its knowledge of the link characteristics (RTT and so on). It drops bad Response messages (with Identifier not equal to the current one). 7. A valid Response is seen. This is forwarded to the DIAMETER server by encapsulating as EAP-Payload AVP in a new Diameter-EAP-Request message. The current stored Identifier is "invalidated" so that we don't do this again until the DIAMETER server responds. 8. The server responds with Diameter-EAP-Answer. If this has an EAP Response to send, go back to step (5). If it has EAP Success or Failure, send that, and quit. Perhaps some feel that step (2) is vague. That's intentional. On PPP, one uses LCP to tell if EAP is in use, and with ISDN one might use the Calling Party Identification to determine what DIAMETER server to use. It's all local policy. It might include an initial EAP Identity to snag an NAI, as suggested in draft-ietf-aaa-eap-00. The distinction I'm drawing, and I think it's quite valid, is between EAP messages sent between EAP Authenticator and EAP Authenticatee, and EAP messages that are carried as freight in the EAP-Payload AVP. At step (7), the DIAMETER server *might* want to validate that the EAP Identifier carried in the payload is indeed the same one that was sent in the last answer to the NAS. If not, then sending Failure would be appropriate. In any event, this sort of AAA message validation and handling is NOT part of RFC 2284. It's strictly a AAA linkage issue and belongs in draft-ietf-aaa-eap-00. Note particularly that *everything* about sequencing is controlled *completely* on the DIAMETER server. That, I think, is another clue that sequencing is not really part of EAP itself but is rather a part of the individual method and the overall deployment-specific authentication policies. > I think there is a distinction here, > but it seems to me the AAA server is in fact the one doing EAP protocol, and > the AP initiates and provided the connection between Client and AAA. Right. > I think this is an area where the same vocabulary can have different meanings, > and conversations go off in peculiar directions. I agree. > Anyway, I think you raise an important point. I think the "passthru" method > might provide solution, where the passthru acts as Authenticator to the Client, > and Client to the AAA. Doing EAP in both connections. I'm almost with you. EAP, including the retransmit mechanism, is certainly there for the Authenticator to Authenticatee connection. Those Identifier tricks are just not the same for the pass-through to AAA connection, because that connnection is most certainly *not* EAP. It has EAP messages encapsulated, but it's actually AAA, not EAP. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Jan 9 14:57:50 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 9 Jan 2003 06:57:50 -0800 (PST) Subject: [eap] Issue 63: Identifier space advice In-Reply-To: <15901.32862.456696.758781@gargle.gargle.HOWL> Message-ID: > We probably need a term to disambiguate the "ultimate authenticator" > (which might be a AAA server) from the EAP Authenticator > (peer-to-peer) role. Any suggestions? The term "EAP Server" is used in RFC 2869bis. However, we have to be careful where this is applied. I'll look through RFC 2284bis for any places where that is meant instead of "authenticator". At first glance, there aren't many cases of this. From yohba@tari.toshiba.com Thu Jan 9 16:09:43 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Thu, 9 Jan 2003 11:09:43 -0500 Subject: [eap] Issue 66: Mandatory for who? In-Reply-To: <1042124338.3e1d8e323c6bd@ponyexpress.mail.umich.edu> References: <3E1D2BCA.4070408@piuha.net> <15901.33562.130285.177155@gargle.gargle.HOWL> <1042124338.3e1d8e323c6bd@ponyexpress.mail.umich.edu> Message-ID: <20030109160943.GB668@catfish> On Thu, Jan 09, 2003 at 09:58:58AM -0500, jrv@umich.edu wrote: > > No, I don't think that definition is good. I think we need clearly > > separate terms for the EAP-speaking peer that is in the Authenticator > > role (the "NAS" in many architectures) and the EAP-capable system that > > is in the ultimate authentication role (the "AAA server"). The two > > are clearly quite different. In particular, the fact that, if you're > > doing pass-through, the AAA server sees EAP messages does *NOT* mean > > that the AAA server itself speaks EAP. In particular, it doesn't do > > the Identifier-related blood-and-chicken dances. It's using EAP > > message formats to convey authentication data, not EAP the > > authentication transport protocol. I agree. > > this is an interesting distinction. could you expand on what you see the > difference between doing EAP the transport protocol and using EAP message > formats to convey authentication data? I think there is a distinction here, > but it seems to me the AAA server is in fact the one doing EAP protocol, and > the AP initiates and provided the connection between Client and AAA. One distinction is EAP Success/Failre message is not necessarily carried in AAA messages. Another distinction is on Identifier management. It is not always possible for a NAS to completely "pass-through" EAP message "as it is". Suppose that method A and method B are performed in a sequence, and method A is performed _without_ using AAA while method B is performed _with_ using AAA. If the NAS passes through method B EAP Requests originated from the AAA server as it is, the last Identifier in method A may conflict with the first Identifier in method B, and coversation may fail. So I think in this case the NAS need to re-assign the Identifier. On the other hand, if AAA provides ordered, reliable transport, EAP Identifier might not be even necessarily carried in AAA messages. > > I think this is an area where the same vocabulary can have different meanings, > and conversations go off in peculiar directions. > > Anyway, I think you raise an important point. I think the "passthru" method > might provide solution, where the passthru acts as Authenticator to the Client, > and Client to the AAA. Doing EAP in both connections. As one of persons who consider "pass-through" method, I think the method should not be described in RFC228bis, according to the consensus on having no distinction on operational modes in the specification. However, when definining a state machine of the protocol (as an informational guideline for implementors), I believe "pass-through" method might help simplify the state machine definition. Yoshihiro Ohba From james.d.carlson@east.sun.com Thu Jan 9 16:19:36 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 11:19:36 -0500 Subject: [eap] Issue 66: Mandatory for who? In-Reply-To: Yoshihiro Ohba's message of 9 January 2003 11:09:43 References: <3E1D2BCA.4070408@piuha.net> <15901.33562.130285.177155@gargle.gargle.HOWL> <1042124338.3e1d8e323c6bd@ponyexpress.mail.umich.edu> <20030109160943.GB668@catfish> Message-ID: <15901.41240.258305.205730@gargle.gargle.HOWL> Yoshihiro Ohba writes: > One distinction is EAP Success/Failre message is not necessarily > carried in AAA messages. > > Another distinction is on Identifier management. It is not always > possible for a NAS to completely "pass-through" EAP message "as it > is". Suppose that method A and method B are performed in a sequence, > and method A is performed _without_ using AAA while method B is > performed _with_ using AAA. Or even (eek!) through different AAA services. > If the NAS passes through method B EAP > Requests originated from the AAA server as it is, the last Identifier > in method A may conflict with the first Identifier in method B, and > coversation may fail. So I think in this case the NAS need to > re-assign the Identifier. On the other hand, if AAA provides ordered, > reliable transport, EAP Identifier might not be even necessarily > carried in AAA messages. That's an interesting problem. Since some methods (e.g., RFC 2284 MD5-Challenge) compute the Response value based on the Identifier, so I think that Identifier remapping is impossible without some additional help. In any event, this is a problem for the definition of the AAA service, not for EAP. (One way around it might be to have the AAA protocol carry an additional "EAP-NAS-Assigned-Identifier" AVP. Since that probably has interesting security issues, it's probably best left to the folks who have to deal with that protocol. Another way around it would be to require the AAA server to choose an Identifier value for the first message at random, and then have error handling code that restarts the AAA session from scratch in the rare instance of a collision.) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Jan 9 15:22:46 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 9 Jan 2003 07:22:46 -0800 (PST) Subject: [eap] Issue 66: Mandatory for who? In-Reply-To: <15901.34385.296721.792172@gargle.gargle.HOWL> Message-ID: > Bernard Aboba writes: > > "All EAP implementations MUST support the MD5-Challenge mechanism." > > > > Does this obligation extend to NASes operating in passthrough mode? > > In a sense, yes. The original text should have been unambiguous enough (an authenticator implements EAP whether it is in passthrough mode or not), but I would propose that we reword this to say: "Peers, authenticators and backend authentication servers implementing EAP MUST support the MD5-Challenge mechanism." Also, to clarify other issues relating to authenticator responsibilities, we can insert your suggested text: "The EAP authenticator is responsible for retransmitting Request messages. If the Request message is obtained from elsewhere (such as from a backend authentication server), then the authenticator will need to save a copy of the Request in order to accomplish this. The authenticator is also responsible for discarding Response messages with the wrong Identifier value before acting on them in any way, including passing them on to the backend authentication server for verification. Similarly, the peer is responsible for detecting and handling duplicate Request messages before processing them in any way, including passing them on to an outside party." From james.d.carlson@east.sun.com Thu Jan 9 16:49:07 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 11:49:07 -0500 Subject: [eap] Issue 66: Mandatory for who? In-Reply-To: Bernard Aboba's message of 9 January 2003 07:22:46 References: <15901.34385.296721.792172@gargle.gargle.HOWL> Message-ID: <15901.43011.888305.120195@gargle.gargle.HOWL> Bernard Aboba writes: > > In a sense, yes. > > The original text should have been unambiguous enough (an authenticator > implements EAP whether it is in passthrough mode or not), but > I would propose that we reword this to say: I think it still is unambiguous enough. I'm a little wary of documents that attempt to solve all conceivable interpretation mistakes. > "Peers, authenticators and backend authentication servers implementing > EAP MUST support the MD5-Challenge mechanism." I think that's too strict. The restriction is that the EAP Authenticator (which includes all of its internal implementation details, such as authentication mechanisms invoked) MUST support MD5-Challenge. Whether that support is in the EAP Authenticator or in the backend or in both is just not an issue here. There's no way to look at the messages on the wire between the Authenticator and Authenticatee and somehow know if the messages are generated by the Authenticator itself, or are being relayed from a secret backend authenticator somewhere. The reason that this requirement was added was for interoperability. There needs to be at least one common authentication algorithm that all are known to speak, or there will be cliques of implementations that cannot interoperate. So, the issue is that from the point of view of the EAP Authenticatee, it must be *possible* for him to prove his identity with MD5-Challenge. (In a given deployment, that ability might will be disabled for security reasons, but the implementations themselves MUST allow it to be enabled in some manner.) > Also, to clarify other issues relating to authenticator responsibilities, > we can insert your suggested text: > > "The EAP authenticator is responsible for retransmitting Request messages. > If the Request message is obtained from elsewhere (such as from a > backend authentication server), then the authenticator will need to > save a copy of the Request in order to accomplish this. The > authenticator is also responsible for discarding Response messages > with the wrong Identifier value before acting on them in any way, > including passing them on to the backend authentication server for > verification. Similarly, the peer is responsible for detecting and > handling duplicate Request messages before processing them in any > way, including passing them on to an outside party." OK, but I think it should be distinguished as an implementation note. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From jrv@umich.edu Thu Jan 9 16:55:39 2003 From: jrv@umich.edu (jrv@umich.edu) Date: Thu, 9 Jan 2003 11:55:39 -0500 Subject: [eap] Re: [Issue 61] Support for EAP Sequences In-Reply-To: <15901.36955.244588.228248@gargle.gargle.HOWL> References: <014a01c2b696$46dd40d0$a4c16540@amer.cisco.com> <15899.21554.770583.678905@gargle.gargle.HOWL> <1041985124.3e1b6e640e442@floatingbottle.mail.umich.edu> <15901.36955.244588.228248@gargle.gargle.HOWL> Message-ID: <1042131339.3e1da98bc68ef@ponyexpress.mail.umich.edu> Quoting James Carlson : > jrv@umich.edu writes: > > > Is suspect that fear need not be true for an implementation that was > > > exceedingly careful (that is, one that ran each authentication method > > > regardless of the intermediate result of each, and then sent Success > > > after *all* had been run only if all had passed). But given the > > > tendency for mistakes, and the likely uselessness of the "feature," it > > > seems reasonable to suggest that it's not a good idea. > > > > > I think the idea of sequences is useful when doing something in addition to > > > authentication. E.g. a method that negotiates QOS. Then the negotiation > for > > authenication method can be done, and if that method succeeds, an attempt > to do > > the QOS method can be made. If the peer accepts the method, it will get to > > > negotiate - if not it gets some default settings. > > Despite the fact that I'm a little uncomfortable with putting > authorization negotiation (such as QoS) into the middle of an > authentication protocol, hat's a good example because it shows the > depth of the problem in trying to define *anything* about sequences in > a "generic" way in this draft. > > Let's suppose you have a QoS negotiation, and the EAP Authenticatee > has never heard of it. Is failure of the "QoS method" a problem? > Almost certainly not -- it just means that the peer gets a default QoS > treatment. Does the unexpected method at the Authenticatee side pose > a problem? No, the Authenticatee just sends back a suitable Nak, and > the Authenticator (and the designer of this new method) must be smart > enough to know what to do next. > > While the concept is useful in implementation, and it's certainly > useful in designing particularly squirrelly methods, I don't see that > it has any place in the EAP specification itself. The EAP > Authenticator holds its cards pretty closely; all it reveals is the > sequence of Request messages it sends. More to the point, the EAP > Authenticatee cannot assume anything about method sequencing, because > it's not in control of the conversation. > > So, since the Authenticator doesn't reveal its intentions except by > Request messages, and the Authenticatee, which is required to respond > to all requests, cannot care about those intentions, I think the issue > is irrelevant at this level. Clearly, useful methods will likely have > to address issues here, but EAP itself doesn't. > > (For instance, an EAP method should probably describe what, if > anything, a client must store between Requests, and what, if anything, > an intervening Request with a different Type might mean. I think that > well-written methods would not change internal state based on the > activities of any other Types seen, but other method designers are > free to be strange. Additionally, a method designer must describe > what, if anything special, an implementation is required to do on > seeing Success. If the method includes mutual authentication, then > the definition of the method should say something like this: "the link > MUST be terminated if the peer sends EAP Success and the client method > state machine is not in final state AuthGood.") > > What meanful generic requirements on EAP could be imposed with regard > to sequencing? Since it's all so dependent on what the method does > and how, I'm at a loss to describe what that requirement must be. > Saying "MUST NOT send a Request with a new Type until the last method > is done" seems vacuous to me. It only means something with a method > that has a state like that, and the general truth of it seems pretty > sketchy. > > > > And what would the peer do with them? They seem to be the protocol > > > equivalent of having the peer say, "yes, yes, I see; do go on." > > > > > > > I agree again. I think a success or failure should end a sequence. If > methods > > are implemented to send success or failure, then these implementations > can't do > > method sequences for the reasons that James Carlson suggests. > > Since "methods" are entirely internal to an EAP implementation, one > could imagine that the "Success" message is filtered out at the EAP > level and sent only when the "sequence" is complete. Needless to say, > this is just an implementation strategy and has nothing to do with the > protocol on the wire. > I think of methods differently. I think they are entities in themselves. In order to do sequences of methods one needs know when they are done and whether they succeeded or failed. This is different from whether a sequence of methods succeeded or failed. For implementations to interoperate when sequences are possible, some set of rules must be agreed on what success for a sequence means, and who can decide. My proposal, which is not the only possible solution, is that 1. the authenticator be the driver, and that it can select any sequence of methods it desires. 2. the peer can NAK any method(s) 3. Each end must have some criteria for a minimum set of methods that must be completed in order to succeed, and be able to indicate success or failure to the lower layer 4. the authenticator may request 'optional' methods which the peer may NAK. There are probably some other rules needed. The intent is to provide a set of rules for sequences which, if followed, will allow adding methods to existing sequences without breaking peer implementations that don't do sequences. I am interested in comments of whether people think this is a reasonable goal, and if so, whether the proposed set of rules would satisfy them. John Vollbrecht From aboba@internaut.com Thu Jan 9 15:56:43 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 9 Jan 2003 07:56:43 -0800 (PST) Subject: [eap] Proposed resolution to Issue 66: Mandatory for who? Message-ID: On re-reading RFC 2284, it would appear to me that the document is relatively clear about the obligations of peer and authenticator EAP implementations. Rarely is the term "authenticator" used when "backend authentication server" is intended. To make this crystal clear, I would propose the following resolution to this issue: In Section 1, add: "Within this document, authenticator requirements apply regardless of whether the authenticator is operating as a pass-through. Where the requirement is meant to apply to either the authenticator or backend authentication server, depending on where the EAP authentication is terminated, the term "EAP server" will be used." In Section 1.2, add: "EAP Server The entity that terminates the EAP authentication with the peer. In the case where there is no backend authentication server, this term is synonymous with "authenticator". Where the authenticator operates in pass-through, it is synonymous with "backend authentication server". In Section 5.4, change: "All EAP implementations MUST support the MD5-Challenge mechanism." To: "EAP peers, authenticators and backend authentication servers MUST support the MD5-Challenge mechanism." Add in Section 4.1: "These obligations apply regardless of whether pass-through is implemented. The EAP authenticator is responsible for retransmitting Request messages. If the Request message is obtained from elsewhere (such as from a backend authentication server), then the authenticator will need to save a copy of the Request in order to accomplish this. The authenticator is also responsible for discarding Response messages with the wrong Identifier value before acting on them in any way, including passing them on to the backend authentication server for verification. Similarly, the peer is responsible for detecting and handling duplicate Request messages before processing them in any way, including passing them on to an outside party." ------------------------------------------------------------------------ Issue 66: Mandatory for who? Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: January 8, 2003 Document: http://mail.frascone.com/pipermail/eap/2003-January/000514.html Comment type: T Priority: S Section: 3.4 Rationale/Explanation of issue: RFC 2284, Section 3.4 states: "All EAP implementations MUST support the MD5-Challenge mechanism." Does this obligation extend to NASes operating in passthrough mode? For example, MUST they be able to authenticate a local user via EAP MD5? Going further, do obligations of authenticators (such as dropping duplicate Requests) extend to NASes operating in passthrough? Who is the authenticator in this case? The NAS? The AAA server? Both? From james.d.carlson@east.sun.com Thu Jan 9 17:16:54 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 12:16:54 -0500 Subject: [eap] Re: [Issue 61] Support for EAP Sequences In-Reply-To: jrv@umich.edu's message of 9 January 2003 11:55:39 References: <014a01c2b696$46dd40d0$a4c16540@amer.cisco.com> <15899.21554.770583.678905@gargle.gargle.HOWL> <1041985124.3e1b6e640e442@floatingbottle.mail.umich.edu> <15901.36955.244588.228248@gargle.gargle.HOWL> <1042131339.3e1da98bc68ef@ponyexpress.mail.umich.edu> Message-ID: <15901.44678.294136.452411@gargle.gargle.HOWL> jrv@umich.edu writes: > I think of methods differently. I think they are entities in themselves. In > order to do sequences of methods one needs know when they are done and whether > they succeeded or failed. This is different from whether a sequence of methods > succeeded or failed. They may be distinct entities or may not; it doesn't matter for the bits that end up on the wire. The glue between methods and EAP (and, perhaps, among methods) is an implementation artifact. > For implementations to interoperate when sequences are possible, some set of > rules must be agreed on what success for a sequence means, and who can decide. Agreed. The point I'm trying to make is that EAP itself is not a good choice of places to define this. The methods themselves would be a much better place. > My proposal, which is not the only possible solution, is that > > 1. the authenticator be the driver, and that it can select any sequence of > methods it desires. > 2. the peer can NAK any method(s) > 3. Each end must have some criteria for a minimum set of methods that must be > completed in order to succeed, and be able to indicate success or failure to > the lower layer > 4. the authenticator may request 'optional' methods which the peer may NAK. I agree with all of that. However, none of that text actually constrains sequencing in any way. For instance, suppose I have two methods, called "A" and "B". "B" is a single request-response method, such as MD5-Challenge. "A" is a more complex method that requires two separate exchanges; we'll call them A1 and A2. (Presumably, these are subtypes identified in the payload itself; that's just a detail.) The following sequence is compliant with your proposal: Authenticator Authenticatee Request Type=A1 -> <- Response Type=A1 Request Type=B -> <- Response Type=B Request Type=A2 -> <- Response Type=A2 Success -> > There are probably some other rules needed. The intent is to provide a set of > rules for sequences which, if followed, will allow adding methods to existing > sequences without breaking peer implementations that don't do sequences. > > I am interested in comments of whether people think this is a reasonable goal, > and if so, whether the proposed set of rules would satisfy them. I think this can be loosened to the point where no special sequencing rules at all are necessary. I *think* we can agree that the only real issue that arises is with methods that use multiple rounds of messaging (such as "A" above). Those that consist of single rounds (such as "B") cannot have any problem, because there's no way to force anything in the middle. (If we can't agree on this, then please explain how a composition of single-round methods requires a special rule.) So, for those that require multiple rounds of Request messages, we state that each method MUST keep its own internal, independent, inter-Request state required to complete the method-specified authentication process. At a minimum, this consists of the next expected message sub-type, and most such methods are expected to keep far more state storage than that. As an Authenticatee, the arrival of a Request with a Type value that belongs to a different method MUST still be processed, even if the previous Request invoked a multi-stage method that is not yet complete, and MUST NOT affect any other method that has not yet completed. Finally, as an Authenticatee, if a Success message is received, and any methods invoked are in a method-specific state such that making the link available for network traffic is impossible (e.g., the method employs mutual authentication, and the Authenticatee has not been able to validate the Authenticator's identity), then the link MUST be terminated. The link MAY be terminated by the Authenticatee at any time and for any reason. With the above text, I think the whole sequencing issue goes away. It becomes a local policy matter. (With the distinct benefit that the logic above is compatible with RFC 2284, while the logic necessary to enforce just about any sort of sequencing among the Request messages would appear to impose stricter requirements than appeared in the RFC and thus be incompatible.) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From james.d.carlson@east.sun.com Thu Jan 9 17:26:13 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 12:26:13 -0500 Subject: [eap] Proposed resolution to Issue 66: Mandatory for who? In-Reply-To: Bernard Aboba's message of 9 January 2003 07:56:43 References: Message-ID: <15901.45237.64320.886800@gargle.gargle.HOWL> Bernard Aboba writes: > In Section 1.2, add: > > "EAP Server > > The entity that terminates the EAP authentication with the peer. > In the case where there is no backend authentication server, this > term is synonymous with "authenticator". Where the authenticator > operates in pass-through, it is synonymous with > "backend authentication server". OK. > In Section 5.4, change: > > "All EAP implementations MUST support the MD5-Challenge mechanism." > > To: > > "EAP peers, authenticators and backend authentication servers > MUST support the MD5-Challenge mechanism." I still think that's too strong. An EAP Authenticator implementation that *always* does pass-through and *always* uses a backend mechanism that supports MD5-Challenge would thus be rendered non-compliant. > Add in Section 4.1: > > "These obligations apply regardless of whether pass-through > is implemented. The EAP authenticator is responsible for > retransmitting Request messages. If the Request message is > obtained from elsewhere (such as from a backend authentication > server), then the authenticator will need to > save a copy of the Request in order to accomplish this. The > authenticator is also responsible for discarding Response messages > with the wrong Identifier value before acting on them in any way, > including passing them on to the backend authentication server for > verification. Similarly, the peer is responsible for detecting and > handling duplicate Request messages before processing them in any > way, including passing them on to an outside party." OK. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Jan 9 16:28:21 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 9 Jan 2003 08:28:21 -0800 (PST) Subject: [eap] Proposed resolution to Issue 66: Mandatory for who? In-Reply-To: <15901.45237.64320.886800@gargle.gargle.HOWL> Message-ID: > I still think that's too strong. An EAP Authenticator implementation > that *always* does pass-through and *always* uses a backend mechanism > that supports MD5-Challenge would thus be rendered non-compliant. Since the original RFC 2284 text uses the words "EAP implementation", it's hard to argue that an authenticator operating in pass-through mode doesn't implement EAP. So it seems to me that the obligation applies. I'd also note that there may be sound technical reasons for it to apply. An EAP implementation that doesn't support the mandatory-to-implement authentication method is incapable of operating without a backend authentication server, an optional feature of EAP. Encouraging the creation of devices like that is a bad idea, because interoperability is then not guaranteed in a number of scenarios. For example, even if the device might operate in pass-through for peers, it might want to authenticate a device on another interface. An example is a switch, which might need to authenticate another switch on a trunk port. Although it operates purely in pass-through for peers, to authenticate another switch, it needs to implement the mandatory method. > > > Add in Section 4.1: > > > > "These obligations apply regardless of whether pass-through > > is implemented. The EAP authenticator is responsible for > > retransmitting Request messages. If the Request message is > > obtained from elsewhere (such as from a backend authentication > > server), then the authenticator will need to > > save a copy of the Request in order to accomplish this. The > > authenticator is also responsible for discarding Response messages > > with the wrong Identifier value before acting on them in any way, > > including passing them on to the backend authentication server for > > verification. Similarly, the peer is responsible for detecting and > > handling duplicate Request messages before processing them in any > > way, including passing them on to an outside party." > > OK. > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > From james.d.carlson@east.sun.com Thu Jan 9 18:42:30 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 13:42:30 -0500 Subject: [eap] Proposed resolution to Issue 66: Mandatory for who? In-Reply-To: Bernard Aboba's message of 9 January 2003 08:28:21 References: <15901.45237.64320.886800@gargle.gargle.HOWL> Message-ID: <15901.49814.186867.514759@gargle.gargle.HOWL> Bernard Aboba writes: > > I still think that's too strong. An EAP Authenticator implementation > > that *always* does pass-through and *always* uses a backend mechanism > > that supports MD5-Challenge would thus be rendered non-compliant. > > Since the original RFC 2284 text uses the words "EAP implementation", it's > hard to argue that an authenticator operating in pass-through mode doesn't > implement EAP. So it seems to me that the obligation applies. Not so hard for me -- the "EAP implementation" in this context encompasses the NAS innards as well as the capabilities and issues of the backend security system. As I said before, the rationale for this requirement was to ensure the *possibility* of interoperability between EAP Authenticatees and EAP Authenticators. It doesn't, and by design cannot, ensure this interoperability in any particular deployment. For instance, I might disable MD5-Challenge support through an administrative interface. Or I might just neglect to put any credentials at all into the MD5-Challenge authentication database. The possibility of these scenarios doesn't negate the requirement. > I'd also note that there may be sound technical reasons for it to apply. > An EAP implementation that doesn't support the mandatory-to-implement > authentication method is incapable of operating without a backend > authentication server, an optional feature of EAP. I disagree with that. It may well make perfect sense for *SOME* implementors to create EAP Authenticators that are incapable of operation without a backend service. This is no different from the situation the customer has when he unwraps the shrink-wrap on his brand-new EAP Authenticator with built-in MD5-Challenge -- that new box can't possibly already have all the client keys hard-coded into it, so it's not "interoperable" by the standards you're asserting. Consider, for example, an access device that has *no* local storage whatsoever. It has an EAP Authenticator and a AAA Client burned into ROM, and has no provision for use in any other way. Are we really trying to say that such a device is "illegal" by this standard? Why? I think all of this is missing the point. The point is that from the point of view of the *wire*, it must be the case that the implementations on each end of that wire *can* be configured such that they are willing to support MD5-Challenge. If there's magic that happens within or behind the implementation, whether that's user prompting, file reading, Tarot cards, AAA access, SQL queries, or anything else, that's immaterial. Think of it as a software version of a Thevenin equivalent. ;-} > Encouraging the > creation of devices like that is a bad idea, because interoperability is > then not guaranteed in a number of scenarios. Interoperability failure is already guaranteed in the scenario where the Authenticatee doesn't have the right credentials to authenticate to the Authenticator. How is this lack-of-implementation-required- backend situation substantially different? I don't think that it is. If your authentication database is unavailable, you're not going to be able to do too many good things. Suppose I have an EAP Authenticator implementation that *DOES* include MD5-Challenge. However, the implementation is designed such that it *MUST* be configured with the address of a TFTP server that gives access to the credentials for authentication. Note that EAP is terminated right on this device, and the inclusion of MD5-Challenge in this implementation makes it "compliant" with the RFC requirements. Suppose now that that TFTP server is down. Does this hypothetical implementation fail the RFC test? > For example, even if the device might operate in pass-through for peers, > it might want to authenticate a device on another interface. An example is > a switch, which might need to authenticate another switch on a trunk port. > Although it operates purely in pass-through for peers, to authenticate > another switch, it needs to implement the mandatory method. I assume you're saying that the pass-through AAA data flows over that trunk port, and thus the implementor ends up with a chicken-and-egg problem in authenticating that trunk port since he can't pass his AAA data yet. That's an implementation error. Such an implementation must either provide an alternative mechanism for that trunk port, or simply not authenticate that port with EAP. I don't think legislating intelligence on the part of designers is likely to be successful. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Jan 9 17:57:13 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 9 Jan 2003 09:57:13 -0800 (PST) Subject: [eap] Proposed resolution to Issue 66: Mandatory for who? In-Reply-To: <15901.49814.186867.514759@gargle.gargle.HOWL> Message-ID: > Not so hard for me -- the "EAP implementation" in this context > encompasses the NAS innards as well as the capabilities and issues of > the backend security system. Maybe this use of "implementation" is a special case where it refers to the peer and EAP server implementations (wherever the EAP server is implemented). Elsewhere in RFC 2284, where the word is used, it seems to apply to the peer and authenticator alone: "If authentication of the link is desired, an implementation MUST specify the Authentication-Protocol Configuration Option during Link Establishment phase." or "silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter." > unless it affects on the wire... If you go down this road, then it's hard to simultaneously argue that the duplicate elimination problem can be resolved by requiring the authenticator to behave the same way regardless of whether it is in pass-through mode or not. After all, from an on-the-wire perspective, the conversation between peer and authenticator looks the same either way, right? From james.d.carlson@east.sun.com Thu Jan 9 19:15:47 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 14:15:47 -0500 Subject: [eap] Proposed resolution to Issue 66: Mandatory for who? In-Reply-To: Bernard Aboba's message of 9 January 2003 09:57:13 References: <15901.49814.186867.514759@gargle.gargle.HOWL> Message-ID: <15901.51811.52932.985690@gargle.gargle.HOWL> Bernard Aboba writes: > > Not so hard for me -- the "EAP implementation" in this context > > encompasses the NAS innards as well as the capabilities and issues of > > the backend security system. > > Maybe this use of "implementation" is a special case where it refers to > the peer and EAP server implementations (wherever the EAP server is > implemented). > > Elsewhere in RFC 2284, where the word is used, it seems to apply to the > peer and authenticator alone: > > "If authentication of > the link is desired, an implementation MUST specify the > Authentication-Protocol Configuration Option during Link > Establishment phase." No, I can't follow you there. The implementation MUST issue this message, because it's the only thing attached to the L2 link. What that text doesn't say -- and can't say -- is how the "desire" is determined. That may well involve access to policy databases that are not coresident with the EAP implementation. > "silently discard > This means the implementation discards the packet without > further processing. The implementation SHOULD provide the > capability of logging the error, including the contents of > the silently discarded packet, and SHOULD record the event > in a statistics counter." > > > unless it affects on the wire... > > If you go down this road, then it's hard to simultaneously argue that the > duplicate elimination problem can be resolved by requiring the > authenticator to behave the same way regardless of whether it is in > pass-through mode or not. After all, from an on-the-wire perspective, the > conversation between peer and authenticator looks the same either way, > right? Right. This is exactly why I've also consistently argued that specifying how pass-through might work is merely an *implementation* guideline, and not specifically an EAP issue. "If you're doing this, here's what we think the best, but perhaps not only, strategy might be." Note also that it's a good guideline because the way DIAMETER works actually *prevents* it from ever doing the Request retransmissions itself. There's no way for a DIAMETER server (at least that I know of) to send an unbidden "answer" that would be required to implement such a thing. Even if it were possible, it's passing strange that the DIAMETER server somehow "knows" the link characteristics of that client 1,000 miles away. As long as retransmissions are in the NAS, it seems questionable at best to have "duplicate" (really: wrong Identifier) detection of the Reponses done anywhere else. Plus, of course, relaying along data that you rightfully know to be garbage (Response Identifier != last sent Request) is just a bad plan. It serves no purpose at all. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Jan 9 18:22:43 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 9 Jan 2003 10:22:43 -0800 (PST) Subject: [eap] Proposed resolution to Issue 66: Mandatory for who? In-Reply-To: <15901.51811.52932.985690@gargle.gargle.HOWL> Message-ID: > No, I can't follow you there. The implementation MUST issue this > message, because it's the only thing attached to the L2 link. What > that text doesn't say -- and can't say -- is how the "desire" is > determined. That may well involve access to policy databases that are > not coresident with the EAP implementation. OK. I think the answer is that a device which does pass-through only, need not implement the mandatory method. However, one which implements both pass-through and local authentication does need to implement the mandatory method. Does that make sense? > Right. This is exactly why I've also consistently argued that > specifying how pass-through might work is merely an *implementation* > guideline, and not specifically an EAP issue. "If you're doing this, > here's what we think the best, but perhaps not only, strategy might > be." Yes. Specifying the operation of pass-through is the job of RFC 2869bis. > Note also that it's a good guideline because the way DIAMETER works > actually *prevents* it from ever doing the Request retransmissions > itself. Yes. > Even if it were possible, it's passing strange that the > DIAMETER server somehow "knows" the link characteristics of that > client 1,000 miles away. The issue does come up though, where the EAP packet is potentially larger than the link MTU. In that case the Diameter or RADIUS server needs to figure out what the link MTU is, so as to limit the packet size appropriately. This is usually accomplished via a "hint" from the NAS. > Plus, of course, relaying along data that you rightfully know to be > garbage (Response Identifier != last sent Request) is just a bad plan. > It serves no purpose at all. Yes. From james.d.carlson@east.sun.com Thu Jan 9 19:56:24 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 14:56:24 -0500 Subject: [eap] Proposed resolution to Issue 66: Mandatory for who? In-Reply-To: Bernard Aboba's message of 9 January 2003 10:22:43 References: <15901.51811.52932.985690@gargle.gargle.HOWL> Message-ID: <15901.54248.680584.988168@gargle.gargle.HOWL> Bernard Aboba writes: > > No, I can't follow you there. The implementation MUST issue this > > message, because it's the only thing attached to the L2 link. What > > that text doesn't say -- and can't say -- is how the "desire" is > > determined. That may well involve access to policy databases that are > > not coresident with the EAP implementation. > > OK. I think the answer is that a device which does pass-through only, need > not implement the mandatory method. However, one which implements both > pass-through and local authentication does need to implement the mandatory > method. Does that make sense? That's a good issue. I'd have to say that as long as the backend authentication mechanism (pass-through or otherwise) is one that can allows the use of MD5-Challenge (i.e., the underlying AAA protocol has some support for it), then this would fulfill the requirement. If one picked a mechanism (e.g., NIS) that didn't, then that would be a problem. > > Right. This is exactly why I've also consistently argued that > > specifying how pass-through might work is merely an *implementation* > > guideline, and not specifically an EAP issue. "If you're doing this, > > here's what we think the best, but perhaps not only, strategy might > > be." > > Yes. Specifying the operation of pass-through is the job of RFC 2869bis. That sounds right to me. > > Even if it were possible, it's passing strange that the > > DIAMETER server somehow "knows" the link characteristics of that > > client 1,000 miles away. > > The issue does come up though, where the EAP packet is potentially larger > than the link MTU. In that case the Diameter or RADIUS server needs to > figure out what the link MTU is, so as to limit the packet size > appropriately. This is usually accomplished via a "hint" from the NAS. Agreed, though that's a slightly different issue. The link MTU is generally pretty simple. It doesn't change much. The RTT may vary wildly, depending on conditions. Plus, as noted before, the AAA connection itself has its own reliability. So, what you'd end up with is one retransmission-based reliable protocol (EAP) running atop another (AAA), with one having the RTT of the AAA connection, and the other having the RTT of the link plus the AAA connection. If the link RTT is very small in comparison to the AAA RTT, which is probably a very likely scenario, then you have two protocols run atop each other with commensurate RTTs. That's bad news; it'll oscillate. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Jan 9 19:00:03 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 9 Jan 2003 11:00:03 -0800 (PST) Subject: [eap] Issues 49 & 62: Strawman Section 4.2.1 Message-ID: In 2002, a University of Maryland team, lead by Bill Arbaugh, the EAP WG Security Advisor, found a security flaw in the IEEE 802.1X state machine that allowed a rogue authenticator to convince the peer to bypass mutual authentication. This involved sending an EAP Success in the middle of a mutually authenticating EAP method such as EAP TLS, prior to when the authenticator would provide its credentials. As described in the ESTEEM document, the EAP State Machine Design Team has been debating how to handle this. I've struggled to come up with appropriate text that doesn't seem too clumsy or impose too many requirements on the implementation. The text below is not very good, but I thought I'd send it to the list anyway, so that we get started in improving it. The basic idea is to cause the peer to silently discard EAP Success or Failure packets that arrive in the middle of an EAP conversation, as well as to require consistency between those indications and any method specific result indications that may have previously arrived. ===================================================================== 4.2.1. Processing of success and failure Within EAP, success and failure indications may be protected or unpro- tected. Unless protected by an underlying link layer ciphersuite, EAP Success and Failure packets are unprotected indications which may be spoofed, since they contain no embedded message integrity check. However, EAP methods MAY include support for acknowledged and protected success and failure indications. This enables the authenticator to indi- cate whether the peer has successfully authenticated to it, as well as for the peer to acknowledge receipt, and to indicate whether the authen- ticator has successfully authenticated to it. If a key has previously been derived, these messages MAY be protected by a Message Integrity Check (MIC). Where a protected success/failure indication has been received at the EAP layer by an EAP peer, it MUST accept and process the protected indi- cation. The following mechanisms are available to protect against spoofing of unprotected success and failure indications: [a] Link layer ciphersuite. If a link layer ciphersuite providing integrity protection is in use, then spoofed EAP Success or Failure packets can be detected and silently discarded by the link layer. [b] Message validation. EAP Failure and Success messages are never sent by the EAP peer, only the authenticator. Therefore, EAP Failure and Success messages received by the authenticator MUST be silently discarded. [c] Mandatory authentication. Whether authentication is mandatory is determined by the authenticator and peer configurations. If authen- tication is not required by the authenticator, or if the identity of the peer is verified by another mechanism (e.g. Calling-Station- ID or MAC address), then the authenticator MAY send a "canned" EAP Success message. These messages are highly vulnerable to spoofing. However, the peer may be configured to require the authenticator to authenticate itself prior to being willing to process an unpro- tected EAP Success message. [d] Completion indications. An EAP method requesting transmission of an EAP messsage by the EAP layer SHOULD indicate whether the message represents completion of the EAP conversation. A peer EAP implemen- tation that has not yet received a completion indication MUST silently discard unprotected EAP Success packets and SHOULD silently discard EAP Failure packets. [e] Method indications. An EAP method supporting protected success and failure indications MAY indicate to the EAP layer the authentica- tion status in each direction: SUCCESS, FAILURE or UNKNOWN, as part of the message transport primitive. An EAP method indicating an authentication FAILURE in either direction MUST cause the EAP layer to silently discard unprotected EAP Success packets. The EAP con- versation MUST also be unsuccessfully terminated. An EAP method indicating authentication SUCCESS in both directions SHOULD cause the EAP layer to silently discard unprotected EAP Failure packets. In the absence of the above mechanisms, unprotected failure indications MAY be accepted and processed by the peer EAP layer. This can result in a denial of service attack. From james.d.carlson@east.sun.com Thu Jan 9 21:13:13 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 9 Jan 2003 16:13:13 -0500 Subject: [eap] Issues 49 & 62: Strawman Section 4.2.1 In-Reply-To: Bernard Aboba's message of 9 January 2003 11:00:03 References: Message-ID: <15901.58857.866944.693008@gargle.gargle.HOWL> Bernard Aboba writes: > The basic idea is to cause the peer to silently discard EAP Success or > Failure packets that arrive in the middle of an EAP conversation, as well > as to require consistency between those indications and any method > specific result indications that may have previously arrived. First, I think that EAP Failure MUST NOT be discarded at any time. If you get one, then the peer is clearly trying to tell you something. It's not a security risk because you're not going to enable the link because of it. If you're worried about spoofed EAP Failure as a DoS, I think the only way to win there is with some sort of link security -- a MIC or something equivalent. Since a *proper* (i.e., one from the Authenticator) EAP Success or Failure is the very last message you'll get from the EAP peer (well, other than far-future rechallenges, if any), there seems to me to be some badness in ignoring this message. You'll need to have some sort of crufty timeout to say, "well, I got Success, and I didn't expect it, and no other Requests showed up; shutting down now." Otherwise, this invokes the possibility of a deadlock: if an Authenticator sends Success (and *really* means it), but the Authenticatee doesn't "expect" it, the link is left in limbo. So, I think the right thing to do is to say (as we already have) that if the Authenticatee gets EAP Success and (for any reason) doesn't like that message, then it disconnects. If you have a MIC, or some other way of guaranteeing that messages on the link can't be forged, you can clearly avoid this problem without having to change anything. Note also that if you get an unexpected EAP Success this means that (A) the peer is an idiot and doesn't implement the chosen method correctly or (B) someone is attacking you. Either way, failing out the link sounds like the right sort of handling. > 4.2.1. Processing of success and failure > > Within EAP, success and failure indications may be protected or unpro- > tected. Unless protected by an underlying link layer ciphersuite, ^^^^^^^^^^^^^^^^^^^^^^ I think that's a little too strong. Unless the link itself is known to have sufficient security, which might consist of physical or cryptographic methods, then the messages received might be spoofed. The analysis for each medium will almost certainly differ in some respects, perhaps even for different deployments. > However, EAP methods MAY include support for acknowledged and protected > success and failure indications. This enables the authenticator to indi- > cate whether the peer has successfully authenticated to it, as well as > for the peer to acknowledge receipt, Receipt of what? > and to indicate whether the authen- > ticator has successfully authenticated to it. If a key has previously > been derived, these messages MAY be protected by a Message Integrity > Check (MIC). This should probably say something about where the MIC goes. There's no provision in EAP for this, so it has to be an L2 issue, right? > Where a protected success/failure indication has been received at the > EAP layer by an EAP peer, it MUST accept and process the protected indi- > cation. I think "protected success/failure" isn't well enough defined. Is this a method-specific Request/Response exchange? Is it an EAP Success message where the implementation happens to have independent knowledge that the link layer is "acceptably secure?" Is it a new message entirely? > [a] Link layer ciphersuite. If a link layer ciphersuite providing > integrity protection is in use, then spoofed EAP Success or Failure > packets can be detected and silently discarded by the link layer. Actually, *all* spoofed messages, including EAP Success or Failure, can be detected, right? > [b] Message validation. EAP Failure and Success messages are never sent > by the EAP peer, only the authenticator. Therefore, EAP Failure and > Success messages received by the authenticator MUST be silently > discarded. That disallows bidirectional authentication. > [c] Mandatory authentication. Whether authentication is mandatory is > determined by the authenticator and peer configurations. If authen- > tication is not required by the authenticator, or if the identity > of the peer is verified by another mechanism (e.g. Calling-Station- > ID or MAC address), then the authenticator MAY send a "canned" EAP > Success message. These messages are highly vulnerable to spoofing. > However, the peer may be configured to require the authenticator to > authenticate itself prior to being willing to process an unpro- > tected EAP Success message. Actually, I think that the Authenticatee ought to disconnect rather than just leave "unprocessed" this unexpected EAP Success message. If it's expecting some sort of authentication that the peer isn't providing, there's no sense in ignoring the condition. Alerting a human (or an administrator) is the only way out. > [d] Completion indications. An EAP method requesting transmission of an > EAP messsage by the EAP layer SHOULD indicate whether the message > represents completion of the EAP conversation. A peer EAP implemen- > tation that has not yet received a completion indication MUST > silently discard unprotected EAP Success packets and SHOULD > silently discard EAP Failure packets. I disagree with both parts of that for different reasons. EAP Failure before the method is complete is entirely possible. It means "go away" and could be the result of administrative reset. EAP Success before the method is complete depends on the method, and I don't think (except by convention) that it needs to be "indicated" anywhere in the message itself; just in the method documentation. In this case, the prudent thing to do is to shut down: you're under active attack, so stop. > [e] Method indications. An EAP method supporting protected success and > failure indications MAY indicate to the EAP layer the authentica- > tion status in each direction: SUCCESS, FAILURE or UNKNOWN, as part > of the message transport primitive. An EAP method indicating an > authentication FAILURE in either direction MUST cause the EAP layer > to silently discard unprotected EAP Success packets. The EAP con- > versation MUST also be unsuccessfully terminated. An EAP method > indicating authentication SUCCESS in both directions SHOULD cause > the EAP layer to silently discard unprotected EAP Failure packets. I think that's basically an implementation choice for (d). > In the absence of the above mechanisms, unprotected failure indications > MAY be accepted and processed by the peer EAP layer. This can result in > a denial of service attack. It's one of several different DoSes available (including Requests with rotating Identifier values), and perhaps not even the most effective one. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Thu Jan 9 21:50:33 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 9 Jan 2003 13:50:33 -0800 (PST) Subject: [eap] New Supplicant Back-end Machine proposal (fwd) Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ------_=_NextPart_000_01C2B82F.021A0AB0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: ---------- Forwarded message ---------- Date: Thu, 9 Jan 2003 14:32:35 -0800 From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'jrv@umich.edu'" , "CONGDON,PAUL (HP-Roseville,ex1)" , Robert Moskowitz , James Burns Cc: 'Tony Jeffree' , 'Bernard Aboba' , gwz@cisco.com Subject: New Supplicant Back-end Machine proposal Not the greatest write-up, but hopefully somewhat helpful.... 802.1X Supplicant to EAP Switch Interface ----------------------------------------- Attached is a new proposed 802.1X supplicant backend that is intended to interface with the EAP Peer switch layer. This machine is intended to replace the current supplicant backend machine in 802.1aa/D4. The following are notes about how this works: Goals ----- 1. To provide a packet handshake interface to the EAP layer that supports the actions of the EAP layer 2. To remove interpretation and action upon EAP packets within 802.1X (for the most part) 3. To do so without completely re-writing the rest of the supplicant machines 4. To give the EAP layer complete decision power over the authentication state of the supplicant Key Observations ---------------- 1. The eapSuccess and eapFailure variables have been completely removed from the supplicant. These variables were set true when an EAP-Success or EAP-Failure message were received. The EAP layer is now responsible for interpreting and acting upon EAP-Success and EAP-Failure messages. 2. Each EAP packet received by the supplicant is handed to the EAP layer one-by-one. The EAP layer handshakes each packet using a set of variables. The EAP layer will either respond to the supplicant backend with an indication to send an EAP-response packet, or an indication that no response will be coming. In the later case, the EAP layer is either silently discarding the EAP frame or a response frame is not necessary. 3. The EAP layer determines the if the sequence succeeds or fails and informs the supplicant machines by setting the global variables suppSuccess or suppFail. Other Ramifications ------------------- 1. The supplicant txKey machine must be slightly modified since the eapSuccess variable has been removed. The eapSuccess variable should simply be replaced by the suppSuccess variable. 2. The supplicant front-end machine must set suppStart when either an EAP-Request, EAP-Success or EAP-Failure packet is received. The suppStart variable is how the supplicant back-end machine is started. It currently only sets the suppStart variable when the initial EAP-Request is received from the authenticator. Basically, the suppStart variable should be set when any EAP message is received. New Variables and handshakes ---------------------------- suppRsp - a global variable set TRUE by the EAP layer when it is done processing a received EAP frame and intends to send an EAP-response frame back to the authenticator. The variable is set FALSE by the supplicant back-end after the response has been sent. suppNoRsp - a global variable set TRUE by the EAP layer when it is done process a received EAP frame but does not intend to send an EAP-response back. The variable is set FALSE by the supplicant back-end. eapRcvd - a variable that indicates an EAP packet has been received. In particular the supplicant should only really care about EAP-Request, EAP-Success and EAP-Failure messages. This variable replaces reqRcvd, eapSuccess and eapFail in the old machine. Old variables with new semantics or owners ------------------------------------------ suppSuccess - the global variable that the EAP layer sets to indicate it is 'done' and the result is a successful authentication. The supplicant front-end machine will transition into the authenticated state when this is set (and of course the port is valid). suppFail - the global variable that the EAP layer sets to indicate it is 'done' and the result was a faile authentication. This failure could be as a result of many things, but the supplicant backend machine doesn't really care. How things work --------------- 1. The supplicant front-end machine is virtually untouched. It works as it does today with the exception of setting suppStart when either an EAP-request, EAP-Success or EAP-Failure message are received. Basically, it initializes, send EAPOL-Start messages and waits for an initial message from the authenticator. When the initial message from the authenticator is received, the variable eapRcvd is set TRUE and suppStart is set TRUE and the back-end machine wakes up. 2. The backend machine has a frame available for the EAP layer anytime eapRcvd is set TRUE. It waits for an acknowledgement that the EAP layer is done working with the frame by looking for either suppRsp or suppNoRsp going TRUE. 3. If suppRsp goes TRUE, the supplicant sends an EAP-Response frame, restarts its timeout and waits for the next frame from the authenticator 4. If suppNoRsp goes TRUE, the supplicant simply restarts it timeout and waits for the next frame from the authenticator 5. if suppSuccess or suppFail go TRUE, the supplicant back-end is basically done 6. if the timeout pops, we haven't received the next EAP frame from the authenticator while in the authentication process, so we basically give-up and start over by sending EAPOL-Start frames. Paul ------_=_NextPart_000_01C2B82F.021A0AB0 Content-Type: APPLICATION/OCTET-STREAM; NAME="newSupplicantBackend.pdf" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="newSupplicantBackend.pdf" JVBERi0xLjINJeLjz9MNCjMgMCBvYmoNPDwgDS9MaW5lYXJpemVkIDEgDS9PIDUgDS9IIFsgNjE3 IDE1MiBdIA0vTCA0MDA0IA0vRSAzNjgxIA0vTiAxIA0vVCAzODI3IA0+PiANZW5kb2JqDSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTMgMTEgDTAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMDU2NCAwMDAwMCBuDQowMDAw MDAwNzY5IDAwMDAwIG4NCjAwMDAwMDA5MjAgMDAwMDAgbg0KMDAwMDAwMTA1MiAwMDAwMCBuDQow MDAwMDAxMjMyIDAwMDAwIG4NCjAwMDAwMDE2ODYgMDAwMDAgbg0KMDAwMDAwMTg2NSAwMDAwMCBu DQowMDAwMDAzNTM5IDAwMDAwIG4NCjAwMDAwMDA2MTcgMDAwMDAgbg0KMDAwMDAwMDc0OSAwMDAw MCBuDQp0cmFpbGVyDTw8DS9TaXplIDE0DS9JbmZvIDIgMCBSIA0vUm9vdCA0IDAgUiANL1ByZXYg MzgxOCANL0lEWzxiMDFmNWQ1ZjZhYTY3ODZiMWU5OTY0ZTJhMDM0Yzg3OD48YjAxZjVkNWY2YWE2 Nzg2YjFlOTk2NGUyYTAzNGM4Nzg+XQ0+Pg1zdGFydHhyZWYNMA0lJUVPRg0gICAgICANNCAwIG9i ag08PCANL1R5cGUgL0NhdGFsb2cgDS9QYWdlcyAxIDAgUiANPj4gDWVuZG9iag0xMiAwIG9iag08 PCAvUyAzNiAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEzIDAgUiA+PiANc3RyZWFtDQpI iWJgYOBkYGDKZAACbgUGbIADSgsAMTsUMzD4MXBzKtwwFm843Q/kAQQYAES5BEQNZW5kc3RyZWFt DWVuZG9iag0xMyAwIG9iag00OCANZW5kb2JqDTUgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFy ZW50IDEgMCBSIA0vUmVzb3VyY2VzIDYgMCBSIA0vQ29udGVudHMgMTAgMCBSIA0vTWVkaWFCb3gg WyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4g DWVuZG9iag02IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RU MiA4IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDExIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwg L0NzNSA5IDAgUiA+PiANPj4gDWVuZG9iag03IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0 b3IgDS9Bc2NlbnQgOTA1IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTEgDS9GbGFncyAzMiAN L0ZvbnRCQm94IFsgLTY2NSAtMzI1IDIwMjggMTAzNyBdIA0vRm9udE5hbWUgL0FyaWFsTVQgDS9J dGFsaWNBbmdsZSAwIA0vU3RlbVYgMCANPj4gDWVuZG9iag04IDAgb2JqDTw8IA0vVHlwZSAvRm9u dCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTI0IA0vV2lk dGhzIFsgMjc4IDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMjc4IDAgMCAwIDU1NiAwIDU1NiAw IDAgNTU2IDU1NiAwIDAgDTAgMCAwIDAgNTg0IDAgMCAwIDY2NyAwIDcyMiA3MjIgNjY3IDYxMSAw IDAgMjc4IDAgMCA1NTYgODMzIDcyMiANNzc4IDY2NyA3NzggNzIyIDY2NyA2MTEgNzIyIDY2NyA5 NDQgMCAwIDYxMSAwIDAgMCAwIDAgMCA1NTYgNTU2IA01MDAgNTU2IDU1NiAwIDU1NiA1NTYgMjIy IDAgMCAyMjIgODMzIDAgNTU2IDU1NiAwIDMzMyA1MDAgMjc4IDU1NiANNTAwIDAgNTAwIDAgMCAw IDI2MCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9BcmlhbE1UIA0v Rm9udERlc2NyaXB0b3IgNyAwIFIgDT4+IA1lbmRvYmoNOSAwIG9iag1bIA0vQ2FsUkdCIDw8IC9X aGl0ZVBvaW50IFsgMC45NTA1IDEgMS4wODkgXSAvR2FtbWEgWyAyLjIyMjIxIDIuMjIyMjEgMi4y MjIyMSBdIA0vTWF0cml4IFsgMC40MTI0IDAuMjEyNiAwLjAxOTMgMC4zNTc2IDAuNzE1MTkgMC4x MTkyIDAuMTgwNSAwLjA3MjIgMC45NTA1IF0gPj4gDQ1dDWVuZG9iag0xMCAwIG9iag08PCAvTGVu Z3RoIDE1OTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImEV0tv20YQvvNX8Lgs Kpr7Xh5ycB2ncOA4qUW3QOMcHFlJXNCQINlOD/nx/WYffEopDFjk7s7szHzzzQxPzvY6X+1z7v/2 q+zk9yXPv+4znj/kmXCm5ILnRslSqZxXLl9Yke/W2ZdfshMSPVvmVVlVavR/eQbxt9D3DxaEyr9D Mn+Xf/xU5fedTm150hlULrPfmuykaQQEmy+ZK0kf/vyDFFVpXGVyw2sSax6zyu/C5AXdakzerLDW fM8+suvzYsF5KdgfN+dL/yhZU3xq3tJZozjcEKV0Dhe9DuLSeXE81TrouHt+KnSp2Le/vj0UC11q 1oafdVGVnOWvCi5ZXiWtFVd1vuAlr1WnVMmBTV/XT4UqawZ7HH6et9vrvTfNsW2B44rdstvCqztv sg4PaWwIl9Q+XLKinx6FtK+MHOwPIjqOo+IwjOKouQE0FZ9HUtdkNQWRQod4sQ8wXLH3V+Fds/Pg tCqt5HIWSmWD/JM/rdi/hYCPSwTTkNdY1aVl1/vtLdut49tqjRgbHH7xh9f3F1H4/lfcrdl2RwfZ +iUe2zzvuxMUPJdCB1uUlDMgRIduHdDY7rwuDSSCrhpPXhVAfZUXnKDarVceIQvM/U6UeCkkXqKR kKKLOaKr3PRiqbuLRbh4H0JATiEE3VVvTgsDLy59dogY4WEeJNooYedUTJtS6wOcmjJJlIoyQFWO yDlnUj1nkmFn5+StwNOf8F6lHJjDL23nsuqZhPhGKtWJScozSfThjuc0+/aBooAI7x7CwY0/2AXa KjMLtOxuDZeu77bX3mDNVi/3wzhbdukBkMhJm/xAmgszI7D0RSWwwvT4XW2CascCgpSaHkAbAZQH AFRgpscoFLAxgGlTKPu/ACpjYA8AFDUVsxGA3mg1wK+5eFdw7Tm7oIL4vhAVu6GoulQRESItxBxH 00VU9q43HhHJHgMP1xtfJU0PYnN9czx5BZcl/DqcvFzxtHk8eSUAEvCdO1wmZr5rO/D94nWB1FWA u4aFKWFLbtTcW1Enb53tvEXIJFzaFpxSBZqeCFzD7nZPADsWCg/9wiLEl+HQ3H3njnfRuHe4G46d 52CuIOCNqOl96rwatsCLq8KXx4um4I5+TwM+l4WDqRchG/6OQcGzkPU8Beo+/WVfN31FUIyoLEHN hddLRZQS4z6+IzYiPuqiYiZxV9f2SHWOxeLzxvcEwRBkPeiWXXeEtLWGz7g6N5YS9pQUaPZ5s/PF xbJAWF8LCir6pwFTgGeG4CmJMon2qJUfYR77Be1RbPvOnBaW2XwU8sTXyLmgqTZDTaGlt5kCnphK 0ol2KtIOG33MlMf5/VTZxyfiAl0ogoVSqJIgpiVvTHcm9BVoQX2SpjvRTkXaUK+CC3Hq6H1SKvok dUjs+UIw5nF+AtaZamJdOtNZhw43tm4s4q2bMUdYlBhDU482JVXy2cwznNR8iY89eoMmHVIX6lUl CVZBQ0TMOq3CsLP3DSGOdUGiCgJUQ2CcI5E0CJDETVMIyc5SviUcYgvvgYn9os2E4ocXjK3GCTBf UC7GfHriSM4mzElwlCaxhvVpEk+0U5EjQBgyBECQPjfHQcVwUvcOs1eYtnhs/kRMVH4fBtwXiJkW pB1n2nxB658zFZ2IXCDVgalJdQq5ctx7HU+0U5HAVFVNoIwLApVYi5DpSng5Ac1ifMa3SBgN6+mq eKKdigQeRgPj3NBbLEQ9rlLzhYExpp4Y051Jxhg1MWYschhtAA0pmlRAzoO0cx0XME7UkQ3YqoWm b5mOOKHCd1O8q/vJ0sQvNKrobfihuZIKfZpJ4kcaTA29vx41jkBh+oLjgxk9fOtw9rxaRWrTtwoq wn6f//gRB0jf/vfPeKPesd2+KajV3j3QPMBhTUxZNNdAHkfBTW9cdEgjWu7QQpiI2i45eh6nBecL wUD/cUrH9Okp3SlNlI4Z11N6LHKM0vCdKM1Ro6tDnDaT2rqkRiwxTCmapejLyrJd7MlP3fCkJs0s LXSJLCo9WYj1MC7AQ46xzAxzPy30uX+k/OFrTwwJ0QkmiGCtq4aEGIv4WE0sJOiriclpwc+1WCdn uecL9hOu8RVztIi3pn0zljZD7atpQNqDQyU8s7414vAEvp+0q/8GAG5gyNYKZW5kc3RyZWFtDWVu ZG9iag0xMSAwIG9iag08PCANL1R5cGUgL0V4dEdTdGF0ZSANL1NBIGZhbHNlIA0vU00gMC4wMiAN L1RSIC9JZGVudGl0eSANPj4gDWVuZG9iag0xIDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRz IFsgNSAwIFIgXSANL0NvdW50IDEgDT4+IA1lbmRvYmoNMiAwIG9iag08PCANL0NyZWF0aW9uRGF0 ZSAoRDoyMDAzMDEwOTEzNDUyMSkNL1Byb2R1Y2VyIChBY3JvYmF0IERpc3RpbGxlciA0LjAgZm9y IFdpbmRvd3MpDS9Nb2REYXRlIChEOjIwMDMwMTA5MTM0NjUyLTA4JzAwJykNPj4gDWVuZG9iag14 cmVmDTAgMyANMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAzNjE3IDAwMDAwIG4NCjAwMDAwMDM2 ODEgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAzDS9JRFs8YjAxZjVkNWY2YWE2Nzg2YjFlOTk2 NGUyYTAzNGM4Nzg+PGIwMWY1ZDVmNmFhNjc4NmIxZTk5NjRlMmEwMzRjODc4Pl0NPj4Nc3RhcnR4 cmVmDTE3Mw0lJUVPRg0= ------_=_NextPart_000_01C2B82F.021A0AB0-- From Internet-Drafts@ietf.org Fri Jan 10 17:34:34 2003 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Fri, 10 Jan 2003 12:34:34 -0500 Subject: [eap] I-D ACTION:draft-ietf-eap-esteem-01.txt Message-ID: <200301101734.MAA04982@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Eap STate machinE dEsign teaM (ESTEEM) Discussions Author(s) : B. Aboba Filename : draft-ietf-eap-esteem-01.txt Pages : 56 Date : 2003-1-10 This document describes the deliberations of the EAP STate MachinE DEsign TeaM (ESTEEM). This includes minutes of meetings, as well as position papers A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-esteem-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-esteem-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-esteem-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-10122242.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-esteem-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-esteem-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-10122242.I-D@ietf.org> --OtherAccess-- --NextPart-- From aboba@internaut.com Sat Jan 11 14:02:24 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 06:02:24 -0800 (PST) Subject: [eap] Re: [Issue 61] Support for EAP Sequences In-Reply-To: <1041985124.3e1b6e640e442@floatingbottle.mail.umich.edu> Message-ID: > I think the idea of sequences is useful when doing something in addition to > authentication. E.g. a method that negotiates QOS. Then the negotiation for > authenication method can be done, and if that method succeeds, an attempt to do > the QOS method can be made. If the peer accepts the method, it will get to > negotiate - if not it gets some default settings. Why wouldn't this be negotiated at the lower layer? EAP doesn't have a generic negotiation framework. > This concept was at least part of the thinking at the time the initial EAP > draft was written. Did it get removed later? From aboba@internaut.com Sat Jan 11 14:06:54 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 06:06:54 -0800 (PST) Subject: [eap] Re: [Issue 61] Support for EAP Sequences In-Reply-To: <15900.41210.409588.362152@gargle.gargle.HOWL> Message-ID: > Yes, precisely. That's what RFC 2284 *requires*: > > 3. The authenticator ends the authentication phase with a Success or > Failure packet. > > and also: > > Implementation Note: Because the Success and Failure packets > are not acknowledged, they may be potentially lost. A peer > MUST allow for this circumstance. The peer can use a Network > Protocol packet as an alternative indication of Success. > Likewise, the receipt of a LCP Terminate-Request can be taken > as a Failure. The third sentence of this paragraph is quite scary -- the idea that the EAP state machine can somehow enter into the SUCCESS state via receipt of out-of-band exchanges. Lower layer failure indications need to be processed, even if they are spoofable. It's the responsibility of the lower layer to do something about this (such as protecting 802.11 Disassociate or Deauthenticate messages), but if it doesn't, there's little EAP can do. From aboba@internaut.com Sat Jan 11 14:40:05 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 06:40:05 -0800 (PST) Subject: [eap] Re: [Issue 61] Support for EAP Sequences In-Reply-To: <15899.21554.770583.678905@gargle.gargle.HOWL> Message-ID: > I suspect that fear need not be true for an implementation that was > exceedingly careful (that is, one that ran each authentication method > regardless of the intermediate result of each, and then sent Success > after *all* had been run only if all had passed). But given the > tendency for mistakes, and the likely uselessness of the "feature," it > seems reasonable to suggest that it's not a good idea. The RFC 2284 text (below) was modified under the assumption that it did not apply to sequences. However, given your concerns and the recent work on man-in-the-middle attacks, that may not have been appropriate. This was the RFC 2284 text: In practice, within or associated with each PPP server, it is not anticipated that a particular named user would be authenticated by multiple methods. This would make the user vulnerable to attacks which negotiate the least secure method from among a set (such as PAP rather than EAP). Instead, for each named user there should be an indication of exactly one method used to authenticate that user name. If a user needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. How about this: In practice, within or associated with each EAP server, it is not anticipated that a particular named user would be authenticated by multiple methods, either in by offering a choice or by using multiple methods in sequence. This would make the user vulnerable to attacks which negotiate the least secure method from among a set ( negotiation attacks, described in Section 7.9) or man-in-the-middle attacks (described in Section 7.5) Instead, for each named user there SHOULD be an indication of exactly one method used to authenticate that user name. If a user needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. From aboba@internaut.com Sat Jan 11 15:23:07 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 07:23:07 -0800 (PST) Subject: [eap] Proposed Resolution of Issue 61: Support for Sequences Message-ID: Issue 61, enclosed below, requests clarification of sequence support within EAP. Comments from implementors disclosed issues with supporting sequences, as well as concerns over whether language in RFC 2284 was being weakened. As a result, the proposed resolution is to restore the RFC 2284 language, with clarifications, in a new section 2.1: "2.1. Support for sequences An authenticator MAY authenticate the peer using a sequence of methods. A common example of this is an Identity request followed by an EAP authentication method such as an MD5-Challenge. If additional authenti- cation methods are required, the authenticator MAY send a Request packet for a subsequent authentication method, or it MAY send another Identity request. However, within or associated with each EAP server, it is not antici- pated that a particular named peer would be authenticated by multiple methods, either by supporting a choice of methods or by using multiple methods in sequence. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set ( negotiation attacks, described in Section 7.9) or man-in-the-middle attacks (described in Section 7.5). Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. If the peer does not support additional authentication methods, after completing the last supported authentication method, it SHOULD respond to a subsequent Request with a Nak, indicating no acceptable alterna- tive, as described in Section 5.3. However, peer implementations MAY not respond at all, in which case a timeout will result and authentica- tion will fail. Since the authenticator presumably requires successful completion of the sequence in order to grant access, authentication failure is the correct result. Therefore, it is not necessary for the authenticator to determine that the peer supports sequences prior to sending a Request for a subsequent authentication method." ------------------------------------------------------------------- Issue 61: Support for EAP Sequences Submitter name: Hao Zhou Submitter email address: hzhou@cisco.com Date first submitted: January 7, 2003 Document: RFC2284bis-08 Reference: http://mail.frascone.com/pipermail/eap/2003-January/000494.html Comment type: T Priority: S Section: 2 Rationale/Explanation of issue: The current 2284bis doesn't distinguish FAILURE and SUCCESS from individual method and the final one from Authenticator, which makes it hard to support sequence of EAP methods. I assume it is preferred that the existing EAP methods will require no change to be supported for sequences. They currently send out EAP-SUCCESS and EAP-FAILURE by themselves. On the other end, authenticator sometimes send out "canned " SUCCESS and FAILURE messages after receiving Accept/Reject from the server [IEEE8021X]. Obviously, we need to distinguish those two types of success and failure to continue the sequence. I wonder if extending the EAP-SUCCESS and EAP-FAILURE message to include a EAP method type would solve this. There would be two types of EAP-SUCCESS and FAILURE: 1. The current EAP-SUCCESS and EAP-FAILURE with no data to indicate final success and failure; 2. The extended EAP-SUCCESS and EAP-FAILURE include extra eap method type to indicate individual eap method success and failure. Without requiring changes in the existing individual methods to be used in the sequence, they would keep sending out EAP-SUCCESS and EAP-FAILURE messages. The EAP layer would append the EAP type to the success and failure packets if the individual methods are chained. Otherwise, send the message out without modifying it, which indicates final success and failure. In addition to above, an acknowledgment of receiving the success and failure message might be needed to support sequence. For example, after EAP method 1 received EAP-SUCCESS, it sends out acknowledge to the backend server, so backend server can start EAP method 2. This is due to unreliable transmission of lower layer, success or failure message might not reach the client. Server should not start method 2 until peer acknowledges that it finishes with method 1. From aboba@internaut.com Sat Jan 11 15:30:37 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 07:30:37 -0800 (PST) Subject: [eap] Proposed resolution to Issue 66: Mandatory for who? In-Reply-To: <15901.54248.680584.988168@gargle.gargle.HOWL> Message-ID: > > OK. I think the answer is that a device which does pass-through only, need > > not implement the mandatory method. However, one which implements both > > pass-through and local authentication does need to implement the mandatory > > method. Does that make sense? > > That's a good issue. I'd have to say that as long as the backend > authentication mechanism (pass-through or otherwise) is one that can > allows the use of MD5-Challenge (i.e., the underlying AAA protocol has > some support for it), then this would fulfill the requirement. If one > picked a mechanism (e.g., NIS) that didn't, then that would be a > problem. OK. How about this: "EAP peer and EAP server implementations MUST support the MD5-Challenge mechanism. An authenticator which only supports pass-through is exempt from this requirement, since it does not act as an EAP server. However, if the authenticator can be configured to authenticate local users, then the requirement applies." From james.d.carlson@east.sun.com Sat Jan 11 16:43:59 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Sat, 11 Jan 2003 11:43:59 -0500 Subject: [eap] Proposed resolution to Issue 66: Mandatory for who? In-Reply-To: Bernard Aboba's message of 11 January 2003 07:30:37 References: <15901.54248.680584.988168@gargle.gargle.HOWL> Message-ID: <15904.18895.358155.822407@gargle.gargle.HOWL> Bernard Aboba writes: > OK. How about this: > > "EAP peer and EAP server implementations MUST support the MD5-Challenge > mechanism. An authenticator which only supports pass-through is exempt > from this requirement, since it does not act as an EAP server. However, if > the authenticator can be configured to authenticate local users, then > the requirement applies." That seems good, at least for pass-through. More broadly, an EAP authenticator must have at least one backend authentication mechanism that is capable of supporting MD5-Challenge. (Which, I think, is equivalent to saying that the authenticator must support MD5-Challenge ...) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Sat Jan 11 15:40:26 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 07:40:26 -0800 (PST) Subject: [eap] Proposed resolution to Issue 66: Mandatory for who? In-Reply-To: <15904.18895.358155.822407@gargle.gargle.HOWL> Message-ID: How about this: "EAP peer and EAP server implementations MUST support the MD5-Challenge mechanism. An authenticator which only supports pass-through MUST be configured with a backend authentication server that is capable of supporting MD5-Challenge, although it need not support MD5-Challenge itself. However, if the authenticator can be configured to authenticate local users, then the requirement applies." On Sat, 11 Jan 2003, James Carlson wrote: > Bernard Aboba writes: > > OK. How about this: > > > > "EAP peer and EAP server implementations MUST support the MD5-Challenge > > mechanism. An authenticator which only supports pass-through is exempt > > from this requirement, since it does not act as an EAP server. However, if > > the authenticator can be configured to authenticate local users, then > > the requirement applies." > > That seems good, at least for pass-through. More broadly, an EAP > authenticator must have at least one backend authentication mechanism > that is capable of supporting MD5-Challenge. (Which, I think, is > equivalent to saying that the authenticator must support MD5-Challenge > ...) > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > From james.d.carlson@east.sun.com Sat Jan 11 16:55:37 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Sat, 11 Jan 2003 11:55:37 -0500 Subject: [eap] Proposed resolution to Issue 66: Mandatory for who? In-Reply-To: Bernard Aboba's message of 11 January 2003 07:40:26 References: <15904.18895.358155.822407@gargle.gargle.HOWL> Message-ID: <15904.19593.366798.41786@gargle.gargle.HOWL> Bernard Aboba writes: > "EAP peer and EAP server implementations MUST support the > MD5-Challenge mechanism. An authenticator which only supports pass-through > MUST be configured with a backend authentication server that is capable > of supporting MD5-Challenge, although it need not support MD5-Challenge > itself. However, if the authenticator can be configured to authenticate > local users, then the requirement applies." How about: "EAP peer and EAP server implementations MUST support the MD5-Challenge mechanism. An authenticator that supports only pass-through MUST allow communication with a backend authentication server that is capable of supporting MD5-Challenge, although the EAP authenticator implementation need not support MD5-Challenge itself. However, if the EAP authenticator can be configured to authenticate peers via any non-pass-through mechanism, then the requirement applies." -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Sat Jan 11 16:02:48 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 08:02:48 -0800 (PST) Subject: [eap] Proposed resolution to Issue 66: Mandatory for who? In-Reply-To: <15904.19593.366798.41786@gargle.gargle.HOWL> Message-ID: OK with me. On Sat, 11 Jan 2003, James Carlson wrote: > Bernard Aboba writes: > > "EAP peer and EAP server implementations MUST support the > > MD5-Challenge mechanism. An authenticator which only supports pass-through > > MUST be configured with a backend authentication server that is capable > > of supporting MD5-Challenge, although it need not support MD5-Challenge > > itself. However, if the authenticator can be configured to authenticate > > local users, then the requirement applies." > > How about: > > "EAP peer and EAP server implementations MUST support the > MD5-Challenge mechanism. An authenticator that supports only > pass-through MUST allow communication with a backend > authentication server that is capable of supporting MD5-Challenge, > although the EAP authenticator implementation need not support > MD5-Challenge itself. However, if the EAP authenticator can be > configured to authenticate peers via any non-pass-through > mechanism, then the requirement applies." > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > From aboba@internaut.com Sat Jan 11 16:57:16 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 08:57:16 -0800 (PST) Subject: [eap] Issues 49 & 62: Strawman Section 4.2.1 In-Reply-To: <15901.58857.866944.693008@gargle.gargle.HOWL> Message-ID: > First, I think that EAP Failure MUST NOT be discarded at any time. If > you get one, then the peer is clearly trying to tell you something. > It's not a security risk because you're not going to enable the link > because of it. If you're worried about spoofed EAP Failure as a DoS, > I think the only way to win there is with some sort of link security > -- a MIC or something equivalent. Link security can often be enabled as soon as keys are derived, which can be *before* the arrival of a success/failure indication. So this can work sometimes. At various points we have also discussed how a method could include its own protected success/failure indication. The question is whether such a protected indication can take precedence over an unprotected EAP result indication if they conflict. In particular: What if the authenticator has, through a protected method-specific result indication, previously told the peer that authentication was successful. Could that be a reason to regard a subsequent EAP Failure with suspicion? If so, when? > of crufty timeout, saying "well, I got Success, and I didn't expect > it, and no other Requests showed up; shutting down now." Yes, a timeout will result where the bogus Success comes from a rogue authenticator. Where it comes from a third party, presumably a legitimate Request will eventually arrive. > Otherwise, > this invokes the possibility of a deadlock: if an Authenticator sends > Success (and *really* means it), but the Authenticatee doesn't > "expect" it, the link is left in limbo. The question is what "expect" means. If the peer and authenticator have negotiated a method that provides mutual authentication, and the authenticator has not yet authenticated to the peer, can it just bypass that by sending an EAP Success? That would create a vulnerability to a rogue authenticator. > So, I think the right thing to do is to say (as we already have) that > if the Authenticatee gets EAP Success and (for any reason) doesn't > like that message, then it disconnects. Why wouldn't an invalid EAP Success be treated like any other invalid packet -- silent discard? The disconnect approach does result in a quicker disconnect in the case of a rogue authenticator, but where the attacker is a third party, peer disconnection results in denial of service, where otherwise authentication would succeed (the legitimate Request would eventually arrive and authentication would continue). > If you have a MIC, or some other way of guaranteeing that messages on > the link can't be forged, you can clearly avoid this problem without > having to change anything. The link layer ciphersuite may not be enabled until after the Success or Failure indication is sent. Also, it is possible for EAP to be used in pre-authentication mode, where EAP packets may be forwarded over an unprotected link. So I think this technique may not be universally employable. > Note also that if you get an unexpected EAP Success this means that > (A) the peer is an idiot and doesn't implement the chosen method > correctly or (B) someone is attacking you. Either way, failing out > the link sounds like the right sort of handling. In case (B), I'd argue that failure is preferred only when there is insufficient security available, so that compromise is likely. That is the approach taken by IEEE 802.11 TKIP, which has a weak MIC, so that if attempts to compromise the MIC are found, then countermeasures (a timeout) are put into effect. This is also the approach in TLS, where MIC errors are fatal, since TLS relies on the underlying TCP transport, and cannot protected against transport attacks (bogus RST, etc.). However, other protocols such as IPsec AH the MIC is calculated over the immutable fields of the IP header as well as the rest of the packet, and in 802.11 CCMP, MIC security is thought to be strong. In both these cases, MIC failures result in silent discard, not countermeasures or failure. This is generally considered a strength of those approaches. > > 4.2.1. Processing of success and failure > > > > Within EAP, success and failure indications may be protected or unpro- > > tected. Unless protected by an underlying link layer ciphersuite, > ^^^^^^^^^^^^^^^^^^^^^^ > > I think that's a little too strong. Unless the link itself is known > to have sufficient security, which might consist of physical or > cryptographic methods, then the messages received might be spoofed. Agreed. > > However, EAP methods MAY include support for acknowledged and protected > > success and failure indications. This enables the authenticator to indi- > > cate whether the peer has successfully authenticated to it, as well as > > for the peer to acknowledge receipt, > > Receipt of what? Receipt of the result indication from the authenticator. > > and to indicate whether the authen- > > ticator has successfully authenticated to it. If a key has previously > > been derived, these messages MAY be protected by a Message Integrity > > Check (MIC). > > This should probably say something about where the MIC goes. There's > no provision in EAP for this, so it has to be an L2 issue, right? The MIC could be done in L2, or it could be done within the EAP method. > > Where a protected success/failure indication has been received at the > > EAP layer by an EAP peer, it MUST accept and process the protected indi- > > cation. > > I think "protected success/failure" isn't well enough defined. Is > this a method-specific Request/Response exchange? In this case, I think the text is referring to a protected EAP Success or Failure packet -- protected at L2, or perhaps by some other means (a tunnel?) > Is it an EAP > Success message where the implementation happens to have independent > knowledge that the link layer is "acceptably secure?" Is it a new > message entirely? In this case, I think it is the existing EAP Success or Failure message when the link layer is "acceptably secure?" > > [a] Link layer ciphersuite. If a link layer ciphersuite providing > > integrity protection is in use, then spoofed EAP Success or Failure > > packets can be detected and silently discarded by the link layer. > > Actually, *all* spoofed messages, including EAP Success or Failure, > can be detected, right? Yes. > > [b] Message validation. EAP Failure and Success messages are never sent > > by the EAP peer, only the authenticator. Therefore, EAP Failure and > > Success messages received by the authenticator MUST be silently > > discarded. > > That disallows bidirectional authentication. Yes, this should be removed. > > [c] Mandatory authentication. Whether authentication is mandatory is > > determined by the authenticator and peer configurations. If authen- > > tication is not required by the authenticator, or if the identity > > of the peer is verified by another mechanism (e.g. Calling-Station- > > ID or MAC address), then the authenticator MAY send a "canned" EAP > > Success message. These messages are highly vulnerable to spoofing. > > However, the peer may be configured to require the authenticator to > > authenticate itself prior to being willing to process an unpro- > > tected EAP Success message. > > Actually, I think that the Authenticatee ought to disconnect rather > than just leave "unprocessed" this unexpected EAP Success message. If > it's expecting some sort of authentication that the peer isn't > providing, there's no sense in ignoring the condition. Alerting a > human (or an administrator) is the only way out. Some sort of logging is definitely appropriate, yes. > > [d] Completion indications. An EAP method requesting transmission of an > > EAP messsage by the EAP layer SHOULD indicate whether the message > > represents completion of the EAP conversation. A peer EAP implemen- > > tation that has not yet received a completion indication MUST > > silently discard unprotected EAP Success packets and SHOULD > > silently discard EAP Failure packets. > > I disagree with both parts of that for different reasons. > > EAP Failure before the method is complete is entirely possible. It > means "go away" and could be the result of administrative reset. Sure. Even if the method derives keys and could protect a result indication, failure can occur early before keys are derived. So this always results in a timeout when an early failure occurs. > > [e] Method indications. An EAP method supporting protected success and > > failure indications MAY indicate to the EAP layer the authentica- > > tion status in each direction: SUCCESS, FAILURE or UNKNOWN, as part > > of the message transport primitive. An EAP method indicating an > > authentication FAILURE in either direction MUST cause the EAP layer > > to silently discard unprotected EAP Success packets. The EAP con- > > versation MUST also be unsuccessfully terminated. An EAP method > > indicating authentication SUCCESS in both directions SHOULD cause > > the EAP layer to silently discard unprotected EAP Failure packets. > > I think that's basically an implementation choice for (d). Yes, it does seem somewhat heavy handed, especially since I don't know any implementation that actually does this (though several implementations do silently discard EAP Success messages prior to completion). > > In the absence of the above mechanisms, unprotected failure indications > > MAY be accepted and processed by the peer EAP layer. This can result in > > a denial of service attack. > > It's one of several different DoSes available (including Requests with > rotating Identifier values), and perhaps not even the most effective > one. Yes, there are other potential DoS attacks. From aboba@internaut.com Sat Jan 11 17:41:34 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 09:41:34 -0800 (PST) Subject: [eap] Issue 67: Lower layer security requirement? Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: January 11, 2003 Document: RFC 2284bis-08 Comment type: T Priority: S Section: 3.1 Rationale/Explanation of issue: Does EAP also require security from the lower layer in some form, such as physical security, or a lower layer ciphersuite? Given that the Nak, Identity, Notification, EAP Success and Failure packets are not protected, this seems reasonable. Add the following to the lower layer requirements: "[2] Lower layer security. Although EAP methods may support method-specific message integrity checks (MICs), these MICs typically only cover the Type-Data field within EAP Request and Response messages of a single Type, such as in [RFC2716]. While it is possible for a method-specific MIC to be calculated over the EAP header, as well as previous EAP messages of Types Identity, Nak, and Notification, existing methods do not support this. While Success and Failure messages also do not include a MIC, it is possible for EAP methods to support method-specific acknowledged and protected success and failure indications. However, as discussed in Section 4.2.1, this cannot provide complete protection against denial of service attacks. In order to compensate for these weaknesses, EAP SHOULD be used only with lower layers that are either physically secure (e.g. wired PPP or IEEE 802 links), or provide per-packet authentication and integrity protection via a lower layer ciphersuite. Note that where keying material for the lower layer ciphersuite is itself provided by EAP, the ciphersuite cannot be enabled until late in the EAP conversation, after key derivation has completed. Thus, it may only be possible to protect a portion of the EAP conversation, such as the EAP Success or Failure packet." From aboba@internaut.com Sat Jan 11 19:21:46 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 11:21:46 -0800 (PST) Subject: [eap] Another stab at text for Issue 49 In-Reply-To: <1041892446.3e1a045ec344f@towncrier.mail.umich.edu> Message-ID: This still isn't right, but hopefully it's a step in the right direction. 4.2.1. Processing of success and failure Within EAP, success and failure indications consist of the EAP Success and Failure messages, as well as method-specific result indications. These indications may be protected or unprotected. Where a lower layer ciphersuite is in use that provides per-packet integrity and authentication protection, or where the lower layer is considered physically secure, EAP may be considered secure from tampering, and EAP Success and Failure packets may qualify as protected indications. Otherwise, EAP Success and Failure packets are considered unprotected indications which may be spoofed, since they contain no embedded message integrity check. Note that Where EAP itself is used to provide the keys for use with a lower layer ciphersuite, protection may not be enabled until key derivation is complete so that only a portion of the EAP conversation may be protected. If the lower layer ciphersuite is not enabled when the EAP Success or Failure packet is sent, then these indications are considered unprotected. In order to provide additional protection against tampering, EAP methods MAY support a method-specific MIC that covers the entire EAP conversation, including messages of types Identity, Nak, and Notification (similar to the Finished message in [RFC2246]). In addition, EAP methods MAY include support for method-specific acknowledged and protected success and failure indications. This enables the authenticator to indicate whether the peer has successfully authenticated, as well as for the peer to acknowledge receipt of that indication, and respond with an indication of whether the authenticator has successfully authenticated to the peer. If a key has previously been derived, the result exchange MAY be protected by a Message Integrity Check (MIC), and if so, then this success/failure indication is considered protected. In order to protect against spoofing of success and failure indications, EAP implementations SHOULD obey the following processing rules: [a] Processing of protected success and failure indications. Where a protected success/failure indication has been received, the EAP implementation MUST validate the method-specific or lower layer MIC, with a MIC failure handled via silent discard, as specified in Section 4.1. [b] Receipt of unprotected indications prior to completion. A peer EAP implementation receiving an unprotected EAP Success packet prior to completion of the method in progress MUST silently discard it. A peer EAP implementation receiving an unprotected EAP Failure packet prior to completion of the method in progress MAY silently discard it. This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. [c] Authentication requirement. An EAP peer implementation that has been configured to require authentication MUST silently discard an unprotected "canned" EAP Success message (an unprotected EAP Success message sent immediately upon connection). [d] Contradictory indications. Where protected and unprotected result indications are both available, protected indications take precedence. For example, where an EAP method provides a protected indication that authentication failure has occurred in either direction, the implementation MUST silently discard subsequent unprotected EAP Success packets. Similarly, where an EAP method provides a protected indication that authentication has succeeded in both directions, the EAP implementation MAY silently discard unprotected EAP Failure packets. [e] Processing of unprotected indications in the absence of protected indications. Subsequent to the completion of the EAP authentication method (Types 4 and greater), and in the absence of protected result indications, unprotected success and failure indications MUST be accepted and processed by the EAP implementation. From aboba@internaut.com Sat Jan 11 19:30:21 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 11:30:21 -0800 (PST) Subject: [eap] Proposed Resolution to Issue 62: Accept Message-ID: Here is the proposed text for resolution of Issue 62: Protected success/failure. Insert a definition of a protected and unprotected indications in Section 4.2.1: "Within EAP, success and failure indications consist of the EAP Success and Failure messages, as well as method-specific result indications. These indications may be protected or unprotected. Where a lower layer ciphersuite is in use that provides per-packet integrity and authentication protection, or where the lower layer is considered physically secure, EAP may be considered secure from tampering, and EAP Success and Failure packets may qualify as protected indications. Otherwise, EAP Success and Failure packets are considered unprotected indications which may be spoofed, since they contain no embedded message integrity check. Note that Where EAP itself is used to provide the keys for use with a lower layer ciphersuite, protection may not be enabled until key derivation is complete so that only a portion of the EAP conversation may be protected. If the lower layer ciphersuite is not enabled when the EAP Success or Failure packet is sent, then these indications are considered unprotected." Change: "Where a protected success/failure indication has been received at the EAP layer by an EAP Peer, it MUST accept and process the protected indication." To: "[a] Processing of protected success and failure indications. Where a protected success/failure indication has been received, the implementation MUST validate the EAP method-specific or lower layer MIC, with a MIC failure handled via silent discard, as specified in Section 4.1." ============================================================= Issue 62: Protected success/failure Submitter name: Jesse Walker Submitter email address: jesse.walker@intel.com Date first submitted: January 3, 2003 Document: RFC2284bis-08 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Page 6: "Protected success/failure" is never defined. Page 6: There is a sentence which says: Where a protected success/failure indication has been received at the EAP layer by an EAP Peer, it MUST accept and process the protected indication. This is a vacuous requirement, because there is no definition of what it means to "process" the "protected indication". At the very least this should indicate that "to process" means something like (a) apply all the protections of whatever ciphersuite that one believes to have been applied to the message to (b) extract a success/failure message, which is then handled according to the normal rules for EAP success/failure messages, and (c) received EAP success/failure messages that arrive unprotected are silently discarded if protection is expected. From aboba@internaut.com Sat Jan 11 23:56:26 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 15:56:26 -0800 (PST) Subject: [eap] (no subject) Message-ID: Issue 68: MIC coverage? Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: January 11, 2003 Document: RFC 2284bis-08 Comment type: T Priority: S Section: 2.1, 3.1 Rationale/Explanation of issue: In order to provide integrity protection and authentication for the EAP conversation, it may be desirable for an EAP method to be able to calculate a MIC on the EAP headers as well as the Type-Data field, and perhaps even previous EAP messages. For example, in a conversation including an Identity Request/Response, a Request for EAP Type X, a Nak Response offering alternative Y, and then EAP Request/Response messages of Type Y, it may be desirable for method Y to be able to calculate a MIC of all previous EAP messages, including headers. Is this prohibited by the multiplexing model? For example, can EAP methods be assumed to have access to the EAP headers? Does the multiplexing model imply that EAP messages of types Nak, Notification Success and Failure are never accessible to the EAP method? What about EAP Identity-Request? From aboba@internaut.com Sat Jan 11 23:57:07 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 15:57:07 -0800 (PST) Subject: [eap] Issue 68: MIC coverage Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: January 11, 2003 Document: RFC 2284bis-08 Comment type: T Priority: S Section: 2.1, 3.1 Rationale/Explanation of issue: In order to provide integrity protection and authentication for the EAP conversation, it may be desirable for an EAP method to be able to calculate a MIC on the EAP headers as well as the Type-Data field, and perhaps even previous EAP messages. For example, in a conversation including an Identity Request/Response, a Request for EAP Type X, a Nak Response offering alternative Y, and then EAP Request/Response messages of Type Y, it may be desirable for method Y to be able to calculate a MIC of all previous EAP messages, including headers. Is this prohibited by the multiplexing model? For example, can EAP methods be assumed to have access to the EAP headers? Does the multiplexing model imply that EAP messages of types Nak, Notification Success and Failure are never accessible to the EAP method? What about EAP Identity-Request? From jari.arkko@piuha.net Sun Jan 12 08:00:41 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 12 Jan 2003 10:00:41 +0200 Subject: [eap] Issue 68: MIC coverage References: Message-ID: <3E2120A9.1040908@piuha.net> Bernard Aboba wrote: > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: January 11, 2003 > Document: RFC 2284bis-08 > Comment type: T > Priority: S > Section: 2.1, 3.1 > Rationale/Explanation of issue: > > In order to provide integrity protection and authentication for the EAP > conversation, it may be desirable for an EAP method to be able to > calculate a MIC on the EAP headers as well as the Type-Data field, and > perhaps even previous EAP messages. > > For example, in a conversation including an Identity Request/Response, > a Request for EAP Type X, a Nak Response offering alternative Y, and > then EAP Request/Response messages of Type Y, it may be desirable for > method Y to be able to calculate a MIC of all previous EAP messages, > including headers. > > Is this prohibited by the multiplexing model? For example, can EAP > methods be assumed to have access to the EAP headers? Does the > multiplexing model imply that EAP messages of types Nak, Notification > Success and Failure are never accessible to the EAP method? What > about EAP Identity-Request? There clearly has to be _some_ amount of information available to the methods from past messages. The identity of the user, for instance. Or if we at some point start to cryptographically bind sequences of methods together, then the keys must be available. One answer to your question is that this is to a large extent an issue for the EAP method spec, and also an implementation issue: if your product needs to implement method M which requires past messages, then your EAP mux implementation better be capable of providing this information. I think it should be sufficient for 2284bis to define what information MUST be available (identity response values?) to the method, and state that methods MAY require more. Then I have a question about your integrity protection scheme above. Exactly how did you plan on using it? The state machine still progresses one step at a time, and at the end we will check if someone modified the sequence? If yes, do you have a more exact definition of what the additional security provided by this would be? It seems to me that the identity responses, for instance, are in a way already included in the MACs... you could substitute some other identity which happens to have the same password, however. Apparently you could protect notifications this way, but they never affect the end-result anyways. Success and failure? But don't they always come _after_ methods? If you are not expecting the state machine to just verify things at the end, are you thinking of building some tree of alternative message sequences and accepting the one that leads to a successful MAC at the end? Jari From aboba@internaut.com Sun Jan 12 07:19:54 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 11 Jan 2003 23:19:54 -0800 (PST) Subject: [eap] Issue 68: MIC coverage In-Reply-To: <3E2120A9.1040908@piuha.net> Message-ID: > I think it should be sufficient for 2284bis to define what > information MUST be available (identity response values?) to > the method, and state that methods MAY require more. Yes, I think this makes sense. That would require rewording the EAP multiplexing section in terms of MUSTs and MAYs. The question in my mind is whether an EAP method can require a capability that is only a MAY. That would mean that it wouldn't be feasible to run it on every Peer and Authenticator implementation. That seems wrong somehow. > Then I have a question about your integrity protection scheme > above. Exactly how did you plan on using it? Protocols such as TLS [RFC2246] include a Finished message that serves to MIC the entire conversation. The reason for this is that early messages typically can't be MIC'd, because there's no key yet. That means that the Identity exchange, Nak, Notification, and perhaps the first one or two method exchanges are not tamperproof. So the purpose of this would be to be able to detect tampering in earlier messages, once the method has been able to derive a MIC key. The question is what earlier messages could be included. The way the section reads now, only the Identity Response is guaranteed to be available -- not the Identity Request, Nak Response (if sent), Notification Request or Notification Response. And it is not entirely clear that the EAP method can have access to the EAP headers over which to calculate a MIC -- though we might clarify this. The Identity Request is only a hint, and Notification Request/Response doesn't change state, so perhaps it can be argued that we don't need these to be part of a complete MIC. As you said, Success/Failure comes after the method, and in any case we can have method-specific protected result indications. So the main thing I'm worried about is a "bidding down" attack -- discovering that the attacker inserted a Nak that the client didn't send, in order to get a less strong method to run. Also perhaps a change of the Identity, so as to cause the authentication to be routed to the wrong server -- I typed bernard@ny.foo.com and instead bernard@badguy.com was sent. > If yes, do you have > a more exact definition of what the additional security provided > by this would be? MICs which only cover the Type-data field leave the EAP headers exposed. There are not many vulnerabilities to exploit in modifying the EAP headers, but there are some. Changes in Code and Identifier will generally result in silent discard, but you can change the Length field in case an implementation isn't checking for buffer overuns, and modify the Type field. Since some EAP methods are similar, changes in the Type field may not be detectable, for example. So you could, for example, convert a PEAP or EAP TTLS packet to an EAP TLS packet without anyone noticing (at least at first). Also there is the bidding down attack I mentioned earlier, and perhaps Identifier space insertion attacks (I'm assuming that most of these will also result in silent discard), and Type insertion attacks (which will also result in silent discard except if they are timed exactly right). > If you are not expecting the state machine to just verify > things at the end, are you thinking of building some tree > of alternative message sequences and accepting the one that > leads to a successful MAC at the end? No, just aborting if the "finished" MICs don't match. From jari.arkko@piuha.net Sun Jan 12 08:41:04 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 12 Jan 2003 10:41:04 +0200 Subject: [eap] Issue 68: MIC coverage References: Message-ID: <3E212A20.7090509@piuha.net> Bernard Aboba wrote: > The question in my mind is whether an EAP method can require a capability > that is only a MAY. That would mean that it wouldn't be feasible to run it > on every Peer and Authenticator implementation. That seems wrong somehow. Ok. I don't think adding a requirement to have past message history available is too much of a burden. We could make it a MUST too. > So the main thing I'm worried about is a "bidding down" attack -- > discovering that the attacker inserted a Nak that the client didn't send, > in order to get a less strong method to run. Also perhaps a change of the > Identity, so as to cause the authentication to be routed to the wrong > server -- I typed bernard@ny.foo.com and instead bernard@badguy.com was > sent. Interesting. Yes, bidding down is an issue. I didn't realize we could solve it this way. I'm convinced now that we should provide the information to methods. [Hmm... this way of protecting against bidding down attacks can only succeed if neither party allows any of the current methods as the sole authentication method. As far as I know, all the currently defined EAP methods lack this capabality. Somewhere down the road we are going to need new methods.] >>If you are not expecting the state machine to just verify >>things at the end, are you thinking of building some tree >>of alternative message sequences and accepting the one that >>leads to a successful MAC at the end? > > > No, just aborting if the "finished" MICs don't match. Ok. Jari From jari.arkko@piuha.net Sun Jan 12 10:12:47 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 12 Jan 2003 12:12:47 +0200 Subject: [eap] Issue 67: Lower layer security requirement? References: Message-ID: <3E213F9F.8090808@piuha.net> Bernard Aboba wrote: > "[2] Lower layer security. Although EAP methods may support > method-specific message integrity checks (MICs), these MICs typically only > cover the Type-Data field within EAP Request and Response messages of a > single Type, such as in [RFC2716]. While it is possible for a > method-specific MIC to be calculated over the EAP header, as well as > previous EAP messages of Types Identity, Nak, and Notification, existing > methods do not support this. While Success and Failure messages also do > not include a MIC, it is possible for EAP methods to support > method-specific acknowledged and protected success and failure indications. > However, as discussed in Section 4.2.1, this cannot > provide complete protection against denial of service attacks. Moreover, authentication is pretty useless without any sort of guarantee that the subsequent payload come from the same source. > In order to compensate for these weaknesses, EAP SHOULD be used only with > lower layers that are either physically secure (e.g. wired PPP or IEEE 802 > links), or provide per-packet authentication and integrity protection via a lower > layer ciphersuite. Note that where keying material for the lower layer > ciphersuite is itself provided by EAP, the ciphersuite cannot be enabled until late in > the EAP conversation, after key derivation has completed. Thus, it may > only be possible to protect a portion of the EAP conversation, such as the > EAP Success or Failure packet." Ok. Jari From aboba@internaut.com Sun Jan 12 14:59:30 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 12 Jan 2003 06:59:30 -0800 (PST) Subject: [eap] Issue 68: MIC coverage In-Reply-To: <3E212A20.7090509@piuha.net> Message-ID: > Ok. I don't think adding a requirement to have past message history > available is too much of a burden. We could make it a MUST too. I don't think it is -- but I hope that capability doesn't wreak havoc with the multiplexing model. Even though one might have the past message history available doesn't mean that methods can assume that messages such as Notification carry data for them. > Interesting. Yes, bidding down is an issue. I didn't realize we could > solve it this way. I'm convinced now that we should provide the information > to methods. Do we assume that a method could have available *all* past traffic (inbound, outbound), including EAP headers? Or do we just add Headers, and the Nak Response (if sent) to Identity Response in the list of things that MUST be available to methods on both peer and authenticator? Doing that would wreak less havoc with the multiplexing model, while still allowing computation of a "finished" MIC. Maybe we should ask for an opinion from our security advisor? > [Hmm... this way of protecting against bidding down attacks can only > succeed if neither party allows any of the current methods as the sole > authentication method. As far as I know, all the currently defined EAP > methods lack this capabality. Somewhere down the road we are going to > need new methods.] Outside of RFC 2284, there is only one EAP method defined in an RFC (RFC 2716). From aboba@internaut.com Sun Jan 12 15:08:51 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 12 Jan 2003 07:08:51 -0800 (PST) Subject: [eap] Issue 67: Lower layer security requirement? In-Reply-To: <3E213F9F.8090808@piuha.net> Message-ID: > Moreover, authentication is pretty useless without any sort of guarantee > that the subsequent payload come from the same source. Do you have some text to suggest? From jari.arkko@piuha.net Sun Jan 12 20:49:29 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 12 Jan 2003 22:49:29 +0200 Subject: [eap] Issue 67: Lower layer security requirement? References: Message-ID: <3E21D4D9.8080804@piuha.net> Bernard Aboba wrote: >>Moreover, authentication is pretty useless without any sort of guarantee >>that the subsequent payload come from the same source. > > Do you have some text to suggest? Here's some: "[2] Lower layer security. Typically, the purpose of EAP authentication is to open a channel for the peer's traffic. In many cases, usage-based accounting is applied for the traffic passing through this channel. In order for the EAP authentication to be useful in allowing the service only to the right peers, there has to be some assurance that the authentication and the traffic comes from the same source. When EAP is used over links that are physically insecure and the link carrying the traffic is not cryptographically protected, it becomes possible for other parties to inject messages to the channel. The authentication run of a real user may also be diverted by a man-in-the-middle to another link, where some service may be acquired with it. Additionally, although EAP methods..." Jari From josh_mendel@infonet.com Tue Jan 14 01:05:50 2003 From: josh_mendel@infonet.com (josh_mendel@infonet.com) Date: Tue, 14 Jan 2003 01:05:50 +0000 Subject: [eap] Josh Mendel/HQ/ISC is out of the office. Message-ID: I will be out of the office starting 01/13/2003 and will not return until 01/17/2003. From aboba@internaut.com Tue Jan 14 05:34:10 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 13 Jan 2003 21:34:10 -0800 (PST) Subject: [eap] Proposed resolution to Issue 69: Accept Message-ID: Issue #69, enclosed below, addresses inconstitencies in ordering requirements within the draft. My proposal is to accept the change. -------------------------------------------------------- Issue 69: Inconsistent language in introduction abstract Submitter name: Nick Petroni Submitter email address: npetroni@cs.umd.edu Date first submitted: January 14, 2003 Document: RFC2284bis-09 Comment type: E Priority: S Section: Abstract and Intro (section 1) Rationale/Explanation of issue: Recent changes to 2284bis have been made to state that link-layer media must support the same order requirements as PPP. The intro and abstract are inconsistent with this requirement. Requested change: Change EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery, dupli- cate elimination and retransmission. to EAP typically runs directly over the link layer without requiring IP, but is reliant on lower layer ordering guarantees as in PPP. EAP does provide its own duplicate elimination and retransmission. From aboba@internaut.com Tue Jan 14 05:59:37 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 13 Jan 2003 21:59:37 -0800 (PST) Subject: [eap] Issue 67: Lower layer security requirement? In-Reply-To: <3E21D4D9.8080804@piuha.net> Message-ID: OK. How about this? [2] Lower layer security. After EAP authentication is complete, the peer will typically wish to transmit data to the network, through the authenticator. In order to provide assurance that the peer transmitting data is the one that successfully completed EAP authentication, it is necessary for the lower layer to either provide per-packet integrity and authentication (using keys derived as a result of EAP authentication) or for the lower layer to be physically secure. Otherwise it is possible for subsequent data traffic to be hijacked. These requirements also serve to allow for the protection of EAP traffic itself. EAP methods may support per-packet message integrity checks (MICs). In existing methods such as EAP-TLS [RFC2716], the MIC covers the Type-Data field within EAP Request and Response messages of a single Type. However, it is also possible for a MIC defined within an EAP method to include coverage of the EAP header or even previous EAP messages, although some EAP implementations may not support this. Where the MIC defined within the EAP method does not cover the EAP header and all messages within the EAP conversation, tampering is possible. While EAP Success and Failure messages do not include a MIC, it is possible for EAP methods to support their own acknowledged and protected success and failure indications. However, as discussed in Section 4.2.1, this cannot provide complete protection against denial of service attacks. As a result of these considerations, EAP SHOULD be used only with lower layers that are either physically secure (e.g. wired PPP or IEEE 802 links), or provide per-packet authentication and integrity protection via a lower layer ciphersuite. Note that where keying material for the lower layer ciphersuite is itself provided by EAP, the ciphersuite cannot be enabled until late in the EAP conversation, after key derivation has completed. Thus, it may only be possible to protect a portion of the EAP conversation, such as the EAP Success or Failure packet. From jari.arkko@piuha.net Tue Jan 14 07:16:10 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 14 Jan 2003 09:16:10 +0200 Subject: [eap] Issue 67: Lower layer security requirement? References: Message-ID: <3E23B93A.5080703@piuha.net> Looks good. Thanks. Bernard Aboba wrote: > OK. How about this? > > [2] Lower layer security. After EAP authentication is > complete, the peer will typically wish to transmit data > to the network, through the authenticator. > In order to provide assurance that the peer transmitting > data is the one that successfully completed EAP > authentication, it is necessary for the lower > layer to either provide per-packet integrity and > authentication (using keys derived as a result of > EAP authentication) or for the lower layer to be > physically secure. Otherwise it is possible for > subsequent data traffic to be hijacked. > > These requirements also serve to allow for the > protection of EAP traffic itself. > EAP methods may support > per-packet message integrity checks (MICs). > In existing methods such as EAP-TLS [RFC2716], > the MIC covers the Type-Data field > within EAP Request and Response messages of a > single Type. However, it is also possible for > a MIC defined within an EAP method > to include coverage of the EAP header > or even previous EAP messages, although > some EAP implementations may not support this. > Where the MIC defined within the EAP method > does not cover the EAP header and all messages > within the EAP conversation, tampering is possible. > > While EAP Success and Failure messages do > not include a MIC, it is possible for EAP methods > to support their own acknowledged and protected > success and failure indications. However, as discussed > in Section 4.2.1, this cannot provide complete protection > against denial of service attacks. > > As a result of these considerations, > EAP SHOULD be used only with lower layers that are either > physically secure (e.g. wired PPP or IEEE 802 links), or > provide per-packet authentication and integrity protection via a lower > layer ciphersuite. Note that where keying material for the lower layer > ciphersuite is itself provided by EAP, the ciphersuite cannot be enabled > until late in > the EAP conversation, after key derivation has completed. Thus, it may > only be possible to protect a portion of the EAP conversation, such as the > EAP Success or Failure packet. > > > From aboba@internaut.com Tue Jan 14 06:33:04 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 13 Jan 2003 22:33:04 -0800 (PST) Subject: [eap] Proposed Resolution to Issue 62: Accept In-Reply-To: <20030113185206.GA2306@catfish> Message-ID: > The following text I found in section 4.1 seems not always mandating > silent discard for invalid packets. > > If a peer receives a valid duplicate Request for which it has already > sent a Response, it MUST resend its original Response. If a peer > receives a duplicate Request before it has sent a Response to a valid > initial Request (i.e. it's waiting for user input), it MUST silently > discard the duplicate Request. An EAP message may be found invalid > for a variety of reasons: failed link layer CRC or checksum, > malformed EAP packet, EAP method-specific MIC, etc. How about this? If a peer receives a valid duplicate Request for which it has already sent a Response, it MUST resend its original Response. If a peer receives a duplicate Request before it has sent a Response, but after it has determined the initial Request to be valid (i.e. it is wait- ing for user input), it MUST silently discard the duplicate Request. An EAP message may be found invalid for a variety of reasons: failed lower layer CRC or checksum, malformed EAP packet, EAP method MIC failure, etc. From aboba@internaut.com Tue Jan 14 06:44:05 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 13 Jan 2003 22:44:05 -0800 (PST) Subject: [eap] RFC 2284bis-09 strawman Message-ID: There have been a lot of changes made between RFC 2284bis-08 and -09, and there are still a few more issues to resolve. In order to give people the opportunity to read the -09 draft in its entirety, I've put together a strawman version that I will keep current as we discuss further changes: http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-09.txt As usual, EAP issues (open and resolved) are available for inspection at: http://www.drizzle.com/~aboba/EAP/eapissues.html From aboba@internaut.com Tue Jan 14 06:50:58 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 13 Jan 2003 22:50:58 -0800 (PST) Subject: [eap] Survey: Unexpected packet in the middle of an EAP method Message-ID: In order to understand how to resolve Issue 52, we need to understand better how current EAP implementation behave. If you have developed an EAP implementation, please describe how your implementation reacts in the following cases: 1. An EAP Success is received prior to completion of the EAP method (e.g. an EAP Success arrives prior to authentication of the authenticator to the Peer). 2. An EAP message of a different Type is received, prior to completion of an EAP method in progress. 3. An EAP Failure is received prior to completion of the EAP method in progress. From aboba@internaut.com Tue Jan 14 07:33:47 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 13 Jan 2003 23:33:47 -0800 (PST) Subject: [eap] RE: Survey: Unexpected packet in the middle of an EAP method Message-ID: Here is what the Microsoft implementation does: 1. The EAP-Success packet is considered an invalid packet and is dropped. Local state remains unaffected 2. If the packet is not as per the state requirements, the packet the dropped. Local state remains unaffected 3. EAP-Failure will cause the state to go into HELD state. However, it does not cause any local data deletion e.g. cleaning out of identity locally, user data etc. If 3 valid failures are detected, the WLAN connection will be put into a blocked state. From yohba@tari.toshiba.com Tue Jan 14 12:50:13 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Tue, 14 Jan 2003 07:50:13 -0500 Subject: [eap] Proposed Resolution to Issue 62: Accept In-Reply-To: References: <20030113185206.GA2306@catfish> Message-ID: <20030114125013.GA671@catfish> This looks fine with me. Thanks, Yoshihiro Ohba On Mon, Jan 13, 2003 at 10:33:04PM -0800, Bernard Aboba wrote: > > The following text I found in section 4.1 seems not always mandating > > silent discard for invalid packets. > > > > If a peer receives a valid duplicate Request for which it has already > > sent a Response, it MUST resend its original Response. If a peer > > receives a duplicate Request before it has sent a Response to a valid > > initial Request (i.e. it's waiting for user input), it MUST silently > > discard the duplicate Request. An EAP message may be found invalid > > for a variety of reasons: failed link layer CRC or checksum, > > malformed EAP packet, EAP method-specific MIC, etc. > > How about this? > > If a peer receives a valid duplicate Request for which it has already > sent a Response, it MUST resend its original Response. If a peer > receives a duplicate Request before it has sent a Response, but after > it has determined the initial Request to be valid (i.e. it is wait- > ing for user input), it MUST silently discard the duplicate Request. > An EAP message may be found invalid for a variety of reasons: failed > lower layer CRC or checksum, malformed EAP packet, EAP method MIC > failure, etc. > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Tue Jan 14 15:57:45 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 14 Jan 2003 07:57:45 -0800 (PST) Subject: [eap] Possible solution to Issue 52: Identity Requery In-Reply-To: <15908.12524.466172.499912@gargle.gargle.HOWL> Message-ID: It strikes me that the "unexpected method" case is actually a subset of the sequence problem, and therefore that the approach taken there applies: a. Sequences are "not anticipated". Similarly, the text could say that switching in mid-stream is discouraged. b. The correct response is a Nak. As James pointed out, a Response is required, so as in a sequence, the Nak is the correct Response, if the Type is not desired. On the authenticator side, I'd argue that a Nak including a Type that was already sent should be logged (evidence of a potential attack), but otherwise ignored. c. Some implementations may silently discard. So switching methods in mid-stream may not result in a response. Here is some proposed text for Section 2.1: An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However, within or associated with each EAP server, it is not anticipated that a particular named peer will utilize multiple authentication methods (Type 4 or greater), either by supporting a choice of methods or by using multiple methods in sequence. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set (negotiation attacks, described in Sec- tion 7.9) or man-in-the-middle attacks (described in Section 7.5). Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. If additional authentication methods are required beyond the initial one, the authenticator MAY send a Request packet for a subsequent authentication method, or it MAY send another Identity request. If the peer does not support additional authentication methods, after complet- ing the last supported authentication method, it SHOULD respond to a subsequent Request with a Nak, indicating no acceptable alternative, as described in Section 5.3. However, peer implementations MAY not respond at all, in which case a timeout will result and authentication will fail. Since the authenticator presumably requires successful completion of the sequence in order to grant access, authentication failure is the correct result. Therefore, it is not necessary for the authenticator to determine that the peer supports sequences prior to sending a Request for a subsequent authentication method. The above prescription also applies in the situation where an authenticator sends a message of a different Type prior to completion of the final round of a given method. If the peer wishes to continue authenticating with the method in progress, it SHOULD send a Nak in response to such a Request, indicating the Type in progress as the alternative. Otherwise it MAY send a Response with the same Type as the Request. Since an EAP packet with a different Type may be sent by an attacker, an authenticator receiving a Nak including a preference for the Type in progress SHOULD log the event, but otherwise not take any action. Once a peer has sent a Response of the same Type as a Request, some existing peer implementations might expect the method to run to completion. As a result, these implementations silently discard EAP Requests of a Type different from the method in progress, despite the requirement for a Response in section 2.2.1. For this reason, EAP authenticators that must interoperate with these peers are discouraged from switching methods before the final round of a given method has completed. From aboba@internaut.com Tue Jan 14 19:26:57 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 14 Jan 2003 11:26:57 -0800 (PST) Subject: [eap] Re: EAP conversation model In-Reply-To: <15908.25136.869901.592843@gargle.gargle.HOWL> Message-ID: > Now *that's* a creative interpretation. ;-} > > My understanding of Nak is that it means "I refuse to use that > authentication type; please offer me another acceptable way to prove > my identity to you." Using it to mean "this type might possibly be > valid a little later on, but it's not valid right at the moment > because I was expecting you to say something else" seems pretty odd. > It would likely lead to non-converging patterns (send Type A, send > Type B, get Nak, go back to Type A ...). Yes, I can see that. This is part of the complexity created by sequences. The reason I suggested this "creative" interpretation was because that Nak Response might be interpretted as innocuous by the authenticator in case the Type B Request was spoofed by an attacker. If the Peer instead responds with a Nak indicating no alternative (0), it's not clear to me what the authenticator should do (assuming that it didn't send the Type B Request). > Not that it perhaps matters, but this new interpretation is also at > odds with what "nak" means in the PPP context. Can you expand on that? > > Good point. I'd say the authenticator isn't "inside" a method until it > > receives a Response with the same type as the initial Request. > > So, with that, I think you need language in the Nak to handle this > case as well. "An Authenticatee MUST NOT send Nak in response to any > message other than the initial Request for a given method; a secondary > Request within a single method MUST NOT elicit a Nak in response. An > Authenticator SHOULD ignore a Nak if received in response to any > message other than the initial Request." > > This brings us to the odd position that, if you're doing sequences, > then it's perfectly reasonable to get Nak on the third method of some > longer sequence, but *not* in the middle of any one of the methods in > the sequence. Since you have to be able to handle one but not the > other, that seems baroque and still quite unnecessary. > > (Yes, I'm just following you down this path. I still don't agree with > it.) I think this is a logical implication of that path. Although since we now have language discouraging sequences hopefully this will not be too prevalent. > > Because that allows an attacker to bring down the link by sending such a > > packet. > > We can't fix that with the tools we're using. EAP assumes some > measure of security from the lower layer such that you already know > that you're talking to *one* peer -- you just don't know *who* that > peer might be. In the case where the link isn't physically secure, the question is whether that security is turned on yet. If the L2 ciphersuite is dynamically keyed, per-packet integrity and authentication can't be enabled until quite late in the conversation. > It still doesn't make any sense to me. Why continue sending Request > messages if the peer has told you that he doesn't know what you're > talking about? Why not either (a) disconnect or (b) assume that the > peer has an implementation bug in that method and try a different one. I guess the difference is between an approach that says "bring the link down if you detect that the other implemention is broken or you're under attack" or "try to persevere anyway". > > That has some undesirable DoS implications. > > I'm still lost on the DoS argument. It seems to imply that the peers > are either open to all attackers on a given link (i.e., 802.11 with no > link security) or that the peer under attack but is unable to shut > down the affected link. If it's the former, then I think we're stuck > because EAP just doesn't address that problem. It rather strongly > assumes that you're talking to exactly one peer. If it's the latter, > then that's an implementation bug -- if you're getting packets you > don't like, then you should stop listening, and you really should not > expect the protocol to save you from ruin. Where EAP is used on wireless networks without L2 ciphersuites in place, the peer is indeed open to attack from anyone within range. If an attacker can cause the peer and authenticator to redo a complete authentication exchange (including public key computations in some cases) by sending only one packet, it seems to me that this provides a lot of leverage for the attacker. If one can assume that the EAP method MICs its own packets, then the remaining forgery threats come from Identity, Notification, Nak, Success, Failure and packets of other Types. Notification doesn't change state, so we can probably ignore it. We can restrict Nak forgeries to particular times in the conversation; Success and Failure forgeries are discussed in Section 4.2.1. Identity can be checked against message-specific identity exchanges (such as certs). So we're left with packets from wrong Types. If we can limit the opportunities for forgery here, we have a narrowed the potential forgery threats somewhat, I'd think. From james.d.carlson@east.sun.com Tue Jan 14 21:31:40 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Tue, 14 Jan 2003 16:31:40 -0500 Subject: [eap] Re: EAP conversation model In-Reply-To: Bernard Aboba's message of 14 January 2003 11:26:57 References: <15908.25136.869901.592843@gargle.gargle.HOWL> Message-ID: <15908.33212.760015.878154@gargle.gargle.HOWL> Bernard Aboba writes: > > Now *that's* a creative interpretation. ;-} > > > > My understanding of Nak is that it means "I refuse to use that > > authentication type; please offer me another acceptable way to prove > > my identity to you." Using it to mean "this type might possibly be > > valid a little later on, but it's not valid right at the moment > > because I was expecting you to say something else" seems pretty odd. > > It would likely lead to non-converging patterns (send Type A, send > > Type B, get Nak, go back to Type A ...). > > Yes, I can see that. This is part of the complexity created by sequences. > The reason I suggested this "creative" interpretation was because that Nak > Response might be interpretted as innocuous by the authenticator in case > the Type B Request was spoofed by an attacker. If the Peer instead > responds with a Nak indicating no alternative (0), it's not clear to me > what the authenticator should do (assuming that it didn't send the Type B > Request). It's not different from getting any other Type value in a Nak that you don't recognize, support, or allow: if you don't like the peer's suggestion, then you at least know that the peer doesn't implement, support, or allow the Type you're currently using, but you know nothing else. A robust implementation would scratch the current Type off the list of possible ways to authenticate this client and try the next permitted one in the hope that, although the peer didn't suggest this particular Type as the "right" one to use, we have nothing to lose by trying. > > Not that it perhaps matters, but this new interpretation is also at > > odds with what "nak" means in the PPP context. > > Can you expand on that? Configure-Nak in PPP means "I don't like the option you gave me, but if you try it this other way, I might possibly respond." You specifically MUST NOT send it to mean "try again later." "Try again later" is implemented as discard because "Configure-Nak" carries with it the implication that the current value is itself unacceptable -- "please don't try this again." > > We can't fix that with the tools we're using. EAP assumes some > > measure of security from the lower layer such that you already know > > that you're talking to *one* peer -- you just don't know *who* that > > peer might be. > > In the case where the link isn't physically secure, the question is > whether that security is turned on yet. If the L2 ciphersuite is > dynamically keyed, per-packet integrity and authentication can't be > enabled until quite late in the conversation. Why isn't that just a design error? > > It still doesn't make any sense to me. Why continue sending Request > > messages if the peer has told you that he doesn't know what you're > > talking about? Why not either (a) disconnect or (b) assume that the > > peer has an implementation bug in that method and try a different one. > > I guess the difference is between an approach that says "bring the link > down if you detect that the other implemention is broken or you're under > attack" or "try to persevere anyway". Yes. As we've noted several times, the simple way the EAP exchange works does *not* lend itself to detecting attacks. I think you'd need to integrate peer-to-peer security into EAP itself to do that, and you'd end up with a different protocol at that point. Maybe IKE. > > I'm still lost on the DoS argument. It seems to imply that the peers > > are either open to all attackers on a given link (i.e., 802.11 with no > > link security) or that the peer under attack but is unable to shut > > down the affected link. If it's the former, then I think we're stuck > > because EAP just doesn't address that problem. It rather strongly > > assumes that you're talking to exactly one peer. If it's the latter, > > then that's an implementation bug -- if you're getting packets you > > don't like, then you should stop listening, and you really should not > > expect the protocol to save you from ruin. > > Where EAP is used on wireless networks without L2 ciphersuites in place, > the peer is indeed open to attack from anyone within range. If an attacker > can cause the peer and authenticator to redo a complete authentication > exchange (including public key computations in some cases) by sending only > one packet, it seems to me that this provides a lot of leverage for the > attacker. I see. So what stops an attacker from beating the legitimate client to the punch and sending the initial Identity Response message? EAP Authenticator Legit Authenticatee Attacker EAP Identity Request -> <------------------------- EAP Identity Response <- EAP Identity Response If that happens, then the legitimate guy loses out -- and the exchange is vulnerable to DoS attacks. Period. I still don't see the DoS issue that EAP can actually be expected to handle in some reasonable way. If you don't have an acceptable level of security on the link such that you know there's at most one peer out there from the moment of the first EAP message, I think you're simply not in any position to fix this problem. Trying to defend against "some" DoS attacks while leaving obvious other ones wide open is just a way of rearranging the deck chairs. The ship is still on its way down. > Notification doesn't change state, so we can probably ignore it. We can > restrict Nak forgeries to particular times in the conversation; Success > and Failure forgeries are discussed in Section 4.2.1. Identity can be > checked against message-specific identity exchanges (such as certs). So > we're left with packets from wrong Types. If we can limit the > opportunities for forgery here, we have a narrowed the potential forgery > threats somewhat, I'd think. I don't think so. Attackers can inject these messages at _any_ point, and the result is the same. Let's suppose that we have the new "no new mid-stream horses" language in the draft. An effective DoS attack would be to watch for carrier from new clients and shove EAP Request messages down the client's craw before the NAP can get the first "real" one out. Even a replayed EAP Request will do the job here, and since the attacker doesn't have to do any difficult numeric conjuring, it's likely that he has time to spare in this effort. If this is done, and the client responds, then you're stuck. The NAP isn't allowed to "change type" in the middle of the conversation, and the attacker isn't really going to authenticate the client. The there are two answers that make sense to me with EAP (and it's likely that the second is just a possible implementation of the first): 1. Assume that the link has an acceptable level of security first. How you achieve that in practice is a topic for the "EAP on Foo" drafts and the administrators of access devices, not the base EAP document. For a wireless application, I'd expect the L2 link to do an anonymous key exchange of some sort first. 2. Write a method draft for insecure links that intentionally redefines parts of EAP -- disallowing Identity and Nak, using an initial Request/Response exchange to set up a shared key, defining MIC behavior, and so forth. Nothing stops a method draft from rewriting history. (I don't think it's necessarily a good idea, but it's clearly not without precedent.) I don't see why any of that would constitute issues for the base document, unless we're planning to redefine EAP to include a protected key exchange before any "real" data are sent. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From aboba@internaut.com Tue Jan 14 23:26:12 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 14 Jan 2003 15:26:12 -0800 (PST) Subject: [eap] draft-vollbrecht-eap-state-00.txt (fwd) Message-ID: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : State Machines for EAP Peer and Authenticators Author(s) : J. Vollbrecht, D. Spence Filename : draft-vollbrecht-eap-state-00.txt Pages : 9 Date : 2003-1-13 The specification for the Extensible Authentication Protocol (EAP) [2] does not include a state machine. The EAP working group would like to include a state machine for peer and authenticator. This might be a separate RFC describing the state machine, or it might be incorporated in a revised EAP RFC. There is at least one other Internet Draft that has been submitted that describes a state machine for EAP. This memo describes a state machine based on an EAP 'Switch' model. This model includes an additional set of events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the model is given in the next section. The EAP design working group has discussed the EAP Switch model as a way to describe EAP protocol interactions. This document is based on a position paper discussed in the design group and discusions on conference calls about the paper. This document is still a work in progress. In particular the handling of integrity checks for the authenticator has not been worked out, and more discussion is needed to get consensus on retransmission support. There is still active discussion on how to mitigate potential Denial of Service Attacks which will need to be integrated. Finally, this does not support being able to send and receive Notify method in the middle of other methods, and this will be added in a future revision. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-vollbrecht-eap-state-00.txt". From jrv@umich.edu Wed Jan 15 03:16:00 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 14 Jan 2003 22:16:00 -0500 Subject: [eap] Re: [Issue 61] Support for EAP Sequences In-Reply-To: References: Message-ID: <15594602.1042582559@[10.0.1.2]> --On Saturday, January 11, 2003 6:40 AM -0800 Bernard Aboba wrote: > > I suspect that fear need not be true for an implementation that was > > exceedingly careful (that is, one that ran each authentication method > > regardless of the intermediate result of each, and then sent Success > > after *all* had been run only if all had passed). But given the > > tendency for mistakes, and the likely uselessness of the "feature," it > > seems reasonable to suggest that it's not a good idea. > I don't think the feature is useless. I think being able to have multiple methods talking between the AS and Client can be quite powerful. The ability to negotiate with the user directly about the value of QoS features is an example. There are others. > The RFC 2284 text (below) was modified under the assumption that it > did not apply to sequences. However, given your concerns > and the recent work on man-in-the-middle attacks, that may not have been > appropriate. > > This was the RFC 2284 text: > > In practice, within or associated with each PPP server, it is not > anticipated that a particular named user would be authenticated by > multiple methods. This would make the user vulnerable to attacks > which negotiate the least secure method from among a set (such as PAP > rather than EAP). Instead, for each named user there should be an > indication of exactly one method used to authenticate that user name. > If a user needs to make use of different authentication methods under > different circumstances, then distinct identities SHOULD be employed, > each of which identifies exactly one authentication method. > My understanding of this text is that only one authentication method should be supported by the Authenticator - negotiating MD5 rather than SIM is not allowed for example. However I do not read it as saying that a sequence of methods with other purposes could not be run. > How about this: > > In practice, within or associated with each EAP server, it is not > anticipated that a particular named user would be authenticated by > multiple methods, either in by offering a choice or by using multiple > methods in sequence. This would make the user vulnerable to attacks > which negotiate the least secure method from among a set ( > negotiation attacks, described in Section 7.9) or man-in-the-middle > attacks (described in Section 7.5) Instead, for each named user there > SHOULD be an indication of exactly one method used to authenticate that > user name. If a user needs to make use of different authentication methods > under different circumstances, then distinct identities SHOULD be > employed, each of which identifies exactly one authentication method. > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Wed Jan 15 04:07:26 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 14 Jan 2003 20:07:26 -0800 (PST) Subject: [eap] Re: [Issue 61] Support for EAP Sequences In-Reply-To: <15594602.1042582559@[10.0.1.2]> Message-ID: > I don't think the feature is useless. I think being able to have multiple > methods talking between the AS and Client can be quite powerful. The > ability to negotiate with the user directly about the value of QoS features > is an example. There are others. EAP is supposed to be for authentication only. The link layer typically has the negotiation facilities. So it's not clear to me why QoS signalling is an important feature to enable in EAP. From jrv@umich.edu Wed Jan 15 08:12:29 2003 From: jrv@umich.edu (John Vollbrecht) Date: Wed, 15 Jan 2003 03:12:29 -0500 Subject: [eap] Re: [Issue 61] Support for EAP Sequences Message-ID: <91922.1042600349@[10.0.1.2]> --On Tuesday, January 14, 2003 8:07 PM -0800 Bernard Aboba wrote: > > I don't think the feature is useless. I think being able to have > > multiple methods talking between the AS and Client can be quite > > powerful. The ability to negotiate with the user directly about the > > value of QoS features is an example. There are others. > > EAP is supposed to be for authentication only. The link layer typically > has the negotiation facilities. So it's not clear to me why QoS signalling > is an important feature to enable in EAP. > I have never thought of it as for authentication only. That is the primary initial use of it, but I see no reason to limit it to that. My model is that it provides a way for a Client and AAA Server to have a conversation as part of access control. Whether the conversation is strictly about authentication or about what parameters the client would like to have, or what parameters the Net is prepared to provide seems to me to be within the bounds of what is natural and reasonable, and not outside the intent of the original RFC. I don't think we should make decisions on what it will be used for based only on what it has been used for. We could be surprised - hopefully pleasantly. From aboba@internaut.com Wed Jan 15 16:06:35 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 15 Jan 2003 08:06:35 -0800 (PST) Subject: [eap] Yet another (less feable?) proposal to resolve Issue 49 Message-ID: During the EAP Design Team discussion today, we concluded that whether the lower layer provides protection or not was irrelevant to the processing of EAP Success and Failure messages. Given this, we have rewritten the potential text for Section 4.2.1 as follows: 4.2.1. Processing of success and failure Within EAP, success and failure indications consist of the EAP Success and Failure messages, as well as method-specific indications. Within EAP, these indications may be protected or unprotected. EAP Success and Failure packets are considered unprotected indications which may be spoofed, since as described in Section 4.2, they contain no message integrity check. In order to provide additional protection against tampering, EAP methods MAY support a MIC that covers some or all of the EAP packet, including headers. It is also possible for a MIC defined within an EAP method to in addition include coverage of previous Request and Response messages. EAP methods also MAY include support for method-specific acknowledged success and failure indications. This enables the authenticator to indicate whether the peer has successfully authenticated, as well as for the peer to acknowledge receipt of that indication, and respond with an indication of whether the authenticator has successfully authenticated to the peer. If a key has previously been derived, the result exchange MAY be protected by a Message Integrity Check (MIC), and if so, then this success/failure indication is consid- ered protected. In order to protect against spoofing of success and failure indications, EAP implementations SHOULD obey the following processing rules: [a] Processing of protected success and failure indications. Where a success/failure indication has been received that is protected within EAP, the implementation MUST validate the EAP method MIC, with a MIC failure handled via silent discard, as specified in Sec- tion 4.1. [b] Receipt of EAP Success and Failure packets prior to method completion. A peer EAP implementation receiving an EAP Success packet prior to completion of the method in progress MUST silently discard it. This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. A peer EAP implementation receiving an EAP Failure packet prior to completion of the method in progress MAY silently discard it. [c] Authentication requirement. An EAP peer implementation that has been configured to require authentication MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). [d] Contradictory indications. Where protected and unprotected result indications are both available, protected indications take precedence. For example, where an EAP method provides a protected indication that authentication failure has occurred in either direction, the implementation MUST silently discard subsequent EAP Success packets. Similarly, where an EAP method provides a protected indication that authentication has succeeded in both directions, the EAP implementation MAY silently discard EAP Failure packets. [e] Processing of EAP Success and Failure in the absence of protected indications. Subsequent to the completion of the EAP authentication method (Types 4 and greater), and in the absence of protected result indications, EAP Success and Failure packets MUST be accepted and processed by the EAP implementation. From npetroni@cs.umd.edu Wed Jan 15 18:32:03 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Wed, 15 Jan 2003 13:32:03 -0500 (EST) Subject: [eap] Yet another (less feable?) proposal to resolve Issue 49 In-Reply-To: Message-ID: > [b] Receipt of EAP Success and Failure packets prior to method completion. > A peer EAP implementation receiving an EAP Success packet > prior to completion of the method in progress MUST silently discard > it. This ensures that a rogue authenticator will not be > able to bypass mutual authentication by sending an EAP Success > prior to conclusion of the EAP method conversation. > A peer EAP implementation receiving an EAP Failure > packet prior to completion of the method in progress MAY silently > discard it. The concept of protected success and failure has been discussed for some time, but in light of recent discussions distinguishing between "Method Failure" and "Authenticator Failure" I would like to inquire as to the implications on protected success and failure. Because such messages would invariably be sent as Method messages, is it possible for the method to claim it actually speaks for the overall conversation? We have previously established that a method could succeed, but authentication fail overall. Ideally, one would not utilize a method with protected success in a manner that would allow this, but I am unsure how this fits into the current framework. Yoshihiro's comments on the previous state machine draft were insightful in showing that a method failure should not necessarily indicate auth failure, but protected success seems to imply that we actually do trust some methods to make this decision. Given that discarding failure messages is a MAY, this might not be an issue. Still, I am having trouble viewing this in terms of the state machine. A related question, for my own information, is what should be represented in the state machine- only MUST and SHOULD behavior, or MAY as well. From aboba@internaut.com Wed Jan 15 17:43:14 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 15 Jan 2003 09:43:14 -0800 (PST) Subject: [eap] Yet another (less feable?) proposal to resolve Issue 49 In-Reply-To: Message-ID: > The concept of protected success and failure has been discussed for some > time, but in light of recent discussions distinguishing between "Method > Failure" and "Authenticator Failure" I would like to inquire as to the > implications on protected success and failure. Because such messages would > invariably be sent as Method messages, is it possible for the method to > claim it actually speaks for the overall conversation? I don't think it can -- but perhaps there are some constraints that can be placed on the overall conversation as a result. > We have previously > established that a method could succeed, but authentication fail overall. Yes. > Ideally, one would not utilize a method with protected success in a > manner that would allow this, but I am unsure how this fits into the > current framework. I think it is possible to utilize it that way. For example, say I invent a method that has protected Success/Failure, and the authentication succeeds in both directions, but there is a constraint that the user can only have one simultaneous login. Once the authentication succeeds the AAA server does a database lookup, finds several simultaneous conversations and decides to deny access. So it *could* send an EAP Failure after a successful authentication. > Yoshihiro's comments on the previous state machine > draft were insightful in showing that a method failure should not > necessarily indicate auth failure, but protected success seems to imply > that we actually do trust some methods to make this decision. This one is more controversial -- because I'd claim that if the authenticator doesn't authenticate to the peer then accepting an unprotected success indication is dangerous -- it opens the peer up to connecting to a rogue authenticator. Maybe this is only at the level of a SHOULD though -- there might be circumstances where alternative behavior might be allowed, but you'd have to think it through carefully (physically secure media?). > Given that > discarding failure messages is a MAY, this might not be an issue. It was left as a MAY for implementations that want a high level of security, and have circumstances that permit this. But it can have side effects (lots of timeouts) so making it the default behavior may not be wise. Of course this enables some DoS attacks. > A related question, for my own information, is what should be represented > in the state machine- only MUST and SHOULD behavior, or MAY as well. I'd suggest that we try to illustrate as much behavior as possible, perhaps by including variables that define what behaviors will be exhibited. From npetroni@cs.umd.edu Wed Jan 15 19:35:40 2003 From: npetroni@cs.umd.edu (Nick Petroni) Date: Wed, 15 Jan 2003 14:35:40 -0500 (EST) Subject: [eap] Yet another (less feable?) proposal to resolve Issue 49 In-Reply-To: Message-ID: > > implications on protected success and failure. Because such messages would > > invariably be sent as Method messages, is it possible for the method to > > claim it actually speaks for the overall conversation? > > I don't think it can -- but perhaps there are some constraints that can be > placed on the overall conversation as a result. I agree. > > Ideally, one would not utilize a method with protected success in a > > manner that would allow this, but I am unsure how this fits into the > > current framework. > > I think it is possible to utilize it that way. For example, say I invent a > method that has protected Success/Failure, and the authentication succeeds > in both directions, but there is a constraint that the user can only have > one simultaneous login. Once the authentication succeeds the AAA server > does a database lookup, finds several simultaneous conversations and > decides to deny access. So it *could* send an EAP Failure after a > successful authentication. I agree here as well. > > Yoshihiro's comments on the previous state machine > > draft were insightful in showing that a method failure should not > > necessarily indicate auth failure, but protected success seems to imply > > that we actually do trust some methods to make this decision. > > This one is more controversial -- because I'd claim that if the > authenticator doesn't authenticate to the peer then accepting an > unprotected success indication is dangerous -- it opens the peer up to > connecting to a rogue authenticator. The question in my mind comes down to basically what value protected failures have. Yes, it's true that if you know you failed the conversation you don't want to accept a success, but that is true even if you never received a "protected" failure. The fact that you have yet to mutually authenticate is the real reason not to accept success. Furthermore, even with a protected failure, you might want to continue with another method anyway. Similarly, protected success doesn't do much more than say the the current method has finished successfully. It doesn't mean you should necessarily neglect an unprotected failure that follows (as stated above), right? I am understanding the protected success/failure methods to only indicate success or failure of the method, in which case I am unclear how the EAP conversation is really affected by them. > > in the state machine- only MUST and SHOULD behavior, or MAY as well. > > I'd suggest that we try to illustrate as much behavior as possible, > perhaps by including variables that define what behaviors will be > exhibited. Ok. From aboba@internaut.com Wed Jan 15 20:36:42 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 15 Jan 2003 12:36:42 -0800 (PST) Subject: [eap] Yet another (less feable?) proposal to resolve Issue 49 In-Reply-To: Message-ID: > The question in my mind comes down to basically what value protected > failures have. That's my question, too. > Yes, it's true that if you know you failed the conversation > you don't want to accept a success, but that is true even if you never > received a "protected" failure. The question is where the failure occurred. If the peer knows that the authenticator failed to authenticate to it, then presumably that will cause it to not accept a "Success" -- but accepting a Failure is fine. On the other hand, if the authenticator has told the peer "you succeeded in authenticating to me", then it is possible that a Failure could be sent afterward. It's also possible that such a Failure might be inauthentic, and will soon be followed by the "real" Success indication. Which one does the peer believe? > The fact that you have yet to > mutually authenticate is the real reason not to accept > success. Yes. I'd also claim Success should not be accepted if the authenticator tells you in a protected way that you've failed to authenticate to it. > Furthermore, even with a protected > failure, you might want to continue with another method anyway. If the authenticator tells the peer that "you've failed to authenticate successfully" it is possible that a retry will occur, yes. The peer only gets to decide whether it will send a Respond to the Request or a Nak. > Similarly, protected success doesn't do much more than say that the > method has finished successfully. It doesn't mean you should necessarily > neglect an unprotected failure that follows (as stated above), right? I think this is a bit like the handling of ICMP messages in IPsec. A host MAY act on those (unprotected) messages, but it also may choose to ignore them and wait for a timeout. Most implementations wait for the timeout -- but this is a source of continuing aggravation when the Responder doesn't support IKE. > I am understanding the protected success/failure methods to only indicate > success or failure of the method, in which case I am unclear how the EAP > conversation is really affected by them. That's what we're trying to figure out :) From yohba@tari.toshiba.com Wed Jan 15 22:46:16 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 15 Jan 2003 17:46:16 -0500 Subject: [eap] Yet another (less feable?) proposal to resolve Issue 49 In-Reply-To: References: Message-ID: <20030115224616.GE775@catfish> On Wed, Jan 15, 2003 at 09:43:14AM -0800, Bernard Aboba wrote: > I think it is possible to utilize it that way. For example, say I invent a > method that has protected Success/Failure, and the authentication succeeds > in both directions, but there is a constraint that the user can only have > one simultaneous login. Once the authentication succeeds the AAA server > does a database lookup, finds several simultaneous conversations and > decides to deny access. So it *could* send an EAP Failure after a > successful authentication. > This implies that EAP Success/Failure message is used as an indication of an authorization result as well as an authentication result. A valid MIC for EAP Failure indicates "you are successfully authenticated" and the EAP code (i.e., Failure) indicates "but sorry, you are not authorized for some reason". The same interpretation might be possible for method-specific success/failure indication. On the other hand, it might be also possible to define success/failure indication differently, i.e., it indicates an authentication result only, not an authorization result. If we take this definition, the authenticator should not return an EAP Failure message when the peer is successfully authenticated. Yoshihiro Ohba From aboba@internaut.com Sun Jan 19 06:16:16 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 18 Jan 2003 22:16:16 -0800 (PST) Subject: [eap] Re: Proposed resolution of issue #41 In-Reply-To: <4.1.20021215130655.0270ed40@mail.funk.com> Message-ID: > >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. OK. James has suggested that could include a Nak packet with a single Type value of 0, to indicate no alternative. Would it also be possible for such a legacy Nak to include more than one Type? > 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. OK on the 8-octet format for Type-Data. However, the structure of the Nak packet itself is defined in RFC 2284: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Type-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Code = 2 (Response) Type = 3 (Nak) Are you proposing to change the format of the Nak packet? > 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. Yes, within the new Nak, the 8-octet format would be used within the Type-Data field: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Is this right? > 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. Are you saying that the legacy Nak has Type field =3, and Type-Data equal to one or more Type values? Note that James has suggested reserving the Type value of 0 to mean "no alternative". > This type of Nak provides backward compatibility for peers that > implement RFC2284 or earlier. Yes. > >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. 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. OK. That makes sense. > 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. I think this is where I am losing you. It would probably help to show all the fields of the EAP packet. For example, an extended Nak proposing two alternative Types, both within the IETF standard space would look like this, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code (2) | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (3) | 254 | Vendor-Id (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VID (0) | Vendor-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V-Type | Vendor-Id (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > There is a typo in my original example, which may be causing confusion. The > single octet "4" should be a "254". OK. Is the above example now correct? > Your two examples are correct, except for the omission of the extended Nak > type itself. Isn't this represented above by the "254" in the first octet of the Type-Data field? > 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OK. This is more clear. Question: Why the need for additional "254" octets after the first one? Is this just to maintain alignment? Otherwise, I think we're in agreement. From aboba@internaut.com Sun Jan 19 06:56:48 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 18 Jan 2003 22:56:48 -0800 (PST) Subject: [eap] Proposed Resolution to Issue 41: Nak of Extended Types Message-ID: I would like to propose that we modify the text of Section 5.3 (Nak) as follows to take into account the changes proposed by Paul Funk and James Carlson. 5.3. Nak Description 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 one or more authentication Types desired by the Peer. Type zero (0) is used to indicate that the sender has no viable alternatives. Since the Nak Type is only valid in Responses and has very limited functionality, it MUST NOT be used as a general purpose error indication, such as for communication of error messages, or negotiation of parameters specific to a particular EAP method. Code 2 for Response. Identifier The Identifier field is one octet and aids in matching Responses with Requests. The Identifier field of a Nak Response MUST match the Identifier field of the Request packet that it is sent in response to. Length >=6 Type 3 Type-Data Where the Request contains a Type within the original EAP Type space (1-253, 255), or the Request contains an expanded Type as defined in Section 5.7, but the peer does not support the expanded Type space, then the Type-Data field MUST contain one or more octets indicating the desired authentication Type(s) within the original EAP Type space (one octet per type), or the value zero (0) to indicate no proposed alternative. If the Request contains an expanded Type as defined in Section 5.7, and the peer supports the expanded Type space, and desires to offer at least one alternative method within that expanded space, then the Type-Data field MUST contain one or more expanded format entries, all of which MUST be in the following format (see Section 5.7 for details on the Vendor-Id and Vendor-Type fields): 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------------------------------------------------------------- Issue 41: NAK of Extended Types Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 23, 2002 Reference: Document: RFC2284bis-07 Comment type: T Priority: S Section: 5.3 Rationale/Explanation of issue: Currently it is not possible to effectively NAK within the Extended EAP type space. For example, what happens when the authenticator proposes an Extended or Vendor-Specific EAP Type, and the client supports the Extended type (255), but not the vendorID or Extended Type that is being proposed? From aboba@internaut.com Sun Jan 19 07:24:05 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 18 Jan 2003 23:24:05 -0800 (PST) Subject: [eap] Possible Resolution to Issue 52: Identity requery Message-ID: The following changes are offered as a potential solution to Issue 52: Identity Requery. The proposed resolution does not state explicitly how many times the Identity method may be used; this is handled generally in Section 2.l, which covers Sequences. Similarly, this section also recommends what is to be done if a Type is "unexpected". Note that the implication is that an Identity Request could be Nak'd in that situation (which is why the MUST was weakened to SHOULD in the first paragraph of Section 5.1). Change the first paragraph of Section 5.1 to: "The Identity Type is used to query the identity of the peer. Generally, the authenticator will issue this as the initial Request. An optional displayable message MAY be included to prompt the peer in the case where there expectation of interaction with a user. A Response of Type 1 (Identity) SHOULD be sent in Response to a Request with a Type of 1 (Identity)" Change Section 2.1 to the following: "An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However, within or associated with each EAP server, it is not anticipated that a particular named peer will utilize multiple authentication methods (Type 4 or greater), either by supporting a choice of methods or by using multiple methods in sequence. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set (negotiation attacks, described in Section 7.8) or man-in-the-middle attacks (described in Section 7.4). Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. If additional authentication methods are required beyond the initial one, the authenticator MAY send a Request packet for a subsequent authentication method, or it MAY send another Identity request. If the peer does not support additional methods, it SHOULD respond with a Nak, indicating no acceptable alternative, as described in Section 5.3. However, peer implementations MAY not respond at all, in which case a timeout will result and authentication will fail. Since the authenticator presumably requires successful completion of the sequence in order to grant access, authentication failure is the correct result. Therefore, it is not necessary for the authenticator to determine that the peer supports sequences prior to sending a Request for a subsequent authentication method. The above prescription also applies in the situation where an authenticator sends a message of a different Type prior to completion of the final round of a given method. If the peer wishes to continue authenticating with the method in progress, it SHOULD send a Nak in response to such a Request, indicating the Type in progress as the alternative. Otherwise it MAY send a Response with the same Type as the Request. Since an EAP packet with a different Type may be sent by an attacker, an authenticator receiving a Nak including a preference for the Type in progress SHOULD log the event, but otherwise not take any action. Once a peer has sent a Response of the same Type as a Request, some existing peer implementations might expect the method to run to completion. As a result, these implementations silently discard EAP Requests of a Type different from the method in progress, despite the requirement for a Response in section 2.2.1. For this reason, EAP authenticators that must interoperate with these peers are discouraged from switching methods before the final round of a given method has completed." ------------------------------------------------------------------------- Issue 52: Identity requery Submitter name: James Carlson Submitter email address: james.d.carlson@sun.com. Date first submitted: January 2, 2003 Document: RFC2284bis Comment type: T Priority: 1 Section: 5.1 Rationale/Explanation of issue: The restriction doesn't appear to be warranted. There's no visible difference between, for example, an authenticator suddenly deciding to start authentication over because the current method cannot proceed (which should be allowed), and sending an Identity message in the "middle" of a method (which has been proscribed). Since there's no distinction, the requirements can't be different. Requested change: from: The Identity Type is used to query the identity of the Peer. The Authenticator will typically issue this as the initial Request; however, an Identity Request MAY also be sent multiple times within a sequence of methods. An Identity Request MUST NOT be sent in the middle of another method conversation. to: The Identity Type is used to query the identity of the Peer. The Authenticator will typically issue this as the initial Request; however, an Identity Request MAY be sent at any time. From aboba@internaut.com Sun Jan 19 07:27:45 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sat, 18 Jan 2003 23:27:45 -0800 (PST) Subject: [eap] Proposed resolution to Issue 49: Spoofing of EAP Success/Failure Message-ID: For Section 4.2.1, substitute: "4.2.1. Processing of success and failure Within EAP, success and failure indications consist of the EAP Success and Failure messages, as well as method-specific indications. Within EAP, these indications may be protected or unprotected. EAP Success and Failure packets are considered unprotected indications which may be spoofed, since as described in Section 4.2, they contain no message integrity check (MIC). In order to provide additional protection against tampering, EAP methods MAY support a MIC that covers some or all of the EAP packet, including headers. In addition, such a MIC MAY include coverage of previous Request and Response messages, so as to enable protection of other packets to that do not contain MICs, such as Identity Request/Response, Notification Request/Response and Nak Response. EAP methods also MAY include support for method-specific acknowledged success and failure indications. This enables the authenticator to indicate whether the peer has successfully authenticated, as well as for the peer to acknowledge receipt of that indication, and respond with an indication of whether the authenticator has successfully authenticated to the peer. If a key has previously been derived, the result exchange MAY be protected by a Message Integrity Check (MIC), and if so, then this success/failure indication is considered protected. In order to decrease vulnerability to spoofing of success and failure indications, the following processing rules are recommended: [a] Processing of protected success and failure indications. Where a method-specific protected success/failure indication has been received, the implementation MUST validate the EAP method MIC, with a MIC failure handled via silent discard, as specified in Section 4.1. [b] Receipt of EAP Success and Failure packets prior to method completion. A peer EAP implementation receiving an EAP Success packet prior to completion of the method in progress MUST silently discard it. This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. A peer EAP implementation receiving an EAP Failure packet prior to completion of the method in progress MAY silently discard it. When using EAP methods that provide their own (protected) error indications, premature EAP Failure packets are unexpected, so that this technique may be more readily employed. [c] Authentication requirement. An EAP peer implementation that has been configured to require authentication MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). [d] Contradictory indications. Where protected and unprotected result indications are both available, protected indications take precedence. For example, where an EAP method provides a protected indication that authentication failure has occurred in either direction, the implementation MUST silently discard subsequent EAP Success packets. Similarly, where an EAP method provides a protected indication that authentication has succeeded in both directions, the EAP implementation MAY silently discard EAP Failure packets. [e] Processing of EAP Success and Failure in the absence of protected indications. Subsequent to the completion of the EAP authentication method (Types 4 and greater), and in the absence of protected result indications, EAP Success and Failure packets MUST be accepted and processed by the EAP implementation." -------------------------------------------------------------------------- Issue 49: Spoofing of EAP Success/Failure Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: December 11, 2002 Reference: Document: RFC2284bis-08 Comment type: T Priority: S Section: 2.1 Rationale/Explanation of issue: The text in section 2.1 does not provide protection against spoofing of EAP Failure. From paul@funk.com Mon Jan 20 06:28:31 2003 From: paul@funk.com (Paul Funk) Date: Mon, 20 Jan 2003 01:28:31 -0500 Subject: [eap] Re: Proposed resolution of issue #41 In-Reply-To: References: <4.1.20021215130655.0270ed40@mail.funk.com> Message-ID: <5.2.0.9.0.20030120000744.023d2688@mail.funk.com> --=====================_87688656==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:16 PM 1/18/2003 -0800, Bernard Aboba wrote: > > >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. > >OK. James has suggested that could include a Nak packet with a single Type >value of 0, to indicate no alternative. Would it also be possible for such >a legacy Nak to include more than one Type? A legacy 2284 client would always Nak with a single type. 2284 says Nak MUST have 1 data byte, though it also says that a Nak MAY offer an alternative (implying that not proposing a type is legal). But I'm betting that 2284 implementations always include exactly one type in a Nak; and if they don't have type to propose they just abandon the authentication. A new implementation, according to the 2284bis draft, could include multiple types in a Nak, whether the Nak is single-byte or extended. If the server is 2284 and the client is bis, the client could send multiple types in a single- byte Nak; the server would either (a) ignore all but the first, or (b) reject the message. I think most servers will do (a), which is benign. But this means that if the server can't accommodate the first type in the client's Nak, it may challenge with a type that wasn't in the client's list at all, so the client should be prepared for this and not deem it an error. > > 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. > >OK on the 8-octet format for Type-Data. However, the structure of the Nak >packet itself is defined in RFC 2284: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Code | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Type-Data ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >Code = 2 (Response) >Type = 3 (Nak) > >Are you proposing to change the format of the Nak packet? No. The legacy Nak format is unchanged. However, there is an additional Nak format, where the Nak itself and all desired types are in extended (8-octet) format. Only bis servers will understand the new format. A client should only send the new format to a server that it knows is a bis server. The way it would know is if the server used an extended type in a request. If a client wants an extended type but doesn't know if the server is bis, it would first do a single-byte Nak asking for 254. If the server then issues a request with an extended type, it may or may not be the type the client wants. It it's not, the client would then respond with an extended Nak for the exact type it wanted. > > 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. > >Yes, within the new Nak, the 8-octet format would be used within the >Type-Data field: > > 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Is this right? Yes. > > 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. > >Are you saying that the legacy Nak has Type field =3, and Type-Data equal >to one or more Type values? Note that James has suggested reserving the >Type value of 0 to mean "no alternative". Yes. As I mentioned above, a 2284 Nak would not have more than one type values. Using type = 0 is a good idea; legacy servers should handle it correctly. > > This type of Nak provides backward compatibility for peers that > > implement RFC2284 or earlier. > >Yes. > > > >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. > >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. > >OK. That makes sense. > > > 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. > >I think this is where I am losing you. It would probably help to show all >the fields of the EAP packet. For example, an extended Nak proposing >two alternative Types, both within the IETF standard space would look >like this, 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Code (2) | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type (3) | 254 | Vendor-Id (0) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VID (0) | Vendor-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | V-Type | Vendor-Id (0) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > There is a typo in my original example, which may be causing confusion. The > > single octet "4" should be a "254". > >OK. Is the above example now correct? No. The above would look to a server like a single-byte Nak with a bunch of single-byte desired types following it, the first of which is a 254. There's no way to know that these are extended types except by noticing that octets are repeated. The 254 is supposed to be in the first position, where the 3 is. Here's the example shown below, but also showing the EAP header, so this is the full packet. It is a Nak, proposing MD5-Challenge and type 15 from vendor 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code = 2 | Identifier | Length = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | Vendor-Id = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type = 3 (Nak) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | Vendor-Id = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type = 4 (MD5-Challenge) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 254 | Vendor-Id = 311 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type = 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Your two examples are correct, except for the omission of the extended Nak > > type itself. > >Isn't this represented above by the "254" in the first octet of the >Type-Data field? I'm not sure if which bit diagram you are referring to, so I won't hazard an answer. If this is still an open question, email me again with the bit diagram . > > 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 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >OK. This is more clear. > >Question: Why the need for additional "254" octets after the first >one? Is this just to maintain alignment? Otherwise, I think we're >in agreement. Strictly speaking, they're not necessary, since the fact that this is an extended Nak requires that all types are in extended format. So it could be defined either way. I think the alignment issue is more important for neatness in the bit diagrams in the RFC than for ease of coding. Mainly, I think that it will be clearer if extended types always are 8 octets, rather than sometimes 8 octets and sometimes 7. Paul --=====================_87688656==.ALT Content-Type: text/html; charset="us-ascii" At 10:16 PM 1/18/2003 -0800, Bernard Aboba wrote:
> >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.

OK. James has suggested that could include a Nak packet with a single Type
value of 0, to indicate no alternative. Would it also be possible for such
a legacy Nak to include more than one Type?

A legacy 2284 client would always Nak with a single type. 2284 says Nak
MUST have 1 data byte, though it also says that a Nak MAY offer an
alternative (implying that not proposing a type is legal). But I'm betting that
2284 implementations always include exactly one type in a Nak; and if they
don't have type to propose they just abandon the authentication.

A new implementation, according to the 2284bis draft, could include multiple
types in a Nak, whether the Nak is single-byte or extended. If the server is
2284 and the client is bis, the client could send multiple types in a single-
byte Nak; the server would either (a) ignore all but the first, or (b) reject the
message. I think most servers will do (a), which is benign. But this means
that if the server can't accommodate the first type in the client's Nak, it
may challenge with a type that wasn't in the client's list at all, so the client
should be prepared for this and not deem it an error.


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

OK on the 8-octet format for Type-Data. However, the structure of the Nak
packet itself is defined in RFC 2284:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Type-Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Code = 2 (Response)
Type = 3 (Nak)

Are you proposing to change the format of the Nak packet?

No.

The legacy Nak format is unchanged.

However, there is an additional Nak format, where the Nak itself and all
desired types are in extended (8-octet) format. Only bis servers will
understand the new format.

A client should only send the new format to a server that it knows is a bis
server. The way it would know is if the server used an extended type in a
request. If a client wants an extended type but doesn't know if the server is
bis, it would first do a single-byte Nak asking for 254. If the server then issues
a request with an extended type, it may or may not be the type the client
wants. It it's not, the client would then respond with an extended Nak for the
exact type it wanted.



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

Yes, within the new Nak, the 8-octet format would be used within the
Type-Data field:

    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                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Vendor-Type                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Is this right?


Yes.



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

Are you saying that the legacy Nak has Type field =3, and Type-Data equal
to one or more Type values? Note that James has suggested reserving the
Type value of 0 to mean "no alternative".

Yes. As I mentioned above, a 2284 Nak would not have more than one
type values. Using type = 0 is a good idea; legacy servers should handle
it correctly.


> This type of Nak provides backward compatibility for peers that
> implement RFC2284 or earlier.

Yes.

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

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.

OK. That makes sense.

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

I think this is where I am losing you. It would probably help to show all
the fields of the EAP packet. For example, an extended Nak proposing
two alternative Types, both within the IETF standard space would look
like this, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Code (2)    |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type (3)    |    254        |        Vendor-Id (0)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   VID (0)     |               Vendor-Type                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    V-Type     |               Vendor-Id (0)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Vendor-Type                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

OK. Is the above example now correct?

No. The above would look to a server like a single-byte Nak with a bunch of
single-byte desired types following it, the first of which is a 254. There's no way
to know that these are extended types except by noticing that octets are repeated.

The 254 is supposed to be in the first position, where the 3 is.

Here's the example shown below, but also showing the EAP header, so this is the
full packet. It is a Nak, proposing MD5-Challenge and type 15 from vendor 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Code = 2    |  Identifier   |       Length  = 28                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      254      |                 Vendor-Id = 0                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Vendor-Type = 3 (Nak)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      254      |                 Vendor-Id = 0                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Vendor-Type = 4 (MD5-Challenge)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      254      |                 Vendor-Id = 311                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Vendor-Type = 15                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



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

Isn't this represented above by the "254" in the first octet of the
Type-Data field?

I'm not sure if which bit diagram you are referring to, so I won't hazard an answer. If this
is still an open question, email me again with the bit diagram .


> 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                        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


OK. This is more clear.

Question: Why the need for additional "254" octets after the first
one? Is this just to maintain alignment? Otherwise, I think we're
in agreement.

Strictly speaking, they're not necessary, since the fact that this is an
extended Nak requires that all types are in extended format. So it could
be defined either way. I think the alignment issue is more important for
neatness in the bit diagrams in the RFC than for ease of coding. Mainly,
I think that it will be clearer if extended types always are 8 octets, rather
than sometimes 8 octets and sometimes 7.

Paul

--=====================_87688656==.ALT-- From Dan.Forsberg@nokia.com Mon Jan 20 09:36:59 2003 From: Dan.Forsberg@nokia.com (Dan.Forsberg@nokia.com) Date: Mon, 20 Jan 2003 11:36:59 +0200 Subject: [eap] preserving packet order in EAP? Message-ID: Hi, EAP requires that packet order is maintained by the lower layer. My = concern is that EAP can't be carried by UDP or IP alone, because these = protocols do not preserve the packet order? This becomes an issue in the = PANA wg. TCP/SCTP would be another option to carry EAP, but EAP detects = duplicates and does re-transmissions already. Another comment/question: = Isn't EAP request-response style protocol, so what are the = possibilites/consequences for packet order mismatch? - Dan From Dan.Forsberg@nokia.com Mon Jan 20 16:13:45 2003 From: Dan.Forsberg@nokia.com (Dan.Forsberg@nokia.com) Date: Mon, 20 Jan 2003 18:13:45 +0200 Subject: [eap] preserving packet order in EAP? Message-ID: One possible solution for this problem is to require the Authenticatee to remember the ID numbers inside the EAP method (message id's between the initial request and Success/Failure msgs). This would imply that no EAP method should produce more than 256 requests per authentication. Another solution to this problem is to prohibit simultaneous *same type* of authentications. Currently in the -10 spec: "Once a peer has sent a Response of the same Type as a Request, some existing peer implementations might expect the method to run to completion. As a result, these implementations silently discard EAP Requests of a Type different from the method in progress, despite the requirement for a Response in section 2.2.1. For this reason, EAP authenticators that must interoperate with these peers are discouraged from switching methods before the final round of a given method has completed." I couldn't find section 2.2.1? So, the Authenticatee could drop the duplicate request (1) because it would restart the authentication method and thus the "first" method would not "run to completion". Anyway, I think this should be fixed in the EAP protocol simply because it is standardized here in the IETF. A new issue perhaps? EAP already provides retransmission and "duplicate" detection. Making the duplicate detection work within this example, would make EAP suitable for carriers such as UDP, ICMP, and IP. This would increase the possibilities for EAP in the Internet. Authenticator Authenticatee Request ID=1 >--------> (got req 1) -----< Response ID=1 (timeout) / Request ID=1 >--/ /\ (got resp 1) <- | Request ID=2 >--------> (got req 2) | --< Response ID=2 | / (got resp 2) <----- \ ---> (got req 1) (disc bad id) <-------< Response ID=1 > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 20 January, 2003 16:17 > To: Forsberg Dan (NRC/Helsinki) > Cc: pana@research.telcordia.com > Subject: Re: [eap] preserving packet order in EAP? > > > Dan, > > Let me attach James Carlson's email which contains a good example for > why packet order for EAP must be maintained by the lower layer. > > Yoshihiro Ohba > > > On Mon, Jan 20, 2003 at 11:36:59AM +0200, > Dan.Forsberg@nokia.com wrote: > > Hi, > > > > EAP requires that packet order is maintained by the lower > layer. My concern is that EAP can't be carried by UDP or IP > alone, because these protocols do not preserve the packet > order? This becomes an issue in the PANA wg. TCP/SCTP would > be another option to carry EAP, but EAP detects duplicates > and does re-transmissions already. Another comment/question: > Isn't EAP request-response style protocol, so what are the > possibilites/consequences for packet order mismatch? > > > > - Dan > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > From aboba@internaut.com Mon Jan 20 20:46:19 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 20 Jan 2003 12:46:19 -0800 (PST) Subject: [eap] Re: preserving packet order in EAP In-Reply-To: <200301201650.h0KGonk22925@internaut.com> Message-ID: On Monday, January 20, 2003 Dan Forsberg wrote: > EAP requires that packet order is maintained by the lower layer. My > concern is that EAP can't be carried by UDP or IP alone, because these > protocols do not preserve the packet order? Those transports are illegal, because they don't preserve order, correct. > TCP/SCTP would be another option to carry EAP, but EAP detects > duplicates and does re-transmissions already. Yes, those transports would be fine, providing that they provide the appropriate security -- namely per-packet integrity and authentication. > Another comment/question: > Isn't EAP request-response style protocol, so what are the > possibilites/consequences for packet order mismatch? The issue comes up since RFC 2284 doesn't require the Identifier space to be monotonically increasing. That means that if a Request packet with ID 1 were retransmitted, and arrived *after* a Request packet with ID 2, it could be erroneously thought by the peer to represent a new Request, rather than a retransmission. > One possible solution for this problem is to require the Authenticatee to remember > the ID numbers inside the EAP method (message id's between the initial > request and Success/Failure msgs). This would imply that no EAP method > should produce more than 256 requests per authentication. That would be incompatible with existing implementations, would impact re-authentication and would enable new DoS attacks. > Another solution to this problem is to prohibit simultaneous *same type* of > authentications. Again, that is incompatible with existing implementations, which can authenticate multiple users at a time. From alper@docomolabs-usa.com Tue Jan 21 07:14:05 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Mon, 20 Jan 2003 23:14:05 -0800 Subject: [eap] Re: preserving packet order in EAP In-Reply-To: Message-ID: On 1/20/03 12:46 PM, "Bernard Aboba" wrote: > On Monday, January 20, 2003 Dan Forsberg wrote: > >> EAP requires that packet order is maintained by the lower layer. My >> concern is that EAP can't be carried by UDP or IP alone, because these >> protocols do not preserve the packet order? > > Those transports are illegal, because they don't preserve order, correct. If UDP or ICMP is used as transport, couldn't an identifier field in the PANA header be a solution to this problem? > >> TCP/SCTP would be another option to carry EAP, but EAP detects >> duplicates and does re-transmissions already. > > Yes, those transports would be fine, providing that they provide the > appropriate security -- namely per-packet integrity and authentication. > Assuming we are talking about per-(data-)packet integrity and authentication after the initial authentication, how is this related to the EAP transport? Regardless of the EAP transport, that protection should be provided by physical, link-layer or network-layer mechanisms. alper >> Another comment/question: >> Isn't EAP request-response style protocol, so what are the >> possibilites/consequences for packet order mismatch? > > The issue comes up since RFC 2284 doesn't require the Identifier space to > be monotonically increasing. That means that if a Request packet with ID 1 > were retransmitted, and arrived *after* a Request packet with ID 2, it > could be erroneously thought by the peer to represent a new Request, > rather than a retransmission. > >> One possible solution for this problem is to require the Authenticatee to >> remember >> the ID numbers inside the EAP method (message id's between the initial >> request and Success/Failure msgs). This would imply that no EAP method >> should produce more than 256 requests per authentication. > > That would be incompatible with existing implementations, would > impact re-authentication and would enable new DoS attacks. > >> Another solution to this problem is to prohibit simultaneous *same type* of >> authentications. > > Again, that is incompatible with existing implementations, which can > authenticate multiple users at a time. > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Tue Jan 21 06:52:19 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 20 Jan 2003 22:52:19 -0800 (PST) Subject: [eap] Re: preserving packet order in EAP In-Reply-To: Message-ID: > > Those transports are illegal, because they don't preserve order, correct. > > If UDP or ICMP is used as transport, couldn't an identifier field > in the PANA header be a solution to this problem? If you're saying that PANA would define its own transport over UDP that preserved ordering, yes that would work. > > Yes, those transports would be fine, providing that they provide the > > appropriate security -- namely per-packet integrity and authentication. > > > > Assuming we are talking about per-(data-)packet integrity and authentication > after the initial authentication, how is this related to the EAP > transport? Regardless of the EAP transport, that protection should > be provided by physical, link-layer or network-layer mechanisms. It is related because otherwise you have not tied the key that is derived in EAP to subsequent data and you have a vulnerability to hijacking. So you might have used EAP for authentication -- but security has not been achieved. There are also issues relating to protection of the EAP exchange itself. Those can presumably be solved by choice of method -- but if PANA also does not make any recommendations in that department, then that is also a vulnerability. From aboba@internaut.com Tue Jan 21 06:59:56 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 20 Jan 2003 22:59:56 -0800 (PST) Subject: [eap] Re: preserving packet order in EAP In-Reply-To: Message-ID: Overall, it is important to understand that PANA (and IEEE 802.11i for that matter) represent very major extensions to the existing EAP usage model. RFC 2284 was created with the assumption that the underlying physical medium was secure, as was IEEE 802.1X (which was created for use with wired networks only). Where EAP is run over wireless that is not the case. This greatly expands the potential security vulnerabilities. IEEE 802.11i has put in substantial effort to address these issues: addition of a "third leg" of mutual auth and key derivation between the NAS and client; proper key wrapping between the AAA server and NAS; definition of the key hierarchy, both for individual sessions, and for fast handoff; support for pre-authentication; EAP method requirements. To get an idea of what you're up against, I would suggest a careful reading of IEEE 802.11i. From aboba@internaut.com Tue Jan 21 07:12:59 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 20 Jan 2003 23:12:59 -0800 (PST) Subject: [eap] Re: Proposed resolution of issue #41 In-Reply-To: <5.2.0.9.0.20030120000744.023d2688@mail.funk.com> Message-ID: > A legacy 2284 client would always Nak with a single type. 2284 says Nak > MUST have 1 data byte, though it also says that a Nak MAY offer an > alternative (implying that not proposing a type is legal). But I'm betting > that > 2284 implementations always include exactly one type in a Nak; and if they > don't have type to propose they just abandon the authentication. That seems to be the favored interpretation. > A new implementation, according to the 2284bis draft, could include multiple > types in a Nak, whether the Nak is single-byte or extended. If the server is > 2284 and the client is bis, the client could send multiple types in a single- > byte Nak; the server would either (a) ignore all but the first, or (b) > reject the > message. I think most servers will do (a), which is benign. But this means > that if the server can't accommodate the first type in the client's Nak, it > may challenge with a type that wasn't in the client's list at all, so the > client > should be prepared for this and not deem it an error. Yes. But this could also happen when both client and server are 2284 implementations, no? > The legacy Nak format is unchanged. > > However, there is an additional Nak format, where the Nak itself and all > desired types are in extended (8-octet) format. Only bis servers will > understand the new format. OK. > A client should only send the new format to a server that it knows is a bis > server. The way it would know is if the server used an extended type in a > request. Yes. > If a client wants an extended type but doesn't know if the server is > bis, it would first do a single-byte Nak asking for 254. If the server then > issues > a request with an extended type, it may or may not be the type the client > wants. It it's not, the client would then respond with an extended Nak for the > exact type it wanted. Yes, this makes sense. > >Is this right? > > Yes. OK. I think we're getting closer. Can you take a look at the text proposed for resolution of issue 41 (the message after the one you replied to) and send corrections? > >Are you saying that the legacy Nak has Type field =3, and Type-Data equal > >to one or more Type values? Note that James has suggested reserving the > >Type value of 0 to mean "no alternative". > > Yes. As I mentioned above, a 2284 Nak would not have more than one > type values. Using type = 0 is a good idea; legacy servers should handle > it correctly. OK. > Here's the example shown below, but also showing the EAP header, so this is > the > full packet. It is a Nak, proposing MD5-Challenge and type 15 from vendor 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Code = 2 | Identifier | Length = 28 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 254 | Vendor-Id = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-Type = 3 (Nak) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 254 | Vendor-Id = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-Type = 4 (MD5-Challenge) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 254 | Vendor-Id =311 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-Type = 15 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I think I understand this now. You are using Type=254 both for Vendor-Specific *and* for Nak itself. > Strictly speaking, they're not necessary, since the fact that this is an > extended Nak requires that all types are in extended format. So it could > be defined either way. I think the alignment issue is more important for > neatness in the bit diagrams in the RFC than for ease of coding. Mainly, > I think that it will be clearer if extended types always are 8 octets, rather > than sometimes 8 octets and sometimes 7. I think I understand the format of the Type-Data field, but not the use of 254 for the Type itself, instead of 3 for Nak. From aboba@internaut.com Tue Jan 21 19:30:22 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 21 Jan 2003 11:30:22 -0800 (PST) Subject: [eap] Re: Proposed Resolution to Issue 41: Nak of Extended Types In-Reply-To: Message-ID: Based on the recent conversation with Paul, I'd like to modify this proposed resolution to the below section. Hopefully this is closer to the right answer. 5.3. Nak Description 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 one or more authentication Types desired by the Peer. Type zero (0) is used to indicate that the sender has no viable alternatives. Since the Nak Type is only valid in Responses and has very limited functionality, it MUST NOT be used as a general purpose error indication, such as for communication of error messages, or negotiation of parameters specific to a particular EAP method. Code 2 for Response. Identifier The Identifier field is one octet and aids in matching Responses with Requests. The Identifier field of a Nak Response MUST match the Identifier field of the Request packet that it is sent in response to. Length >=6 Type 3 Type-Data Where the Request contains a Type within the original EAP Type space (1-253, 255), or the Request contains an expanded Type as defined in Section 5.7, but the peer does not support expanded Types, then the Type-Data field of the Nak Response MUST contain one or more octets indicating the desired authentication Type(s), one octet per Type, or the value zero (0) to indicate no proposed alternative. When the Nak Response includes as one of the Type(s) the value 254, this indicates an expanded Type of preference indicated by the relative order. If the authenticator can accomodate this preference, it will respond with a an expanded Type Request. If a peer supporting expanded Types receives an expanded Type Request, then the Type-Data field of the Nak Response, if sent, MUST contain one or more authentication Types, all of which MUST be in the format below (8 octets per Type). This includes the encoding of zero (0), to indicate no proposed alternative. See Section 5.7 for details on the Vendor-Id and Vendor-Type fields. If the peer does not support expanded Types, then the Type-Data field of the Nak Response MUST contain one or more authentication Type(s), one octet per Type, or the value zero (0) to indicate no proposed alternative. However, the value 254 MUST NOT be included as one of the preferred authentication Types. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From aboba@internaut.com Tue Jan 21 19:38:53 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 21 Jan 2003 11:38:53 -0800 (PST) Subject: [eap] Moving forward on issues 49 and 52 Message-ID: We've had a good discussion on Issues 49 and 52, and proposed text has been put forward, but there is some uncertainty on how to proceed. To make sure that we really understand the issues, we've asked the EAP WG Security Advisor, Professor Bill Arbaugh of University of Maryland to go over the threads on Issues 49 and 52, look at the security issues relating to the potential solutions and render an opinion. If you'd like to make an argument for Bill to look at, please send mail to the EAP WG mailing list with [Issue 49] or [Issue 52] in the subject, depending on what you'd like to comment on. If there are specific sections of text which are objectionable in the proposed fixes, please reference those and propose alternatives. As usual, the EAP Issues list is maintained at: http://www.drizzle.com/~aboba/EAP/eapissues.html and the latest version of the -10 strawman can be found at: http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-10.txt From aboba@internaut.com Tue Jan 21 21:59:20 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 21 Jan 2003 13:59:20 -0800 (PST) Subject: [eap] RE: The EAP GPRS protocol (fwd) Message-ID: ---------- Forwarded message ---------- Date: Wed, 15 Jan 2003 19:11:06 +0200 From: Salkintzis Apostolis-Y1026C To: "'Mark Grayson (mgrayson)'" Cc: ietf-ppp@merit.edu Subject: RE: The EAP GPRS protocol Mark, Thanks for your response. EAP GPRS is virtually a simple encapsulating scheme tailored for UMTS/GPRS terminals, which, in addition to UTRAN/GPRS interfaces, they support an 802.11 radio interface. Note that these terminals already implement the GMM protocol, hence EAP GPRS assumes that GMM is already there. Note also that, UMTS/GPRS terminals already implement L2 protocols (in particular the RRC in UMTS and the LLC in GPRS), which provide a L2 transport for GMM messages. EAP GPRS does not encapsulate directly the GMM messages but rather it encapsulates the corresponding RRC/LLC messages. This way, we exploit the data link services of RRC/LLC, which include sequence control, re-transmissions, enciphering, integrity checking, etc. In other words, EAP GRPS operates right below RRC (in UTRAN mode) or LLC (in GPRS mode). The goal of EAP GPRS is to allow UMTS terminals to move between UTRAN and WLAN access. Our assumption is that the WLAN is "tightly-coupled" to UMTS core network. In this scenario, EAP GPRS acts as a scheme that allows RRC/LLC packets to pass through WLAN devices that enforce 802.1x access control. One of the benefits of using EAP GPRS is that it is very simple. In theory, EAP GPRS can carry any type of traffic, not only RRC/LLC. I agree that RRC/LLC operation or even GMM operation is coupled to some parameters broadcast on UTRAN/GPRS radio interface. We are seeing this as a separate issue and we deliberately left it outside the scope of EAP GPRS. Best regards, Apostolis --- -----Original Message----- From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com] Sent: Wednesday, January 15, 2003 5:20 PM To: Salkintzis Apostolis-Y1026C; ietf-ppp@merit.edu Subject: RE: The EAP GPRS protocol Apostolis Can you explain the differences between your proposal and http://www.ietf.org/internet-drafts/draft-buckley-pppext-eap-sim-gmm-00. txt. Do you propose to transport more than GMM messages between the peer and EAP server? If so how are Radio Resource messages processed - since these relate specifically to GSM/GPRS/UMTS radio bearers. Keeping my comments to GMM, I would say that the GMM state machine is quite complex for WLAN authentication: according to 24.008, 115 pages of mobility management elementary procedures, 27 pages of GMM messages and 22 pages of GMM information elements. Hence, the limited appeal to those interested in tight coupling, although even for tight coupling, alternative techniques exist, e.g., EAP-SIM. In addition, some of these GMM procedures require interaction with Radio Specific information, e.g., using GSM broadcast information to trigger transitioning between different values of GPRS Update Status, which are not defined for WLAN. Best regards, Mark ___________________________________________________ Mark Grayson Consulting Engineer World Wide Mobile Service Providers Cisco Systems IP Phone: +33 (0)1.58.04.31.24 GSM: +33 (0)6.19.98.40.99 -----Original Message----- From: Salkintzis Apostolis-Y1026C [mailto:salki@motorola.com] Sent: 15 January 2003 15:29 To: ietf-ppp@merit.edu Subject: The EAP GPRS protocol Dear all, The following I-D has recently been submitted and relates to PPPEXT area. I would appreciate your comments. Title : The EAP GPRS Protocol (EAP-GPRS) Author(s) : A. Salkintzis Filename : draft-salki-pppext-eap-gprs-00.txt Pages : 21 Date : 2003-1-6 This document specifies an extension to the Extensible Authentication Protocol (EAP) [2], referred to as EAP-GPRS, which allows GPRS clients to perform signaling procedures with a core GPRS network through devices that enforce EAP-based access control. For example, a GPRS client can use EAP-GPRS to attach to a GPRS network through an access point that enforces IEEE 802.1X [3] access control. In this case, the GPRS attach signaling is performed in the context of the underlying 802.1X procedure and the GPRS messages are encapsulated into EAP-GPRS packets. If the GPRS client is permitted to attach to the GPRS network, then the 802.1X procedure ends successfully and the client is authorized access to the access point. In general, EAP-GPRS allows any type of signaling to take place during the EAP authentication as an embedded signaling procedure. However, in this documents we particularly focus on GPRS specific signaling. A URL for this Internet-Draft is: --- Dr. Apostolis Salkintzis Motorola Tel: +30-210-8172335 Fax: +30-210-6810168 E-mail: salki@motorola.com From jsalowey@cisco.com Wed Jan 22 15:39:12 2003 From: jsalowey@cisco.com (Joe Salowey) Date: Wed, 22 Jan 2003 07:39:12 -0800 Subject: [eap] Two EAP related drafts Message-ID: <4D1E846548771F4AA7FAE28F4B358DB5012EF3D8@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> Two drafts were recently submitted to the IETF that may be of interest to the EAP working group: From aboba@internaut.com Wed Jan 22 14:47:52 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 22 Jan 2003 06:47:52 -0800 (PST) Subject: [eap] RFC 2869bis to IETF Last Call Message-ID: In order to have RFC 2869bis published as an RFC in time for citation by IEEE 802.1aa, it needs to enter IETF last call approximately 4-5 months before publication is required. In order not to delay IEEE 802.1aa, I have asked for the draft, which is available below, to go to IETF last call. Since this is the last opportunity for people to read and comment on it, it's important for those interested in the subject of RADIUS/EAP to do a read through and ensure that it is satisfactory. Comments can be sent to the EAP WG mailing list (eap@frascone.com) and to the authors, using the format described at: http://www.drizzle.com/~aboba/EAP/eapissues.html The draft itself is available at: http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-06.txt From jsalowey@cisco.com Wed Jan 22 16:03:33 2003 From: jsalowey@cisco.com (Joe Salowey) Date: Wed, 22 Jan 2003 08:03:33 -0800 Subject: [eap] Two EAP-Related Drafts (complete message) Message-ID: <4D1E846548771F4AA7FAE28F4B358DB5012EF3D9@e2k-sea-xch1.ecsbu-lab-sea.cisco.com> Two drafts were recently submitted to the IETF that may be of interest to the EAP working group. =20 The first is a proposal for an EAP-TLV to carry authorization informaiton. The second is an proposal for a method for cryptographically protecting EAP-TLV messages. This is directly related to the authorization document, but it may also be useful for tunnel authentication binding. Comments Welcome. Thanks, Joe Title : EAP Authorization Author(s) : M. Grayson, J. Salowey Filename : draft-grayson-eap-authorisation-00.txt Pages : 13 Date : 2003-1-17 =09 This document specifies an Extensible Authentication Protocol (EAP)=20 mechanism for authorization information exchange. EAP TLV is a=20 Container type for EAP messages. This mechanism describes an EAP TLV=20 for exchange of authorization related information which can take=20 place within the EAP framework and allows an authentic user to=20 provide the network with additional information in order to=20 determine which Internet Service is being requested. This mechanism=20 may be chained after any EAP-Authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-grayson-eap-authorisation-00.t xt Title : Protected EAP TLV Author(s) : J. Salowey Filename : draft-salowey-eap-protectedtlv-00.txt Pages : 7 Date : 2003-1-17 =09 EAP type-length-value (TLV) message types provide a mechanism for=20 encapsulating additional information in an EAP conversation. In some=20 cases it is useful to cryptographically protect this information to=20 maintain the integrity and/or privacy of the communication. This=20 document defines a TLV type that uses message authentication to=20 maintain the integrity of the data, encryption to protect the privacy=20 of the data and sequence numbers to protect replays or re-sequencing=20 of the data. Although protected TLVs must be chained after an=20 authentication mechanism that generates key material the protection=20 mechanism is independent of any particular authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-00.tx t From alper@docomolabs-usa.com Wed Jan 22 22:01:02 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Wed, 22 Jan 2003 14:01:02 -0800 Subject: [eap] Re: preserving packet order in EAP In-Reply-To: Message-ID: >>> Those transports are illegal, because they don't preserve order, correct. >> >> If UDP or ICMP is used as transport, couldn't an identifier field >> in the PANA header be a solution to this problem? > > If you're saying that PANA would define its own transport over UDP that > preserved ordering, yes that would work. > Yes, that's one possibility. >>> Yes, those transports would be fine, providing that they provide the >>> appropriate security -- namely per-packet integrity and authentication. >>> >> >> Assuming we are talking about per-(data-)packet integrity and authentication >> after the initial authentication, how is this related to the EAP >> transport? Regardless of the EAP transport, that protection should >> be provided by physical, link-layer or network-layer mechanisms. > > It is related because otherwise you have not tied the key that is derived > in EAP to subsequent data and you have a vulnerability to hijacking. So > you might have used EAP for authentication -- but security has not been > achieved. Definitely agreed. My point was, regardless of whether EAP was carried over UDP, or ICMP, or TCP, I suspect this tying of key to subsequent data would happen the same way. > > There are also issues relating to protection of the EAP exchange itself. > Those can presumably be solved by choice of method -- but if PANA also > does not make any recommendations in that department, then that is also a > vulnerability. Agreed. alper > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > > ------ End of Forwarded Message > > From jari.arkko@piuha.net Wed Jan 22 20:59:17 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 22 Jan 2003 22:59:17 +0200 Subject: [eap] design team minutes, jan 22nd Message-ID: <3E2F0625.20106@piuha.net> EAP State Machine Design Team (ESTEEM) Meeting Minutes January 22nd, 2003 Scribe: Jari Arkko o A lot of progress has been made on the list regarding the open issues. This time we talked about the state machine more than the issues. o John Vollbrecht talked about the status of the state machine work: - We have come far. - The new version (not in the I-D archive, only posted to eap-design) should correspond to the one Paul has done for the IEEE supplicant state machine. A link to the draft will be posted to the main EAP list as well. - John is happy about the status of the peer side. Some issues in the authenticator side remain, however. - Bernard: There are some issues how the authenticator functions. Conclusion: The authenticator means the same thing as in 802.1x. It does do basic EAP things, such as retransmissions. - John has a model on how passthrough works, but not quite ready to present to others yet. There's a passthrough method which in one side it looks like EAP, in the other side it looks like RADIUS. NAS is controlling retransmission and other tasks in both directions. The simple way to think of this is that a NAS mux talks to a method (possibly the passthrough method). Bernard: This is not quite right, mux does not get all the packets. It doesn't have type codes. John: has a wildcard type code. Jari: Are you thinking of allowing one method in NAS, then something else in passthrough. John: Basically yes, but it is really hard to get out of passthrough. Bernard: Thats ok because if you go to passthrough then you are saying that you don't look at packets. John: One problem I still have is that I originally thought Naks would not go to methods, but here I seem to have to send Nak to the passthrough method since AAA needs to know what methods have been Nakked. Bernard: It could be that the NAS gets a Nak, handles it, and goes to passthrough method as a result. Bernard: James has been stressing that we should focus on what goes on in the wire. Bernard: But the Nak might not go on the wire (between the NAS and the AAA), it could be for the NAS only. It could be a Nak of a method the NAS was running. John: At first you select a method -- send identity, send local method, have the AAA send its method. The response comes to what ever initiated it. Bernard: I agree with that. John: What's the problem then? Bernard: If Radius initiates, the Nak would go then Radius. This is fine. But if the method was initiated by the NAS, the Nak would go to the NAS too. Not passed to the Radius. Then I'd suggest to go to radius and let it deal with the peer instead. DECISION: Who ever sent the request gets the response as well, be it the NAS or AAA or whatever. Question: But currently, the NAS sends Id-Req and response goes to the AAA. Bernard: But that can be defined as the response coming to the NAS, and it just forwarding it via EAP-Start to Radius. Bernard: To complicate your life a little further, NASes might be passthroughs for some methods and users but not for others. - Jari: Can an AAA proxy become a passthrough? John: That's an interesting question. One of the questions if exactly where the EAP protocol chain can be broken out and terminated. Bernard: It can be broken anywhere where there are local methods. In EAP TLS, any node can terminate the method, including proxies. John: I've been thinking of Kerberos authentication with all proxies along the way. Bernard: I think we want to forbid this. John: Yes, we are starting to lose the knowledge of who are we talking to. Bernard: Yes, that's the basic problem with sequences and so on. Also emphasizes the need for careful evaluation of the compound binding problems. Bernard: We could consider the question of where to terminate the EAP method as a RFC 2869 last call comment. Comment: Need to consider Nak as a valid response to the first method in the state machine. - We don't want the 802.1x layer to look at inside the EAP packet and decide things based on that. o Keying - We should talk about Jim Burns' proposal for a key exchange method. Do we ever want to send keys in the middle of method, or only at the very end with Access-Accept? Bernard: One problem with these attributes is that there never was a table in the RFC. So its not clear where they are legal or illegal. John: They are legal if no one says they are illegal. I think it wasn't the intent however when these RFCs were written. Its also a security issue whether this is a reasonable thing to do. - Bernard: This is all up to the RADIUS server. Say you send keys i the middle of a challenge. One of problems in RADIUS is that you never know if those keys were accepted. Certainly in DIAMETER we'd like all the keys to be mandatory. John: We need an acknowledgement of accepting the keys. Bernard: The problem is that there's no response to Access-Accept. John: The next Radius Request could be used for this. This is really a much greater issue of when attributes have been turned on and so on. Bernard: Yes it is. A problem is that radius can't tell that critical information couldn't be used. You never know. But DIAMETER does that. John: I'm still not convinced that you can't do this in RADIUS. DIAMETER is better in many respects, but not sure if it can do everything either. There are non-EAP reasons why AAA servers need to know whether e.g. encryption was turned on. For instance, this information may be needed for accounting. It may be according to the server's policy to disconnect if either eap or ip traffic encryption can't be turned on. Jari: Why allow in-method or in-sequence turning of encryption? Bernard: Agree with the in-method part. But in-sequence may be useful. Bernard: I believe there's a case for a link-status AVP. Bernard: It is possible to have keys in Access-Challenge. Currently they would be silently ignored. Jim's fix will extend current treatment to allow turning them on in other situations than at Access-Accept. We have to know the order in which things happen. In 802.1x, EAP Success is sent before keying is turned on. This does not correspond to what the RFCs say. - Bernard: I encourage everyone to read 2869bis and comment. Here's what it says: everything else processed prior to processing keys. John: But what does "processing" mean, does it have to be "turn on"? That's what Jim was working on, trying to figure what the interface ought to be. - Bernard: Part of the problem, to be blunt here, is that there is no keying attributes specification. I though Bill Arbaugh signed on to do it: It turns out the current key wrap is bad. We need a key wrap. Its not a simple problem. In diameter its better than in Radius since ipsec/tls protect better than radius shared secrets. Most people think its ok to send using ipsec/tls if its one hop. But what happens if there are multiple hops? John: Diameter server would not know if its doing ipsec, but it would know about tls. John: I fear Diameter is not going to solve the problem in the short term. And CMS is far away from ready. Bernard: I think that is an accurate statement. Bernard: 802.1x at least separated eap and radius. In 802.11i, it is much more intermingled, there are references to Radius all over the place. John: We need to make sure that Radius and Diameter both will be able to carry keys. o Meetings - Anyone planning to attend 802.11a meeting in Seattle? Bernard: I will participate. John: when is that? February 19th-21st. That would be the ultimate place to work out all the remaining From jari.arkko@piuha.net Wed Jan 22 21:30:57 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 22 Jan 2003 23:30:57 +0200 Subject: [eap] design team minutes, jan 8th Message-ID: <3E2F0D91.1050701@piuha.net> Date: Wednesday, January 8, 2003 and thereafter Time: 8 AM PST Present: Bob Moskowitz, Jari Arkko, Bernard Aboba, Nick Petroni, Paul Congdon, James Carlson, Yoshihiro Ohba, Glen Zorn Agenda o Discussion of EAP issues - See http://www.drizzle.com/~aboba/EAP/eapissues.html - Issue 60: Ordering guarantees James Carlson: The point is that unless we want to make incompatible change, then we are stuck with the assumption of ordering. Bernard: If its a slow link, the old response could still be coming. James: Yes, and it could be much worse if running over UDP over the Internet. Bernard: The question is if EAP takes care of some of these problems by itself. James: Here's the scenario: ID 1 is sent once, a timeout occurs, ID 1 is sent another time. However, receiver gets first of these messages and replies. Authenticator takes the response as the one for the first and sends the next message with ID 2. Now, the second and third messages swap places on the way to the peer. Peer thinks it has seen three messages, when in reality one was a duplicate. Bernard: This is a really good point, if you go back in the sequence space then you will be screw up the sequence space. Bob: Can radius reorder? Bernard: No, it will not, and it will not save the situation either. John: Why do we need ordering? Bernard: There is a requirement for 2869bis though: Authenticator must not send duplicates to the authentication server. No need since ppp side ordering is enough if the nas is killing duplicates? John: I'm still not convinced. Bernard: This works because the authenticator is keeping state and knows where it is. Whereas the peer does not know about the state, and can get confused. Bernard: There's a number of ways we can handle this. The original way is to require the identifiers to be unique. However, this limits the use of EAP to 256 messages. Also, we could limit the way identifiers are generated by the authenticator. However, RFC 2284 has already been implemented and not all implementations might follow such limits. Bernard: This has happened in real life, we've seen it on a GPRS simulator. It has also happened in real-life 802.1x networks. DECISION: We have to put the ordering requirement in the draft. Bernard opens another issue for the rest of this problem, such as duplicate elimination before shipping the EAP messages over RADIUS. Bernard: Does the 802.1x access point handle the duplicate elimitation above? Paul: No. It would be really helpful if we could clearly articulate which role is responsible for which activity: ordering, duplicate elimination vs. link layer, access point, etc. Bernard: We don't need to think about this in DIAMETER, because it has an ordered transport. Jari: DIAMETER is not ordered end-to-end, only hop-by-hop. Bernard: T bit will fix this. Jari: I wouldn't be too sure about that. - Issue 59 Failed authentication and EAP Failure Nick raised this. Bernard thinks the proposed text is OK, but Nick has to make sure this gets to the state machine as well. - Issue 57 & 58 posted by Jesse are OK, and there's agreed text on the web site. - Issue 54: Can you have a NAK with no types? The current text is vague. It does say must have one octet in one place. The suggestion is to use the value of one when you have no alternative. This would initiate an Identity exchange. DECISION: It would be better to use an illegal value of 0. Bernard: Is it OK to have more than one value? RFC 2284 pretends that there can only be one octet. The understanding is that implementations would not blow up, and would only ignore the remaining bytes. James: There may be implementations that do a silent discard, but I expect a reasonable processing of even bad NAKs from good implementations. - Issue 51: How to allow for turning around the EAP authentication roles. Bernard: Does the 802.1x allow EAP runs in both directions. Paul: Yes, but these are independent. Bernard: We're keeping the peer to peer language in the draft because it is essential for some environments where EAP is used. - Issue 50: Media requirements. Bernard: We can live with duplication, (even if not ordering). John: I agree. Bernard: The media must have checksums or there may become problems for some methods. John: I'd prefer to say its better to have checksums. Bernard: I think that's what our intention is. But we really do need the checksums or otherwise there will be problems. John: I'm not sure this belongs to the EAP protocol description. Bernard: The IESG wanted us to define the transport requirements for later evaluation of new protocols that intend to use EAP. So we need to do it. - Issue 23: Contents of the identity request payload. Glen: I'd reject this. Bob: I agree. - Issue 41: Paul Funk suggests a NAKking of extended types. We'll handle this on the list. - Issue 52: James Carlson suggests that identities be handled at any time. Bernard: The question is if you can switch method at any time. The background is that based on an analysis of the existing state machine there are potential attacks when the state machine provides too much freedom. What's the benefit of allowing identities? James: If the method gets confused, it can use this to get out of the method. Bernard: Why not require a method-specific message for this? James: Then we are setting requirements for all methods. John: Most implementations can accept some requirements on their methods. Jari: Are you trying to use Identity as an Abort? James: The original RFC 2284 gives all control to the authenticator. Changing this would be a break from 2284. Glen: Avoidance of DoS is perhaps one reason. James: I don't believe DoS avoidance can be done this way. James: Its an implementation issue on the client side what to do. If I get into trouble, I can still disconnect. James: The problem is that the protocol as originally defined does not include the restrictions you are suggesting. John: They do not change anything and they do not hurt, but are useful. Bernard: Why don't we take this one to the list, we don't have an agreement on this. o Discussion of EAP state machine document (John Vollbrecht and Nick Petroni's Powerpoint slide set containing the new state machine) - John: I think we a model with three layers (methods, eap mux, link layer) is useful, even if James might not fully agree. Someone: Again, it would be clear if the roles of the different layers could be clearly articulated. - Paul: 802.1aa is coming to a ballot, and is in some sense fixed. But it doesn't mean that if a serious problem is found we wouldn't change it. - Bernard: The 3GPP is giving up a lot requirements to IETF on EAP. A meeting is coming up between IETF and 3GPP on 26-27th of January in San Francisco. The EAP WG probably needs to keep its deadlines for all work items, including the keying draft which is not in great shape. - Bernard: Issue 62 shows that the protected success/failure indication text is not very good. It would be helpful if people could take a look at the text and suggest improvements. From alper@docomolabs-usa.com Wed Jan 22 22:33:34 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Wed, 22 Jan 2003 14:33:34 -0800 Subject: [eap] Re: preserving packet order in EAP In-Reply-To: Message-ID: > ------ Forwarded Message > From: Bernard Aboba > Date: Mon, 20 Jan 2003 22:59:56 -0800 (PST) > To: Alper Yegin > Cc: eap@frascone.com, , > Subject: Re: [eap] Re: preserving packet order in EAP > > Overall, it is important to understand that PANA (and IEEE 802.11i for > that matter) represent very major extensions to the existing EAP usage > model. RFC 2284 was created with the assumption that the underlying > physical medium was secure, as was IEEE 802.1X (which was created for use > with wired networks only). Where EAP is run over wireless that is not the > case. This greatly expands the potential security vulnerabilities. > > IEEE 802.11i has put in substantial effort to address these issues: > addition of a "third leg" of mutual auth and key derivation > between the NAS and client; proper key wrapping between the AAA server and > NAS; definition of the key hierarchy, both for individual sessions, and > for fast handoff; support for pre-authentication; EAP method requirements. > > To get an idea of what you're up against, I would suggest a careful > reading of IEEE 802.11i. Obviously this is not a task that should be underestimated. But there are few things that needs to be noted here. The case 802.11i handles is the hardest case that PANA can be used for. That is: using PANA in the absence of any lower layer security. Before that case there are two other simpler ones. Namely, using PANA over physically secure links (e.g., DSL), and over already secured link-layers (e.g., 3GPP/3GPP2). One possible approach is to identify the common element among all these scenarios and develop a modular solution set. Developing an EAP carrier above IP seems to be the common denominator among these three. This piece by itself should be sufficient to handle two of the cases, but not the hardest one. The solution to first two cases can be developed first. For the last case, there needs to be additional pieces in place (how to bind outcome of EAP, keys, to subsequent data by using IPsec or L2 ciphers). But that should not hold solving other cases back. As long as we keep an eye on the last case as we develop the basic building block, we shall be fine. alper From aboba@internaut.com Wed Jan 22 22:01:20 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 22 Jan 2003 14:01:20 -0800 (PST) Subject: [eap] Re: preserving packet order in EAP In-Reply-To: Message-ID: > Obviously this is not a task that should be underestimated. > > But there are few things that needs to be noted here. > > The case 802.11i handles is the hardest case that PANA can be used for. > That is: using PANA in the absence of any lower layer security. Before that > case there are two other simpler ones. Namely, using PANA over physically > secure links (e.g., DSL), and over already secured link-layers (e.g., > 3GPP/3GPP2). Yes, cases in which the link is physically secure are *much* simpler. > One possible approach is to identify the common element among > all these scenarios and develop a modular solution set. Developing an EAP > carrier above IP seems to be the common denominator among these three. This > piece by itself should be sufficient to handle two of the cases, but not the > hardest one. Yes. > The solution to first two cases can be developed first. For the last case, > there needs to be additional pieces in place (how to bind outcome of EAP, > keys, to subsequent data by using IPsec or L2 ciphers). But that should not > hold solving other cases back. As long as we keep an eye on the last case as > we develop the basic building block, we shall be fine. Yes. What I am suggesting is that there may be a need for an IP-layer equivalent to the IEEE 802.11i 4-way handshake, to secure the "third leg". From james.d.carlson@east.sun.com Thu Jan 23 13:09:26 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 23 Jan 2003 08:09:26 -0500 Subject: [eap] preserving packet order in EAP? In-Reply-To: Dan.Forsberg@nokia.com's message of 20 January 2003 18:13:45 References: Message-ID: <15919.59782.784045.436440@gargle.gargle.HOWL> Dan.Forsberg@nokia.com writes: > One possible solution for this problem is to require the > Authenticatee to remember the ID numbers inside the EAP method > (message id's between the initial request and Success/Failure > msgs). This would imply that no EAP method should produce more than > 256 requests per authentication. That doesn't work because of rechallenge. (Well, unless you're willing to drop the link when you run out of ID space for rechallenges ...) > Anyway, I think this should be fixed in the EAP protocol simply > because it is standardized here in the IETF. A new issue perhaps? > EAP already provides retransmission and "duplicate" > detection. Making the duplicate detection work within this example, > would make EAP suitable for carriers such as UDP, ICMP, and IP. This > would increase the possibilities for EAP in the Internet. EAP has no problem with retransmission or duplicates (or other bad packets, for that matter). It does have a problem with reordering, and that can't actually be fixed without making the "new" version incompatible with the old. If you're going to make it incompatible, I'd suggest starting with a blank slate. EAP just wasn't designed to be used as you suggest. It needs an order-preserving peer-to-peer link. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From Dan.Forsberg@nokia.com Thu Jan 23 13:26:28 2003 From: Dan.Forsberg@nokia.com (Dan.Forsberg@nokia.com) Date: Thu, 23 Jan 2003 15:26:28 +0200 Subject: [eap] preserving packet order in EAP? Message-ID: Thank you for your comments. Just a quick question. What if PANA would = specify a "EAPv2" that wasn't backwards compatible with EAP but better = suitable for UDP/ICMP or TCP/SCTP? This new version could carry EAP = methods specified in the current EAP wg. For my understanding this = wasn't the intention of PANA wg, but it would make things simpler/easier = for PANA(?). Just an idea. - Dan > -----Original Message----- > From: ext James Carlson [mailto:james.d.carlson@east.sun.com] > Sent: 23 January, 2003 15:09 > To: Forsberg Dan (NRC/Helsinki) > Cc: yohba@tari.toshiba.com; pana@research.telcordia.com; > eap@frascone.com > Subject: RE: [eap] preserving packet order in EAP? >=20 >=20 > Dan.Forsberg@nokia.com writes: > > One possible solution for this problem is to require the > > Authenticatee to remember the ID numbers inside the EAP method > > (message id's between the initial request and Success/Failure > > msgs). This would imply that no EAP method should produce more than > > 256 requests per authentication. >=20 > That doesn't work because of rechallenge. (Well, unless you're > willing to drop the link when you run out of ID space for rechallenges > ...) >=20 > > Anyway, I think this should be fixed in the EAP protocol simply > > because it is standardized here in the IETF. A new issue perhaps? > > EAP already provides retransmission and "duplicate" > > detection. Making the duplicate detection work within this example, > > would make EAP suitable for carriers such as UDP, ICMP, and IP. This > > would increase the possibilities for EAP in the Internet. >=20 > EAP has no problem with retransmission or duplicates (or other bad > packets, for that matter). It does have a problem with reordering, > and that can't actually be fixed without making the "new" version > incompatible with the old. If you're going to make it incompatible, > I'd suggest starting with a blank slate. >=20 > EAP just wasn't designed to be used as you suggest. It needs an > order-preserving peer-to-peer link. >=20 > --=20 > James Carlson, Solaris Networking =20 > > Sun Microsystems / 1 Network Drive 71.234W Vox +1=20 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1=20 > 781 442 1677 >=20 From aboba@internaut.com Thu Jan 23 12:23:22 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 23 Jan 2003 04:23:22 -0800 (PST) Subject: [eap] Issue 70: Which PRF Message-ID: Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: January 23, 2003 Document: draft-puthenkulam-eap-binding-01.txt Comment type: T Priority: S Section: 4.1 Rationale/Explanation of issue: I am not clear whether a requirement for a solution is that it work with every tunnel encapsulation of EAP. Currently the draft does say that this is a requirement. I would like to see the draft discuss the feasibility of a general solution within the Solution Requirements section. There are some sticky issues that would arise in attempting to achieve a general solution. One is that the PRFs vary between encapsulations. A TLS encapsulation (EAP TTLS, PEAP, POTLS) will use the TLS PRF; an ISAKMP encapsulation (PIC, IKE) will use the IKE PRF, etc. That means that any means of calculating a compound MAC or compound key that depends on a PRF cannot be completely general, because the question will arise: which PRF? The question is whether it can be made "general enough". One way to do this would be to choose the IKE PRF as the generic one. However, as I understand the architectural model for a "solution", it involves having the EAP method export its MSK, and having this "mixed" (probably via a PRF) with the keying material derived by the tunnel encapsulation. Within this model, tunnel encapsulation is effectively "receiving" an exported EAP MSK, and mixing this internally with its own tunnel key, so that there is no requirement that the tunnel key (e.g. TLS master secret) be exported, which in many cases is not possible or desirable. Choosing the IKE PRF as the universal compound MAC/compound binding PRF would imply that this PRF would have to be universally available to any tunnel encapsulation. I am not clear whether this is a realistic assumption or not. If this assumption cannot be made, or if there are other significant encapsulations with their own PRFs, then a generic EAP solution to the problem is not possible -- although a framework for a solution could be put together that could be customized for each usage. Requested change: Discuss the issue of "generic" vs. "encapsulation specific" solutions in the document, as well as the impact of PRF choice. Also talk about the architectural assumptions regarding key export and import. From james.d.carlson@east.sun.com Thu Jan 23 13:50:44 2003 From: james.d.carlson@east.sun.com (James Carlson) Date: Thu, 23 Jan 2003 08:50:44 -0500 Subject: [eap] preserving packet order in EAP? In-Reply-To: Dan.Forsberg@nokia.com's message of 23 January 2003 15:26:28 References: Message-ID: <15919.62260.336710.649460@gargle.gargle.HOWL> Dan.Forsberg@nokia.com writes: > Thank you for your comments. Just a quick question. What if PANA > would specify a "EAPv2" that wasn't backwards compatible with EAP > but better suitable for UDP/ICMP or TCP/SCTP? This new version could > carry EAP methods specified in the current EAP wg. For my > understanding this wasn't the intention of PANA wg, but it would > make things simpler/easier for PANA(?). Just an idea. That's basically what I was suggesting -- if you're going to make it incompatible, then it's not EAP anymore and isn't suitable for the EAP RFC update, but it might work for some particular domain. It seems to me that there are other issues that need to be solved, and might as well be solved while the patient is on the table. For instance, EAP assumes a peer-to-peer link. PANA and 802.11 [1] have a common problem -- the use of multiaccess media. (Note that both PPP and 802.1X are just point-to-point.) It's not the wireless aspect that's really a special problem; it's the multiaccess nature that causes all the additional security headache. Why not define something that's specific to use on multiaccess networks and that can handle bootstrapping the security association required? That new protocol (MEAP?) can certainly carry EAP-formatted messages if it wants -- after all, AAA protocols aren't EAP, but do carry EAP- formatted messages, so it's not a new concept -- but it needn't be compatible with EAP in any other way, so it doesn't need the same retransmission mechanism. I think that'd be a happier result than contorting EAP to fit into a non-EAP-shaped hole. [1] Minor digression: I leave DSL out of that list quite intentionally. DSL is most certainly a point-to-point technology, and it's made to appear to be multiaccess only by error. If you could yank out the Ethernet-over-ATM baggage and run plain PPP over HDLC on the raw bit pipe between CPE and CO, then all of the current problems -- including PPPoE and PANA -- disappear (and overhead is reduced as well). Bridged Ethernet with DHCP or routed point-to-point link: pick *one*. (It also doesn't actually require the authentication in the plain point-to-point case, since you know where the wires go physically, but it doesn't hurt.) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From jrv@umich.edu Thu Jan 23 13:51:24 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 23 Jan 2003 08:51:24 -0500 Subject: [eap] preserving packet order in EAP? In-Reply-To: References: Message-ID: <8425210.1043311880@[10.0.1.2]> I think it is an interesting idea to consider a way to use EAP Methods independently of EAP itself. Seems to me it could be an interesting approach for PANA to consider. --On Thursday, January 23, 2003 3:26 PM +0200 Dan.Forsberg@nokia.com wrote: > Thank you for your comments. Just a quick question. What if PANA would > specify a "EAPv2" that wasn't backwards compatible with EAP but better > suitable for UDP/ICMP or TCP/SCTP? This new version could carry EAP > methods specified in the current EAP wg. For my understanding this wasn't > the intention of PANA wg, but it would make things simpler/easier for > PANA(?). Just an idea. > > - Dan > > > > -----Original Message----- > > From: ext James Carlson [mailto:james.d.carlson@east.sun.com] > > Sent: 23 January, 2003 15:09 > > To: Forsberg Dan (NRC/Helsinki) > > Cc: yohba@tari.toshiba.com; pana@research.telcordia.com; > > eap@frascone.com > > Subject: RE: [eap] preserving packet order in EAP? > > > > > > Dan.Forsberg@nokia.com writes: > > > One possible solution for this problem is to require the > > > Authenticatee to remember the ID numbers inside the EAP method > > > (message id's between the initial request and Success/Failure > > > msgs). This would imply that no EAP method should produce more than > > > 256 requests per authentication. > > > > That doesn't work because of rechallenge. (Well, unless you're > > willing to drop the link when you run out of ID space for rechallenges > > ...) > > > > > Anyway, I think this should be fixed in the EAP protocol simply > > > because it is standardized here in the IETF. A new issue perhaps? > > > EAP already provides retransmission and "duplicate" > > > detection. Making the duplicate detection work within this example, > > > would make EAP suitable for carriers such as UDP, ICMP, and IP. This > > > would increase the possibilities for EAP in the Internet. > > > > EAP has no problem with retransmission or duplicates (or other bad > > packets, for that matter). It does have a problem with reordering, > > and that can't actually be fixed without making the "new" version > > incompatible with the old. If you're going to make it incompatible, > > I'd suggest starting with a blank slate. > > > > EAP just wasn't designed to be used as you suggest. It needs an > > order-preserving peer-to-peer link. > > > > -- > > James Carlson, Solaris Networking > > > > Sun Microsystems / 1 Network Drive 71.234W Vox +1 > > 781 442 2084 > > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 > > 781 442 1677 > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From yohba@tari.toshiba.com Thu Jan 23 14:25:59 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Thu, 23 Jan 2003 09:25:59 -0500 Subject: [eap] preserving packet order in EAP? In-Reply-To: <15919.62260.336710.649460@gargle.gargle.HOWL> References: <15919.62260.336710.649460@gargle.gargle.HOWL> Message-ID: <20030123142559.GC704@catfish> I agree with James, and the following is just a clarification. PIC and PoTLS are aiming to serve for carrying EAP-formatted messges over multiaccess (and any other type of) link, by logically establishing a secure, order-preserved, logical point-to-point communication channel before starting EAP conversation, based on anonymous key exchange. This is a different approach from which 802.11i is taking. Yoshihiro Ohba On Thu, Jan 23, 2003 at 08:50:44AM -0500, James Carlson wrote: > Dan.Forsberg@nokia.com writes: > > Thank you for your comments. Just a quick question. What if PANA > > would specify a "EAPv2" that wasn't backwards compatible with EAP > > but better suitable for UDP/ICMP or TCP/SCTP? This new version could > > carry EAP methods specified in the current EAP wg. For my > > understanding this wasn't the intention of PANA wg, but it would > > make things simpler/easier for PANA(?). Just an idea. > > That's basically what I was suggesting -- if you're going to make it > incompatible, then it's not EAP anymore and isn't suitable for the EAP > RFC update, but it might work for some particular domain. > > It seems to me that there are other issues that need to be solved, and > might as well be solved while the patient is on the table. For > instance, EAP assumes a peer-to-peer link. PANA and 802.11 [1] have a > common problem -- the use of multiaccess media. (Note that both PPP > and 802.1X are just point-to-point.) It's not the wireless aspect > that's really a special problem; it's the multiaccess nature that > causes all the additional security headache. Why not define something > that's specific to use on multiaccess networks and that can handle > bootstrapping the security association required? > > That new protocol (MEAP?) can certainly carry EAP-formatted messages > if it wants -- after all, AAA protocols aren't EAP, but do carry EAP- > formatted messages, so it's not a new concept -- but it needn't be > compatible with EAP in any other way, so it doesn't need the same > retransmission mechanism. > > I think that'd be a happier result than contorting EAP to fit into a > non-EAP-shaped hole. > > [1] Minor digression: I leave DSL out of that list quite > intentionally. DSL is most certainly a point-to-point technology, > and it's made to appear to be multiaccess only by error. If you > could yank out the Ethernet-over-ATM baggage and run plain PPP > over HDLC on the raw bit pipe between CPE and CO, then all of the > current problems -- including PPPoE and PANA -- disappear (and > overhead is reduced as well). Bridged Ethernet with DHCP or > routed point-to-point link: pick *one*. > > (It also doesn't actually require the authentication in the plain > point-to-point case, since you know where the wires go physically, > but it doesn't hurt.) > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From alper@docomolabs-usa.com Thu Jan 23 19:32:59 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 23 Jan 2003 11:32:59 -0800 Subject: [eap] preserving packet order in EAP? In-Reply-To: Message-ID: On 1/23/03 5:26 AM, "Dan.Forsberg@nokia.com" wrote: > Thank you for your comments. Just a quick question. What if PANA would specify > a "EAPv2" that wasn't backwards compatible with EAP but better suitable for > UDP/ICMP or TCP/SCTP? This new version could carry EAP methods specified in > the current EAP wg. For my understanding this wasn't the intention of PANA wg, > but it would make things simpler/easier for PANA(?). Just an idea. First we really need to understand what problems arise from carrying EAP above IP. Re-ordering was brought up, but that can be handled by including an identifier field in a PANA header. So I don't see this as a requirement for a new version of EAP. Is there anything else? Let's think... Also let's note that if modifications to EAP are needed, PANA is not the right WG to take over this. We need to bring it up to the EAP WG. alper > > - Dan > > >> -----Original Message----- >> From: ext James Carlson [mailto:james.d.carlson@east.sun.com] >> Sent: 23 January, 2003 15:09 >> To: Forsberg Dan (NRC/Helsinki) >> Cc: yohba@tari.toshiba.com; pana@research.telcordia.com; >> eap@frascone.com >> Subject: RE: [eap] preserving packet order in EAP? >> >> >> Dan.Forsberg@nokia.com writes: >>> One possible solution for this problem is to require the >>> Authenticatee to remember the ID numbers inside the EAP method >>> (message id's between the initial request and Success/Failure >>> msgs). This would imply that no EAP method should produce more than >>> 256 requests per authentication. >> >> That doesn't work because of rechallenge. (Well, unless you're >> willing to drop the link when you run out of ID space for rechallenges >> ...) >> >>> Anyway, I think this should be fixed in the EAP protocol simply >>> because it is standardized here in the IETF. A new issue perhaps? >>> EAP already provides retransmission and "duplicate" >>> detection. Making the duplicate detection work within this example, >>> would make EAP suitable for carriers such as UDP, ICMP, and IP. This >>> would increase the possibilities for EAP in the Internet. >> >> EAP has no problem with retransmission or duplicates (or other bad >> packets, for that matter). It does have a problem with reordering, >> and that can't actually be fixed without making the "new" version >> incompatible with the old. If you're going to make it incompatible, >> I'd suggest starting with a blank slate. >> >> EAP just wasn't designed to be used as you suggest. It needs an >> order-preserving peer-to-peer link. >> >> -- >> James Carlson, Solaris Networking >> >> Sun Microsystems / 1 Network Drive 71.234W Vox +1 >> 781 442 2084 >> MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 >> 781 442 1677 >> > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Fri Jan 24 14:22:02 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 24 Jan 2003 06:22:02 -0800 (PST) Subject: [eap] Re: security requirements In-Reply-To: <200301231650.h0NGoTk01625@internaut.com> Message-ID: > That's basically what I was suggesting -- if you're going to make it > incompatible, then it's not EAP anymore and isn't suitable for the EAP > RFC update, but it might work for some particular domain. Since there are a lot of EAP clients and EAP-capable RADIUS servers already deployed, backward compatibility is a practical necessity, not just a nicety. Although it is worth noting that IEEE 802.1X does require monotonically increasing Identifiers, and so as a result, most EAP-capable RADIUS servers accomodate that requirement, regardless of what the lower layer EAP transport is. > It seems to me that there are other issues that need to be solved, and > might as well be solved while the patient is on the table. For > instance, EAP assumes a peer-to-peer link. PANA and 802.11 [1] have a > common problem -- the use of multiaccess media. (Note that both PPP > and 802.1X are just point-to-point.) It's not the wireless aspect > that's really a special problem; it's the multiaccess nature that > causes all the additional security headache. The security issue comes in ensuring that actions resulting from successful EAP authentication (such as opening a "controlled port") only result in access for the authenticated peer. In IEEE 802.1X it is assumed that there is only one peer per port, or that if there are more, that the switch can detect this and shut down the port or send appropriate alarms. Since the link is assumed to be point-to-point and physically secure, EAP methods with lesser security (such as EAP MD5) can be used, and there is no need to key a link layer ciphersuite, since the presence of EAP authentication packets and data on the same physically secure link is presumed to be enough to "bind" the data to the initial authentication. In IEEE 802.11, the ports are virtual -- formed as the result of an association. So there can also only be one peer per "virtual port", but it is no longer reasonable to assume physical security. As a result, the "binding" of the data to the identity of the peer occurs via a lower layer ciphersuite -- one providing per-packet integrity protection, authentication and replay protection. The key used in that ciphersuite can either be static (PSK mode in IEEE 802.11i) or it can be dynamically derived via the EAP method. I'd also note that EAP can also be used in IEEE 802.11i for what is called "pre-authentication" -- authentication that occurs prior to association (pre-auth is also supported in IEEE 802.11-1997). In this case, there is no valid port until *after* EAP authentication completes, so this is completely a multiaccess scenario. Among other things, this imposes considerably greater requirements on the EAP method -- such as mutual authentication, key derivation, dictionary attack resistance, etc. > Why not define something > that's specific to use on multiaccess networks and that can handle > bootstrapping the security association required? I'm curious as to your views on how an ideal protocol would differ from EAP. There are some obvious things that would be fixable -- such as handling of fragmentation in the EAP layer, larger Identifier space, and addition of a field for a CRC/checksum. I'm not sure that retransmission would make the list. In other words, the biggest issues tend to be the kinds of things that are addressed by UDP and IP. The problem of bringing up a security association over a medium which cannot be assumed to be physically secure (e.g. the Internet) is one that has been addressed by protocols such as IKE (running over UDP). So it's not clear to me why an ideal protocol would have to do more than provide basic datagram delivery services such as is provided by UDP and IP. After all, UDP and IP don't need to do anything special to handle "multiaccess". From aboba@internaut.com Fri Jan 24 19:36:49 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 24 Jan 2003 11:36:49 -0800 (PST) Subject: [eap] Re: eap digest, Vol 1 #184 - 2 msgs In-Reply-To: <200301241650.h0OGoPk16814@internaut.com> Message-ID: > First we really need to understand what problems arise from carrying EAP > above IP. Re-ordering was brought up, but that can be handled by > including an identifier field in a PANA header. So I don't > see this as a requirement for a new version of EAP. Is there anything else? > Let's think... The most obvious problems arise because EAP is only a mediocre datagram transport (e.g. no checksum, no fragmentation support, small identifier field, etc.). These things have little to do with whether EAP is used in wireless or wired networks. If the EAP header had looked more like the UDP header in the first place, these problems would not have arisen. So it is not unreasonable to think that a UDP transport could fix most of them, if done well. From Pasi.Eronen@nokia.com Mon Jan 27 09:23:13 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Mon, 27 Jan 2003 11:23:13 +0200 Subject: [eap] EAPv2? Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA08@esebe023.ntc.nokia.com> On 20 Jan 2003, Bernard Aboba wrote: > Overall, it is important to understand that PANA (and IEEE 802.11i for > that matter) represent very major extensions to the existing EAP usage > model. RFC 2284 was created with the assumption that the underlying > physical medium was secure, as was IEEE 802.1X (which was created for = use > with wired networks only). Where EAP is run over wireless that is not = the > case. This greatly expands the potential security vulnerabilities. > > IEEE 802.11i has put in substantial effort to address these issues: > addition of a "third leg" of mutual auth and key derivation > between the NAS and client; proper key wrapping between the AAA server = and > NAS; definition of the key hierarchy, both for individual sessions, = and > for fast handoff; support for pre-authentication; EAP method = requirements. > > To get an idea of what you're up against, I would suggest a careful > reading of IEEE 802.11i. Given that many people seem to be interested in using EAP in environments where the underlying medium is not secure, and getting it right seems to be very difficult, would there be any point or interest in developing "EAPv2"? Some ideas what properties this "EAPv2" could have: - Designed to be used in environments where the underlying=20 medium is not secure. - Designed and specified so that it is easy to "embed" EAPv2 in=20 other protocols (EAPv1 was designed to be extensible, but it=20 was not intended as a "building block" for other protocols). - Maybe better support for mutual authentication and method=20 negotiation related to it. - EAPv2 records could be transported as an EAPv1 method, so it could be used in PPP/802.1X environments without changing NAS boxes. - Clear specification of behavior (state machines, etc.), so that EAPv2 would be simpler and easier to implement than EAPv1. Clearly, the main target of this work would not be PPP, or even 802.1X/11i, but new protocols which would like to reuse an existing "building block" (PANA, PIC, others?).=20 What do you think, is there demand for this kind of work? Are people interested in thinking more about this? If so, how should the thing get started? (Perhaps some of the more difficult issues in 2284bis could be postponed to this "EAPv2", so we can get 2284bis accepted sooner? Or maybe this isn't a good idea...) Best regards, Pasi From aboba@internaut.com Mon Jan 27 13:14:32 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 27 Jan 2003 05:14:32 -0800 (PST) Subject: [eap] Issue 71: Key framework review Message-ID: Issue 71: Key framework review Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: January 26, 2003 Document: draft-aboba-pppext-key-problem-05.txt Comment type: T Priority: S Section: various Rationale/Explanation of issue: Comments marked with "JARI:" JARI: Overall comments: I think this looks pretty good at the moment. There are many places in the document where we have to be more precise than what the text currently says, however. The main worry that I have with this document is that I don't understand how big changes are required to provide what Jesse Walker (AAA issue 294) wanted to have for three-party participation. And I don't understand the role of NAS/client layer 2 and 3 addresses and what is required there. Finally, the document would beclearer if EAP ciphersuite and link ciphersuite issues were kept completely separate from each other. These limitations can be overcome via negotiation of EAP methods such as EAP TLS [RFC2716] that support mutual authentication, as well as key derivation. JARI: Right. 1.2. Terminology This document frequently uses the following terms: Client-Server Token (CS-Token) The package within which the MSK is transported between the EAP Server and the EAP Client. The package MUST be integrity protected, authenticated and encrypted, so as to protect the MSK JARI: Not replay protected? from compromise. In addition to the MSK, the CS-Token MAY include one or more attributes providing information on MSK usage. Attributes may include the NAS layer 2 and layer 3 addresses, MSK JARI: How would layer 3 addresses be available at this time? In PPP, NCPs run after authentication, right? And how would layer 2 addresses be possible to distribute in a manner independent from the actual link layer specifics? Cryptographic binding The demonstration of the EAP Client to the EAP Server that a single entity has acted as the EAP Client for all methods executed within a sequence or tunnel. Binding MAY also imply that the EAP Server demonstrates to the Client that a single entity has acted as the EAP Server for all methods executed within a sequence or tunnel. If executed correctly, binding serves to mitigate man-in-the-middle vulnerabilities. JARI: Add a reference to Valtteri Niemi et al paper or some other suitable source? Master Session Key (MSK) Keying material provided to the EAP Client and NAS by the AAA Server, acting as a Key Distribution Center (KDC). The MSK is used in derivation of Transient Session Keys for the ciphersuite negotiated between the EAP Client and NAS. So that the MSK is usable with any ciphersuite, it is longer than necessary, and is truncated to fit. JARI: This sounds a bit ad hoc. Why not require that (a) the MSK is long enough to have sufficient entropy and (b) provide an algorithm for deriving actual TSKs? Note that an Authentication Server may simultaneously provide the EAP Client with MSKs suitable for use with multiple APs, so as to enable fast handoff. Similarly the AAA Server may send MSKs to multiple APs simultaneously. Note that where the AP supports transport of multiple MSK sets to the EAP Client and NASes, the MSKs MUST be kept cryptographically separate from each other. JARI: Indentation of the above paragraph is wrong. Within [IEEE80211i], the Enc-RECV-Key is also known as the Pairwise Master Key (PMK). IEEE 802.11 ciphersuites such as TKIP, WRAP and CCMP derive their Transient Session Keys (TSKs) solely from the PMK, whereas the WEP ciphersuite, when used with IEEE 802.1X-2002, derives its TSKs from both the Enc-RECV-Key and the Enc-SEND-Key. JARI: Repeated text, see previous paragraph. The MSK contained within the CS-Token and AN-Tokens is suitable for use with any negotiated ciphersuite, and therefore an EAP method MUST NOT directly use the MSK JARI: s/, and therefore an/. An/ 3.1. Two-party exchange Figure 3 illustrates the two-party exchange, where the Client is authenticated locally by the NAS using a locally implemented authentication method. In this case, the EAP Master Key (EMK) is derived on the Client and the NAS, which acts as the EAP Server during the EAP authentication exchange, and the Client-Server token is transported by the NAS to the EAP Client. The Client and NAS then use the MSK contained with the CS-Token to derive the transient session keys used JARI: Does this require the MSK to be actually sent? Wouldn't it be better to leave it to the methods, some methods can derive keys without actually sendin them encrypted over the channel? If the authentication occurs with a method not implemented on the NAS, or involves a non-local user whose credentials the Server is unable to validate, then the NAS functions as a "pass-through". For pass-through authentication methods, instead of implementing the authentication method locally, the NAS delegates the authentication to an Authentication Server. The Authentication Server installs the desired EAP method, typically by interfacing with the operating system via an EAP API, such as that described in [EAPAPI]. JARI: Doesn't this go to the three-party exchange section? JARI: Does the direction of sending the CS-Token have to be asymmetric? Where key distribution is supported, the EAP Client and Authentication Server (EAP Server) MUST mutually authenticate via the negotiated EAP method, and derive keys only known between the EAP Client and Server, known as the EMK. During EAP authentication, the CS-Token MAY be transported from the EAP Server to the EAP Client, providing the Client with the MSK. Alternatively, the MSK MAY be derived from the EMK, via a one-way function. Whether the MSK is derived or transported, possession JARI: Good that we allow CS-Token to be derived. Utilizing the AAA protocol, the Authentication Server and NAS MUST mutually authenticate, and derive a protected channel which MUST provide per-packet integrity protection, authentication and confidentiality. JARI: No replay protection? Wouldn't someone be able to inject a AN-token from an old session? But perhaps this is trivially handled by RADIUS/DIAMETER checking for a response matching a request it has sent. AN-Token is distributed by the Authentication Server to the NAS over this channel. Where possible, the channel between the Authentication Server and NAS SHOULD be protected using a session key, as in [DiamEAP] JARI: Reference Diameter base here instead? During the (optional) TSK derivation step, the EAP Client and NAS MUST mutually authenticate by providing mutual posession of the portion of JARI: s/providing/proving/? JARI: Is the use of TSKs (derived using an algorithm) on both sides to send packets sufficient? To use an IP-layer example, would it OK to set up a manual IPsec SA pair with keys set to f(MSK)? Or is IKE needed? If the Authentication Server and NAS do not mutually authenticate, then the the EAP Client will once again be vulnerable to rogue Authentication Servers, NASes or both. If there is no per-packet authentication, integrity and replay protection between the Authentication Server and JARI: Not in line with what was said under figure 5. Replay protection wasn't included there, and confidentiality is not mentioned here. NAS, then the EAP conversation could be modified in transit, or packets can spoofed. Since the EMK is uniquely held by the EAP Client and Server, and only mutually authenticating EAP methods may distribute keys, proof of possession of the EMK is proof of a completed mutual authentication. In order to ensure that the NAS does not possess the EMK, which could be used to impersonate the EAP Client or EAP Server, the EMK MUST NOT be provided to third parties such as the JARI: This statement may have to be more precise. What does "used to impersonate mean"? Unless the EAP method is horribly broken, the rogue NAS does not appear to be able to perform a new authentication in some other place, claiming to be the client. Similarly, even if the EMK is not given to the NAS, the NAS will still be able to impersonate the client in the sense of being able to form payload packets that look like those coming from the client. And it can also claim that the client has sent packets it did not. So what do we really want to say here? [b] Master Session Key (MSK) branch. The MSK is (optionally) distributed by the Authentication Server to the EAP Client within the CS-Token (or alternatively, derived from the EMK). It is JARI: Maybe: "The MSK is (optionally) either derived from the EMK or distributed by the ..." If the Authentication Server and NAS do not mutually authenticate, then the the EAP Client will once again be vulnerable to rogue Authentication Servers, NASes or both. If there is no per-packet authentication, integrity and replay protection between the Authentication Server and NAS, then the EAP conversation could be modified in transit, or packets can spoofed. JARI: If there is no confidentiality, then ... what? MSK hierarchy For a ciphersuite to be suitable for use with dynamic keying via EAP a specification MUST be provided describing how TSKs are derived from the MSK. JARI: Does this belong under 4.2? This is not an EAP protocol issue, and methods are not expected to know about ciphersuites. Cryptographic Separation Methods supporting key derivation MUST demonstrate cryptographic separation between the TEKs and TSKs. Also, it must be demonstrated that possession of the MSK does not provide information useful in determining the EMK. JARI: Hmm... Isn't the following the hierarchy we are specifying here: (some secret data) -> EMK -> TEK -> MSK -> TSK If it is, it appears that the part that methods are responsible is that (a) TEKs do not reveal anything from EMK, (b) MSK does not reveal anything from EMK, (c) TEK and MSK are cryptographically separated. (Do we have a term for one-way cryptographic separation, we could use it for a and b above?) The TSK issue doesn't appear to belong to the responsibility of EAP methods. However, hopefully we have somewhere the right requirement for that i.e. (d) TSK does not reveal MSK. Luckily, since TEK and MSK are separated, a TSK generated in any manner from MSK is also separated from TEK, I think. Session Uniqueness In order to assure non-repetition of TSKs even in cases where one party may not have a high quality random number generator, the MSK derivation SHOULD include a two-way nonce exchange, using nonces of at least 128-bits. Note although the IEEE 802.11 RSN TSK derivation includes a nonce exchange, the TSK derivation step is link layer dependent, so that a link layer nonce exchange cannot be guaranteed to occur. As a result, a nonce exchange is still needed within the EAP method itself. A nonce exchange SHOULD also be included in the derivation of the TEKs from the EMK. JARI: It might make sense to require either (a) nonce exchange or (b) high quality random number generation from at least one party. TEK derivation In order to establish a protected channel between the EAP Client and Server as part of the EAP exchange, a ciphersuite needs to be negotiated and keyed, using TEKs derived from the EMK. The ciphersuite used to protect the EAP exchange is distinct from the ciphersuite negotiated between the EAP client and NAS, used to protect data. Where a protected channel is established within the EAP method, the method specification MUST specify the mechanism by which the EAP ciphersuite is negotiated, as well as the algorithms for derivation of TEKs from the EMK during the EAP authentication exchange. JARI: TEK is EAP-method issue only, right? I'm starting to think TEKs and the ciphersuite to protect EAP (as in EAP TLS ciphersuites) needs to have its own section, because it is easy to confuse it with the data protection ciphersuite. Cryptographic separation The TSKs derived from the MSK MUST be cryptographically separate from each other. Similarly, TEKs MUST be cryptographically separate from each other. In addition, the TSKs MUST be cryptographically separate from the TEKs. JARI: Add that knowledge of TSK must not reveal anything from the MSK. The same for TEK->MSK. [RFC2284bis] Blunk, L., Vollbrecht, J., Aboba, B., "Extensible Authentication Protocol (EAP)", Internet draft (work in progress), draft-ietf-pppext-rfc2284bis-08.txt, December 2002. JARI: Author list on the above has changed, reference list needs an update. Export -------->| Client| | Server| | Client| | Server| Figure B-1 - TLS [RFC2246] Key Hierarchy JARI: What's "Export"? Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient session key used to protect unicast traffic, is derived from the PMK (octets 0-31 of the MSK), otherwise known as the Peer to Authenticator Encryption Key. Within [RFC2548], the PMK is transported via the MS- MPPE-Recv-Key attribute. In IEEE 802.11 RSN, the PTK is derived from the PMK via the following formula: PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion" || Min(AA,SA) || Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) Where: PMK = MSK(0,31) SA = Station MAC address AA = AP MAC address JARI: These are simply put in by the AP? They are not protected by the EAP method, and delivered from the server? How does this relate to Jesse Walker's issue for AAA key transport? From aboba@internaut.com Mon Jan 27 13:52:47 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 27 Jan 2003 05:52:47 -0800 (PST) Subject: [eap] Issue 72: RFC 2869bis review Message-ID: Issue 72: RFC 2869bis review Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: January 26, 2003 Document: draft-aboba-radius-rfc2869bis-07.txt Comment type: T Priority: S Section: various Rationale/Explanation of issue: Comments marked with "JARI:" JARI: I think we need a section on what has been updated since RFC 2869. 1. Introduction [RFC2865] describes the RADIUS Protocol as it is implemented and deployed today, and [RFC2866] describes how Accounting can be performed with RADIUS. JARI: Remove "as it is implemented and deployed today". I don't think RFC2865 talks about implementation or deployment. In order to provide for support of EAP within RADIUS, two new JARI: s/provide for support of/support/ Once EAP has been negotiated, the NAS SHOULD send an initial EAP-Request message to the authenticating peer. This will typically be an EAP-Request/Identity, although an EAP-Request for an alternate EAP method is possible. For example, a NAS might be JARI: s/alternate/actual authentication/? This could be usefulin cases where the identity is determined by another means (such as the Called-Station-Id or Calling-Station-Id), a single authentication method is required (so that the identity is not needed to determine the method), or where identity hiding is desired, so that the identity is not requested until after a protected channel has been set up. The peer responds with an EAP-Response, which the NAS encapsulates within EAP-Message attribute(s) within a RADIUS Access-Request packet, sent to the RADIUS server. For example, if an EAP-Request/Identity message is sent by the NAS as the first packet, the peer responds with an EAP-Response/Identity, and the NAS encapsulates the EAP-Response/Identity message within EAP-Message attribute(s), enclosed within an Access-Request sent to the RADIUS server. JARI: In the above, we need a discussion of the possibility that the NAS decides at this point to run a local method. Add: "Alternatively, the NAS may determine from the response that it should proceed with local authentication. Once the NAS has begun the use of RADIUS authentication for a particular session, it no longer can perform local authentication." If the RADIUS server supports EAP, it MUST respond with an Access-Challenge packet containing EAP-Message attribute(s). If the RADIUS server does not support EAP, it MUST respond with an Access-Reject. JARI: Support vs. wants to do vs. wants to do for this particular user? EAP-Message attribute(s) encapsulate a single EAP packet which the NAS decapsulates and passes on to the authenticating peer. The conversation continues until either a RADIUS Access-Reject or Access-Accept packet is received from the RADIUS server. Reception of an RADIUS Access-Reject packet MUST result in the NAS denying access to the authenticating peer. A RADIUS Access-Accept packet successfully ends the authentication phase. JARI: This could my lack of knowledge in RADIUS, but what about the simultaneous bidir authentications? What does the Access-Accept signify in that case? Both end at that time, or can we open up a new RADIUS dialog for the other auth? And what happens if the NAS/RADIUS doesn't even want to authenticate the peer, but the peer insists on authenticating the NAS/RADIUS? Seems like the initiate-with-Id-Request -approach seems wrong in such a case. Using RADIUS, the NAS can act as a pass-through for an EAP conversation between the peer and backend authentication Server, without needing to implement the EAP method used between them. Even where the NAS initiates the conversation by sending an EAP-Request, it is not required that the NAS fully implement the EAP method sent in the first packet. Depending on the method, it may be sufficient for the NAS to be configured with the initial packet to be sent to the peer, and for the NAS to act as a pass-through for subsequent messages. JARI: The above is somewhat unclear. Do you or do you not require just the identity request to be sent by the NAS? Or do you require also a canned first message to be sent if no id request is needed? Besides, not all methods can have a canned first message, e.g. challenge-response... In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP- Response/Identity in the User-Name attribute in every subsequent Access-Request. JARI: Only because of non-EAP aware proxies? What does the EAP-aware proxy use for routing the messages to the right direction, User-Name or contents of the EAP messages? I think the former... so its for the operation of all proxies, right? JARI: I'm hoping the above "MUST copy" doesn't apply for an EAP Id req/resp pair appearing within a tunneled method or in a sequence... (the NAS might be able to see this message pair if it executed the first part itself and *then* let RADIUS handle the rest. Or did we prohibit such cases already?) The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in the Access-Request packet, and either NAS-Identifier or NAS-IP-Address attributes MUST be included. In order to permit forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name attribute was included in an Access-Request, the RADIUS server MUST include the User-Name attribute in subsequent Access-Challenge, Access-Accept or Access-Reject packets. Without the User-Name attribute, accounting and billing becomes difficult to manage. If the identity is determined by another means, such as the Calling-Station-Id, the NAS MUST include these identifying attributes in every Access-Request, and the RADIUS server MUST copy these identifying attributes into subsequent Access-Challenge, Access-Accept or Access-Reject packets. JARI: Uh.... so identity hiding breaks roaming completely? There seems to be two issues that we need to deal with: 1) How to route the request to the right place. Here it is hard for me to see any solutions. Or perhaps hiding just the user name but not the domain as was done in EAP SIM & AKA. But we don't have the general machinery in EAP for that. 2) How to associate the accounting records with the right user? Would the Class attribute be suitable in this situation? The records would carry the information, but only the home network can correlate them with the actual user. Having the NAS send the initial EAP-Request packet has a number of advantages: JARI: [3] Allowing for local authentication for some users. In this case, the NAS MAY also send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. This allows the RADIUS server to take over the task of negotiating a more suitable method. JARI: Question - does the NAS include the contents of the Nak and the request that led to it when sending this EAP-Start? 2.2. Role reversal Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction. Both peers may act as authenticators and authenticatees at the same time. Support for role reversal is optional on the RADIUS server, and requires JARI: Why optional? How about mandatory to implement, optional to configure the server to actually do it? If we required mandatory support for this, would this increase the likelihood protection against rogue NASes? Or maybe we should require mutual auth support in EAP. The RADIUS server then replies with an Access-Accept (in response to an EAP-Success) or an Access-Reject (in response to an EAP-Failure), containing no EAP-Message attribute. JARI: May need to explain how the two RADIUS dialogs are independent, i.e. Access-Accept as a response to the above kind of Access-Request does *not* mean the other auth is complete and the user should be let in. Also, I'm uncertain what happens in the user is authenticated to the NAS/RADIUS first and an Access-Accept is returned, and *then* the user initiates EAP in another direction. Can this happen with PPP? 802.1X? This can be accomplished by inclusion of Session-Timeout and Password-Retry attributes within the Access- Challenge packet. JARI: I don't understand Password-Retry in this context. Wouldn't it be the RADIUS server that only is aware of an authentication failure, and would also need to send the new Requests to make possible the use of a new password? If Session-Timeout is present in an Access-Challenge packet that also contains an EAP-Message, the value of the Session-Timeout provides the NAS with the maximum number of seconds the NAS should wait for an EAP-Response before retransmitting the EAP-Request. JARI: Please clarify whether this can be received multiple times, and what the semantics are. E.g. first you start PEAP and timeout is 5 s, then inside you'll be running token caard and timeout is 60 s, apparently the NAS takes the latest received timeout value, and starts counting from the time that it received this value from the NAS? As described in [RFC2284], the EAP Success and Failure packets are not JARI: Update refs to 2284bis? Since the responsibility for avoiding these conflicts lies with the RADIUS server, the NAS MUST NOT "manufacture" EAP packets in order to correct contradictory messages that it receives. This behavior, originally mandated within [IEEE8021X], has since been deprecated. JARI: So, what does it do then? MUST disconnect? 2.6.2. Priority In addition to containing EAP-Message attributes, RADIUS messages may also contain other attributes. In order to ensure the correct processing of RADIUS messages, the NAS SHOULD process EAP-Message attributes last. JARI: We need more detail here. Say, Session-Timeout is one of these other attributes. What does 'process' mean? Look at the EAP message contained in the packet? Send that message to the peer and expect it to answer -- if so, the timeout setting would be handled too late. It is possible that the chosen Identifier value will conflict with a value chosen by the RADIUS server for another packet within the EAP conversation. This would violate the requirement that the Identifier be unique within an EAP conversation. JARI: And after this, its still a MAY? Backwards compatibility prevents us prohibiting it? When used within an EAP conversation, a Reply-Message attribute received by the NAS MAY be translated to an EAP-Request/Notification sent to the peer. As a result, a Reply-Message attribute MUST NOT be included in a RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP-Request/Notification or Reply-Message attribute SHOULD NOT be included within an Access-Accept or Access-Reject packet representing the conclusion of an EAP conversation. JARI: But this is in conflict in 2.6.3! Delete 2.6.3 and use this instead? Value The Value field is four octets, containing an integer specifying the number of password retry attempts to permit the user. JARI: I must be missing something obvious again. What does the NAS do with this information? If it is running EAP and carrying it over to the RADIUS server, it doesn't appear to be able to tell whether the response messages from the peer used the right password or not. Nor can it resend Requests, there'd be Identifier conflicts, no? RADIUS over IPsec, defined in [RFC3162] will eventually make this attribute obsolete, so it should be considered an interim measure. JARI: When is the time to start requiring this? Or should new protocols just start using DIameter instead? Vulnerabilities include: Separation of EAP server and authenticator Dictionary attacks Known plaintext attacks Replay protection Connection hijacking Man in the middle attacks Multiple databases Negotiation attacks JARI: No DoS? Reading on... For the authenticating peer, authentication policy should be set on a per-connection basis. Per-connection policy allows an authenticating peer to negotiate a strong EAP method when connecting to one service, while negotiating a weaker EAP method for another service. JARI: Per-service or per-connection? If its per-connection, what if the attacker causes a disconnect, then offers a weaker method? Ah, the explanation below clarifies this. Wouldn't the right name for this be "per-service"? An authenticating peer expecting EAP to be negotiated for a session MUST NOT negotiate a weaker method, such CHAP or PAP. JARI: s/such/such as/ wireless networks, the service advertisement itself may be spoof-able, so that an attacker could fool the peer into negotiating an authentication method suitable for a less secure network. JARI: Ouch! So, per-service isn't very helpful either unless you support the same security level for all services. EAP-capable authenticating peer MUST refuse to renegotiate the authentication protocol if EAP had initially been negotiated. Note that problems with a non-EAP capable RADIUS proxy could prove difficult to diagnose, since a user connecting from one location (with an EAP-capable proxy) might be able to successfully authenticate via EAP, while the same user connecting at another location (and encountering an EAP-incapable proxy) might be consistently disconnected. JARI: Ok, so to get back to the DoS issue... let's see: No, I can't think of any additional dos problems beyond those already present in EAP. 5. Normative references JARI: I'm not sure why the above ones are normative. At least the first one should be informative? From aboba@internaut.com Mon Jan 27 14:54:59 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 27 Jan 2003 06:54:59 -0800 (PST) Subject: [eap] Re: EAPv2 In-Reply-To: <200301271357.h0RDvDk21163@internaut.com> Message-ID: > Some ideas what properties this "EAPv2" could have: > > - Designed to be used in environments where the underlying > medium is not secure. Since EAP is largely a datagram transport, it's not clear to me why it needs any more inherent security than say, UDP, with the possible exception of Success and Failure messages. After all, nooone is claiming that we need UDPv2 in order to make IKE secure. So far, the changes that have been brought forward that would improve security are mostly transport issues (bigger Identifier & Type space) and state machine clarifications. So we should not over-estimate what can be achieved by changing the datagram headers. > - Designed and specified so that it is easy to "embed" EAPv2 in > other protocols (EAPv1 was designed to be extensible, but it > was not intended as a "building block" for other protocols). GSS-API is the IETF solution to this problem. Is there a compelling case for creating something new? > - Maybe better support for mutual authentication and method > negotiation related to it. Mutual authentication can be done today in EAPv1. How would EAPv2 make that easier? Also in terms of negotiation, unlike in GSS-API, there is no key assumed to exist at the time that EAP negotiation occurs. So the exchange MUST be unprotected -- and EAPv2 would not change that. Of course, the negotiation result can be verified later - but this is also supported in EAPv1. > - EAPv2 records could be transported as an EAPv1 method, so it could > be used in PPP/802.1X environments without changing NAS boxes. Sounds like a tunneling protocol -- which could be developed as an EAPv1 method. > - Clear specification of behavior (state machines, etc.), so that > EAPv2 would be simpler and easier to implement than EAPv1. Given how widely EAP has been implemented, it is hard to argue that protocol complexity is holding back deployment. > Clearly, the main target of this work would not be PPP, or even > 802.1X/11i, but new protocols which would like to reuse an existing > "building block" (PANA, PIC, others?). PIC was looking to reuse an existing protocol, so that's probably not a good candidate for this. PANA might be, but only if a case can be made that the issues can't be fixed in the lower layer transport. > Perhaps some of the more difficult issues in 2284bis > could be postponed to this "EAPv2"? Given that we only have three issues open, I don't see much value in putting them off, especially since we're already discussing potential solutions to them. From jari.arkko@piuha.net Mon Jan 27 09:47:48 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 27 Jan 2003 11:47:48 +0200 Subject: [eap] issues 71 and 72 References: Message-ID: <3E350044.1010604@piuha.net> Hello, Given that there were many comments to different parts of the documents, the comments may be easier to read from the following URLs: http://www.piuha.net/~jarkko/publications/eap/keyingframework_review.txt http://www.piuha.net/~jarkko/publications/eap/rfc2869bis_review.txt Jari From aboba@internaut.com Wed Jan 29 00:36:41 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 28 Jan 2003 16:36:41 -0800 Subject: [eap] Re: Multiple RADIUS packets Message-ID: <200301290036.h0T0af806726@internaut.com> If you're proposing changes to the EAP header to address fragmentation, I would suggest that you file an issue with the EAP WG mailing list using the format in: http://www.drizzle.com/~aboba/EAP/eapissues.html This seems like the crucial issue because RFC 2869 already can handle EAP methods that support fragmentation (e.g. EAP TLS). So it would not appear to be a RADIUS issue, per se. ---------- Original message ---------- Date: Tue, 28 Jan 2003 14:43:14 -0800 From: Murtaza S. Chiba Reply-To: Murtaza S. Chiba To: Bernard Aboba , Greg Weber Subject: Multiple RADIUS packets Hi Bernard, A mechanism to break-up a huge EAP message into multiple parts for transmission on the Authenticator-Authentication Server interface, I was thinking we can use a combination of Flags in the EAP message header, the state attribute(from the Authenticator and Authentication Server) and Access-Challenge from Authentication Server. That is the flag in the EAP packet indicates more fragments and the Authenticator includes its own State attribute which should be echo'd back by the Authentication Server in an Access-Challenge. The Authentication Server should add its own State attribute only after the one from the Authenticator, just like a Proxy State. Regards, Murtaza From Pasi.Eronen@nokia.com Wed Jan 29 09:32:31 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Wed, 29 Jan 2003 11:32:31 +0200 Subject: [eap] Re: EAPv2 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BA0A@esebe023.ntc.nokia.com> On January 27, 2003 Bernard Aboba wrote: >> Some ideas what properties this "EAPv2" could have: >> >> - Designed to be used in environments where the underlying >> medium is not secure. > > Since EAP is largely a datagram transport, it's not clear to me why it > needs any more inherent security than say, UDP, with the possible > exception of Success and Failure messages. After all, nooone is > claiming that we need UDPv2 in order to make IKE secure. So far, > the changes that have been brought forward that would improve security > are mostly transport issues (bigger Identifier & Type space) and > state machine clarifications. So we should not over-estimate what > can be achieved by changing the datagram headers. Well, this depends on whether you think EAP is a datagram transport mechanism, or a general-purpose authentication framework. As a datagram=20 transport, EAP works fine, but a framework like ISAKMP does a lot more=20 than just sending bits from one place to another. >> - Designed and specified so that it is easy to "embed" EAPv2 in >> other protocols (EAPv1 was designed to be extensible, but it >> was not intended as a "building block" for other protocols). > > GSS-API is the IETF solution to this problem. Is there a compelling > case for creating something new? You're of course absolutely right, IETF already has a solution for this, and probably there isn't a compelling case to replace it. However, when you compare RFC 2284 and the latest 2284bis draft, you can't blame somebody (including myself) for thinking that EAP is trying to replace GSS-API as an authentication building block (although this probably was not the intention of 2284bis), and=20 have used or tried to use it as such (PIC, EAP/SIP, ...). RFC 2284 doesn't even mention the possibility of using EAP for something else than PPP; 2284bis adds a lot of stuff which would be useful to have in a general-purpose authentication building block (just compare the abstracts to get an idea what I'm trying to say; even the length has increased from 15 pages to 40!). I guess my point in suggesting EAPv2 was that if people are going to use EAP as an authentication "building block" for other protocols,=20 it would be nice to have some things EAP currently does not. If we adopt the position that EAP should not be used as such a building block (and people should use GSS-API instead), then=20 would it be a good idea to include a "usage guidelines" section=20 in 2284bis, clearly stating this? Best regards, Pasi From jari.arkko@piuha.net Tue Jan 28 09:07:37 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 28 Jan 2003 11:07:37 +0200 Subject: [eap] state machine design team conf call minutes, jan 29th Message-ID: <3E364859.8040806@piuha.net> EAP State Machine Design Team Conference Call Minutes Date: Wednesday, January 29, 2003 Time: 8 AM PST Participants: John Vollbrech, Bernard Aboba, Nick Petroni, Chuk Yang Seng, Bob Moskowitz, Jari Arkko Agenda o Discussion of EAP state machine document http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.txt http://www.ietf.org/internet-drafts/draft-payne-eap-sm-01.ps - John has been talking to Jim Burns on synchronizing the IETF and IEEE state machines for the authenticator, and John intends to go to the 802.11 meeting in Seattle if there's enough interest from their side to work on this issue. Bernard: It is unclear who on the IEEE side is the main state machine expert, and who cares most of the issue. John: Jessie Walker has been that person in the past at least. - John: Pre-auth in WLANs requires state machine changes. Bernard: Not really at the EAP layer. It just provides indication to the link layer about a change in its state machine. 802.11i is complex in the sense that authentication might occur before or after association. Unfortunately, there is no state machine to describe pre-authentication. Bernard's clarifications to the 802.11i state machine regarding this were not taken to the current specification. This does not affect EAP state machine however, as the signals to the 802.11i are the same. Bernard: Pre-auth changes the 802.11i state machine. Even before associating with a nearby access point, you move from the unauthenticated state to the authenticated state. Bob: No, this is not true. This is just authentication frames, not movements in the authentication state machine. Besides, 802.11i does not have a state machine, it only has some text about this. We are changing the moving state in terms of the 802.11i. Bernard: When you arrive at the AP, are you in state 1 or state2 ? Bob: State 1. Bernard: Maybe I'm wrong but the draft doesn't state this. Bob: Yes, its unclear. Jari: What happens if you are in state 1 after move? Bernard: Then you have to still do 802.11 open auth. Then you do EAPOL-Start, and the response will be the final 4-way handshake not the EAP run. Jari: what happens if the sides don't agree whether preauth has happend. Bernard: The answer is that we need a state machine. Bob: If the station rebooted and lost the keys, the result would be a timeout since the expected 4-way handshake would not come. Bob: I'm going to go back and take a look at this. Bernard: There remains a lot of work to make this clear. John: Are we allowed to discuss this in Seattle? Bob: There are so many comments that only comments will be discussed during the main meeting. It is important to pick the comments that indicate the need for the state machine. John will contact Dorothy in order to ensure that there's enough people willing to work on these issues. - Bob: With the state machines, the methods have to take on new tasks they didn't have before. Bernard: That's not right. Bob: Announcing that a key is available is one such thing. Bernard: Yes. But it isn't clear that the switch sends the "key available" event forward immediately after the method has informed it about it? Bob: We need a section about guidelines for method implementers in the document. John: Yes. Bernard: If the EAP method provides keys, at some point, is that the required signal? Or is there something additional required to push the key in use? The problem is that in some cases the keys should be used immediately, and in other cases they should be used later. Bob: This is a method issue. We need to describe what information the method is expected to provide to the switch. Is this breaking methods? Bernard: This is an implementation issue, does not change what goes over the wire. Bob: But we are formalizing things more now with explicit variables in the state machine etc. Bernard: RFC 2284 was vague. As we are making 2284 bis a better document, we may in some cases make some behaviour unallowed. o Open issues - Bernard: Paul Funk and Bernard have talked about issue #41. Paul is saying that if you send an extended method, you should respond with an extended Nak. Bob: - Bill Arbaugh will provide an opinion on the other two. o Other issues - John: We are getting to a situation where methods are link-layer dependent. Bernard: No, link layers such as 802.11i just set a set of requirements such as mutual authentication and key generation. - A 3GPP - IETF conference was held this week in San Francisco. The main question 3GPP had for the EAP WG was how many documents the WG has to finish before methods can be written. The intention is to try to get it down to a small number. The intention is to move normative requirements for methods from the keying framework to 2284bis document. 3GPP will also need the DIAMETER EAP, key wrap, DIAMETER NASREQ, EAP SIM, and EAP AKA documents as references in their specifications. Additionally, the keying framework document is likely necessary for the security review when we are publishing e.g. the DIAMETER EAP and key wrap (CMS) documents. John: We also need guidelines on what the method implementations must do, the small things such as what you do when you receive a malformed message. Bernard: We have language in the latest 2284 bis that says what to do in this case. EAP TLS doesn't do this, however. - RFC 2284 bis will get a new editor. A note on this will be posted to the list this week. From aboba@internaut.com Wed Jan 29 22:15:49 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 29 Jan 2003 14:15:49 -0800 (PST) Subject: [eap] Announcing: New Editor for RFC 2284bis, Henrik Levkowetz Message-ID: Effective today, we have a new editor for RFC 2284bis: Henrik Levkowetz. As I hope you will all come to appreciate, Henrik brings to the job considerable expertise in the wireless arena, as well as expertise in editing of IETF documents. I hope you will join me in welcoming Henrik to the team. It is our hope that by building an editorial team, we can be able to make more progress on all of the items on our charter so as to meet our milestones which, since they impact other standards bodies such as 3GPP and IEEE 802.11, are relatively inflexible. For those of you who do not know Henrik, here is an introduction, in his own words: "I'm currently working about fifty-fifty with IETF work and software design and coding related to a Mobile-IP enabled gateway/router produced by ipUnplugged in Stockholm, Sweden. I became interested in programming and ran my first program in 1968, and haven't been able to let it go since :-) After a M.Sc in Physics I've worked many years with embedded software, then from 1996 to 2001 both as a manager and with software development for cellular phone systems. In 2001 I started work with ipUnplugged and focused on Mobile-IP and related work. I've been doing IETF work since late 2000, edited the first 2 drafts of a seamoby document which is now RFC3374 , also the Mobile-IP NAT traversal draft which has recently been approved as a proposed standard, and a few less interesting drafts. I enjoy horseriding, hiking and good food and drink, and live together with 3 cats." --- I plan to make intermediate work documents in the 2284bis work available through the web page at http://www.levkowetz.com/pub/ietf/drafts/eap/ , in text, html and xml form. I hope to have the first drafty conversion of the current (-10) draft to xml available there tomorrow. Best regards, Henrik -- Henrik Levkowetz +46708321608 henrik@levkowetz.com www.levkowetz.com -------------------------------------------------------------------- Ah! this azure sky! The colour makes my heart jump and my spirit fly. From dave@frascone.com Thu Jan 30 14:57:39 2003 From: dave@frascone.com (David Frascone) Date: Thu, 30 Jan 2003 08:57:39 -0600 Subject: [eap] test, please ignore Message-ID: <20030130145739.GD22296@wolverine> -- David Frascone A bird in the hand can be messy. From henrik@levkowetz.com Thu Jan 30 17:33:59 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Thu, 30 Jan 2003 18:33:59 +0100 Subject: [eap] XML based version of 2284bis draft available Message-ID: <20030130183359.00004a66.henrik@levkowetz.com> Hi, An unpolished XML-based text version of the 2284bis draft is now available at http://www.levkowetz.com/pub/ietf/drafts/eap/ , along with an html version generated from the xml source, and an alternate html version generated from the text version. No textual changes have been done relative to the -10 draft so far; next I'll be dealing with a number of typos and editorial changes I've already run by Bernard. Regards, Henrik -- Henrik Levkowetz +46708321608 henrik@levkowetz.com www.ipunplugged.com ---------------------------------------------------------------------- From aboba@internaut.com Fri Jan 31 14:14:10 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 31 Jan 2003 06:14:10 -0800 (PST) Subject: [eap] Proposed Resolution of Issue 72 Message-ID: I've put my proposed responses inline with a BA: preceeding them. Issue 72: RFC 2869bis review Submitter name: Jari Arkko Submitter email address: jari.arkko@piuha.net Date first submitted: January 26, 2003 Document: draft-aboba-radius-rfc2869bis-07.txt Comment type: T Priority: S Section: various Rationale/Explanation of issue: Comments marked with "JARI:" JARI: I think we need a section on what has been updated since RFC 2869. BA: Yes. I will add this. 1. Introduction [RFC2865] describes the RADIUS Protocol as it is implemented and deployed today, and [RFC2866] describes how Accounting can be performed with RADIUS. JARI: Remove "as it is implemented and deployed today". I don't think RFC2865 talks about implementation or deployment. BA: Done. In order to provide for support of EAP within RADIUS, two new JARI: s/provide for support of/support/ BA: Done. Once EAP has been negotiated, the NAS SHOULD send an initial EAP-Request message to the authenticating peer. This will typically be an EAP-Request/Identity, although an EAP-Request for an alternate EAP method is possible. For example, a NAS might be JARI: s/alternate/actual authentication/? BA: Done. This could be usefulin cases where the identity is determined by another means (such as the Called-Station-Id or Calling-Station-Id), a single authentication method is required (so that the identity is not needed to determine the method), or where identity hiding is desired, so that the identity is not requested until after a protected channel has been set up. The peer responds with an EAP-Response, which the NAS encapsulates within EAP-Message attribute(s) within a RADIUS Access-Request packet, sent to the RADIUS server. For example, if an EAP-Request/Identity message is sent by the NAS as the first packet, the peer responds with an EAP-Response/Identity, and the NAS encapsulates the EAP-Response/Identity message within EAP-Message attribute(s), enclosed within an Access-Request sent to the RADIUS server. JARI: In the above, we need a discussion of the possibility that the NAS decides at this point to run a local method. Add: "Alternatively, the NAS may determine from the response that it should proceed with local authentication. Once the NAS has begun the use of RADIUS authentication for a particular session, it no longer can perform local authentication." If the RADIUS server supports EAP, it MUST respond with an Access-Challenge packet containing EAP-Message attribute(s). If the RADIUS server does not support EAP, it MUST respond with an Access-Reject. BA: Done. JARI: Support vs. wants to do vs. wants to do for this particular user? BA: Done. EAP-Message attribute(s) encapsulate a single EAP packet which the NAS decapsulates and passes on to the authenticating peer. The conversation continues until either a RADIUS Access-Reject or Access-Accept packet is received from the RADIUS server. Reception of an RADIUS Access-Reject packet MUST result in the NAS denying access to the authenticating peer. A RADIUS Access-Accept packet successfully ends the authentication phase. JARI: This could my lack of knowledge in RADIUS, but what about the simultaneous bidir authentications? What does the Access-Accept signify in that case? Both end at that time, or can we open up a new RADIUS dialog for the other auth? And what happens if the NAS/RADIUS doesn't even want to authenticate the peer, but the peer insists on authenticating the NAS/RADIUS? Seems like the initiate-with-Id-Request -approach seems wrong in such a case. BA: Each authentication is handled as a separate RADIUS session, or else things get very confusing. However, where the client is attempting to authenticate the NAS, Accept doesn't mean "grant access" or that would open a security loophole. Perhaps that is an argument to remove this text altogether. It can cause trouble and I don't expect it to be implemented widely. Using RADIUS, the NAS can act as a pass-through for an EAP conversation between the peer and backend authentication Server, without needing to implement the EAP method used between them. Even where the NAS initiates the conversation by sending an EAP-Request, it is not required that the NAS fully implement the EAP method sent in the first packet. Depending on the method, it may be sufficient for the NAS to be configured with the initial packet to be sent to the peer, and for the NAS to act as a pass-through for subsequent messages. JARI: The above is somewhat unclear. Do you or do you not require just the identity request to be sent by the NAS? Or do you require also a canned first message to be sent if no id request is needed? Besides, not all methods can have a canned first message, e.g. challenge-response... BA: I've rewritten this section to improve clarity. See what you think: http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-08.txt In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP- Response/Identity in the User-Name attribute in every subsequent Access-Request. JARI: Only because of non-EAP aware proxies? What does the EAP-aware proxy use for routing the messages to the right direction, User-Name or contents of the EAP messages? I think the former... so its for the operation of all proxies, right? BA: User-Name, because the proxies also act as pass-throughs. I've added some text to clarify this. JARI: I'm hoping the above "MUST copy" doesn't apply for an EAP Id req/resp pair appearing within a tunneled method or in a sequence... (the NAS might be able to see this message pair if it executed the first part itself and *then* let RADIUS handle the rest. Or did we prohibit such cases already?) BA: The NAS cannot see the inner method in a tunnel because it acts as a pass-through and does not decrypt EAP messages passing through it. The use of Reply-Message is now deprecated, in favor of EAP-Request/Notification. The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in the Access-Request packet, and either NAS-Identifier or NAS-IP-Address attributes MUST be included. In order to permit forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name attribute was included in an Access-Request, the RADIUS server MUST include the User-Name attribute in subsequent Access-Challenge, Access-Accept or Access-Reject packets. Without the User-Name attribute, accounting and billing becomes difficult to manage. If the identity is determined by another means, such as the Calling-Station-Id, the NAS MUST include these identifying attributes in every Access-Request, and the RADIUS server MUST copy these identifying attributes into subsequent Access-Challenge, Access-Accept or Access-Reject packets. JARI: Uh.... so identity hiding breaks roaming completely? There seems to be two issues that we need to deal with: 1) How to route the request to the right place. Here it is hard for me to see any solutions. Or perhaps hiding just the user name but not the domain as was done in EAP SIM & AKA. But we don't have the general machinery in EAP for that. 2) How to associate the accounting records with the right user? Would the Class attribute be suitable in this situation? The records would carry the information, but only the home network can correlate them with the actual user. BA: Class attribute can be added, yes. I've added to the table of attributes to make this clear. Having the NAS send the initial EAP-Request packet has a number of advantages: JARI: [3] Allowing for local authentication for some users. BA: Done. In this case, the NAS MAY also send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. This allows the RADIUS server to take over the task of negotiating a more suitable method. JARI: Question - does the NAS include the contents of the Nak and the request that led to it when sending this EAP-Start? BA: I've clarified the text to indicate that it is possible to send the Nak embedded in the initial Access-Request, to give the RADIUS server a hint about what the peer wants to do. However, when that is done, an EAP-Start is *not* included as well. 2.2. Role reversal Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction. Both peers may act as authenticators and authenticatees at the same time. Support for role reversal is optional on the RADIUS server, and requires JARI: Why optional? How about mandatory to implement, optional to configure the server to actually do it? If we required mandatory support for this, would this increase the likelihood protection against rogue NASes? Or maybe we should require mutual auth support in EAP. BA: I'm now leaning toward removing support for role reversal. The RADIUS server then replies with an Access-Accept (in response to an EAP-Success) or an Access-Reject (in response to an EAP-Failure), containing no EAP-Message attribute. JARI: May need to explain how the two RADIUS dialogs are independent, i.e. Access-Accept as a response to the above kind of Access-Request does *not* mean the other auth is complete and the user should be let in. Also, I'm uncertain what happens in the user is authenticated to the NAS/RADIUS first and an Access-Accept is returned, and *then* the user initiates EAP in another direction. Can this happen with PPP? 802.1X? BA: I don't think I can explain it -- so it probably should be removed. This can be accomplished by inclusion of Session-Timeout and Password-Retry attributes within the Access- Challenge packet. JARI: I don't understand Password-Retry in this context. Wouldn't it be the RADIUS server that only is aware of an authentication failure, and would also need to send the new Requests to make possible the use of a new password? BA: On reflection, neither do I. I've removed all mention of this attribute in the text, and indicated in the attribute table that it isn't used in EAP conversations. If Session-Timeout is present in an Access-Challenge packet that also contains an EAP-Message, the value of the Session-Timeout provides the NAS with the maximum number of seconds the NAS should wait for an EAP-Response before retransmitting the EAP-Request. JARI: Please clarify whether this can be received multiple times, and what the semantics are. E.g. first you start PEAP and timeout is 5 s, then inside you'll be running token caard and timeout is 60 s, apparently the NAS takes the latest received timeout value, and starts counting from the time that it received this value from the NAS? BA: Yes. As described in [RFC2284], the EAP Success and Failure packets are not JARI: Update refs to 2284bis? BA: Since RFC 2869bis needs to be published right away since it is a dependency of IEEE 802.1aa, and 802.1aa does not have a dependency on RFC2284bis so far, adding one is probably not a good idea. Since the responsibility for avoiding these conflicts lies with the RADIUS server, the NAS MUST NOT "manufacture" EAP packets in order to correct contradictory messages that it receives. This behavior, originally mandated within [IEEE8021X], has since been deprecated. JARI: So, what does it do then? MUST disconnect? BA: The client can't tell if the NAS is manufacturing or not, so I can't see any way to act differently. 2.6.2. Priority In addition to containing EAP-Message attributes, RADIUS messages may also contain other attributes. In order to ensure the correct processing of RADIUS messages, the NAS SHOULD process EAP-Message attributes last. JARI: We need more detail here. Say, Session-Timeout is one of these other attributes. What does 'process' mean? Look at the EAP message contained in the packet? Send that message to the peer and expect it to answer -- if so, the timeout setting would be handled too late. BA: It means send the message to the peer. It is possible that the chosen Identifier value will conflict with a value chosen by the RADIUS server for another packet within the EAP conversation. This would violate the requirement that the Identifier be unique within an EAP conversation. JARI: And after this, its still a MAY? Backwards compatibility prevents us prohibiting it? BA: I've made it a SHOULD NOT. When used within an EAP conversation, a Reply-Message attribute received by the NAS MAY be translated to an EAP-Request/Notification sent to the peer. As a result, a Reply-Message attribute MUST NOT be included in a RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP-Request/Notification or Reply-Message attribute SHOULD NOT be included within an Access-Accept or Access-Reject packet representing the conclusion of an EAP conversation. JARI: But this is in conflict in 2.6.3! Delete 2.6.3 and use this instead? BA: I've integrated this with 2.6.3. Value The Value field is four octets, containing an integer specifying the number of password retry attempts to permit the user. JARI: I must be missing something obvious again. What does the NAS do with this information? If it is running EAP and carrying it over to the RADIUS server, it doesn't appear to be able to tell whether the response messages from the peer used the right password or not. Nor can it resend Requests, there'd be Identifier conflicts, no? BA: Good catch. I've removed mention of Password-Retry, since on reflection it doesn't make sense to me either. RADIUS over IPsec, defined in [RFC3162] will eventually make this attribute obsolete, so it should be considered an interim measure. JARI: When is the time to start requiring this? Or should new protocols just start using DIameter instead? BA: I've made it a SHOULD. Vulnerabilities include: Separation of EAP server and authenticator Dictionary attacks Known plaintext attacks Replay protection Connection hijacking Man in the middle attacks Multiple databases Negotiation attacks JARI: No DoS? Reading on... BA: Do you have some text to suggest? For the authenticating peer, authentication policy should be set on a per-connection basis. Per-connection policy allows an authenticating peer to negotiate a strong EAP method when connecting to one service, while negotiating a weaker EAP method for another service. JARI: Per-service or per-connection? If its per-connection, what if the attacker causes a disconnect, then offers a weaker method? Ah, the explanation below clarifies this. Wouldn't the right name for this be "per-service"? BA: Yes. Now using that term. An authenticating peer expecting EAP to be negotiated for a session MUST NOT negotiate a weaker method, such CHAP or PAP. JARI: s/such/such as/ BA: Done. wireless networks, the service advertisement itself may be spoof-able, so that an attacker could fool the peer into negotiating an authentication method suitable for a less secure network. JARI: Ouch! So, per-service isn't very helpful either unless you support the same security level for all services. BA: yes. EAP-capable authenticating peer MUST refuse to renegotiate the authentication protocol if EAP had initially been negotiated. Note that problems with a non-EAP capable RADIUS proxy could prove difficult to diagnose, since a user connecting from one location (with an EAP-capable proxy) might be able to successfully authenticate via EAP, while the same user connecting at another location (and encountering an EAP-incapable proxy) might be consistently disconnected. JARI: Ok, so to get back to the DoS issue... let's see: No, I can't think of any additional dos problems beyond those already present in EAP. BA: OK. 5. Normative references JARI: I'm not sure why the above ones are normative. At least the first one should be informative? BA: Probably.