idnits 2.17.1 draft-ietf-eap-esteem-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 55 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 56 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 154 instances of too long lines in the document, the longest one being 21 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2023 has weird spacing: '...tv/auth snd N...' == Line 2025 has weird spacing: '...s/notok not-...' == Line 2027 has weird spacing: '...done.ok actv/...' == Line 2032 has weird spacing: '...tv/auth term...' == Line 2033 has weird spacing: '...tng-mth sile...' == (4 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (9 January 2003) is 7771 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '2' is mentioned on line 1006, but not defined == Missing Reference: '3' is mentioned on line 1009, but not defined == Missing Reference: '4' is mentioned on line 1024, but not defined == Missing Reference: '5' is mentioned on line 1030, but not defined == Missing Reference: '6' is mentioned on line 1042, but not defined == Missing Reference: '7' is mentioned on line 1054, but not defined == Missing Reference: '9' is mentioned on line 1061, but not defined == Missing Reference: '10' is mentioned on line 1073, but not defined == Missing Reference: '11' is mentioned on line 1078, but not defined == Missing Reference: '12' is mentioned on line 1093, but not defined == Unused Reference: 'RFC1661' is defined on line 2444, but no explicit reference was found in the text == Unused Reference: 'RFC1994' is defined on line 2447, but no explicit reference was found in the text == Unused Reference: 'RFC2044' is defined on line 2450, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 2453, but no explicit reference was found in the text == Unused Reference: 'RFC2279' is defined on line 2456, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 2459, but no explicit reference was found in the text == Unused Reference: 'RFC2988' is defined on line 2463, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 2466, but no explicit reference was found in the text == Unused Reference: 'IEEE8021X' is defined on line 2469, but no explicit reference was found in the text == Unused Reference: 'DECEPTION' is defined on line 2475, but no explicit reference was found in the text == Unused Reference: 'RFC1510' is defined on line 2478, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 2481, but no explicit reference was found in the text == Unused Reference: 'RFC2486' is defined on line 2484, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 2487, but no explicit reference was found in the text == Unused Reference: 'RFC2408' is defined on line 2490, but no explicit reference was found in the text == Unused Reference: 'RFC2433' is defined on line 2494, but no explicit reference was found in the text == Unused Reference: 'RFC2661' is defined on line 2497, but no explicit reference was found in the text == Unused Reference: 'RFC2716' is defined on line 2501, but no explicit reference was found in the text == Unused Reference: 'KRBATTACK' is defined on line 2504, but no explicit reference was found in the text == Unused Reference: 'KRBLIM' is defined on line 2508, but no explicit reference was found in the text == Unused Reference: 'KERB4WEAK' is defined on line 2512, but no explicit reference was found in the text == Unused Reference: 'PIC' is defined on line 2517, but no explicit reference was found in the text == Unused Reference: 'PPTPv1' is defined on line 2521, but no explicit reference was found in the text == Unused Reference: 'IEEE8023' is defined on line 2526, but no explicit reference was found in the text == Unused Reference: 'IEEE80211' is defined on line 2534, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) == Outdated reference: A later version (-07) exists of draft-ietf-ipsra-pic-05 Summary: 12 errors (**), 0 flaws (~~), 46 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP Working Group B. Aboba, Editor 3 INTERNET-DRAFT Microsoft 4 Category: Informational 5 6 9 January 2003 8 Eap STate machinE dEsign teaM (ESTEEM) Discussions 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet- Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2002). All Rights Reserved. 32 Abstract 34 This document describes the deliberations of the EAP STate MachinE 35 DEsign TeaM (ESTEEM). This includes minutes of meetings, as well as 36 position papers. 38 1. Key Issues for Resolution in RFC 2284bis 40 Nick Petroni 41 October 14, 2002 42 I see three major areas at first glance. This is not 43 comprehensive, just off the top of my head. 45 a. EAP MUX/method and method/method interaction. 47 It seems most people have settled into the MUX paradigm and some of the 48 details have been decided such as: 49 - MUX and not methods sending Success/Fail 50 - Methods cannot be interrupted (one method at a time) 51 - Identity is a special kind of method (can't be NAK'd, etc.) 53 but other details don't seem clearly defined. In particular 54 - How does information get passed from method to method? through the 55 MUX? directly between methods? not at all? Since Methods can send Id 56 REQ themselves, is it assumed all methods have access to this info? 57 - How does the MUX know a method has begun/finished? This is 58 particularly important in terms of success/failure only being 59 allowed at specific times. We have discussed authMethodSuccess and 60 Fail indications, but I don't think these have been set in stone. 61 - How is order determined? Is this standardized, or just blanketed by 62 policy? Do methods get to pick "I want to be followed by X and will 63 only go after Y"? Is it enough to say something such as "MD5 before 64 TLS" and 65 what does that mean for cases where the same auth method could be 66 run twice, e.g. "MD5 TLS MD5". I don't see why one would want to do 67 this, but should the protocol allow it? Since there could be 68 multiple back-end servers involved, it seems more likely than I 69 would hope. Is it significant which MD5 goes first? 70 - how are methods with specific requirements like being the last 71 method run handled? Does the method tell the MUX this or is it part 72 of policy? Packet filters have been discussed here, but how/when are 73 these specified by the method? 75 b. Policy specification 76 - If order is part of policy, how is it specified? 77 - it seems that any method can update policy (as shown in the state 78 machine draft) and only the MUX can determine if the whole policy 79 has been satisfied. how does this work for encapsulated methods such 80 as PEAP? do they have their own policy with the outer policy just 81 requiring "PEAP with policy x" to be successful? 82 - can general policy rules such as "any protocol providing successful 83 mutual authentication"? how are these specified? 84 - are there limitations/specifications for how a method interacts with 85 policy? For example, will statements such as "All methods must 86 update policy variable X" be added to the bis? 88 c. Error handling 89 Conversations have ranged from adding a new message to modifying an 90 existing one or just punting on errors all together. This could go any 91 direction, but all would affect the state machine. 93 2. Meeting minutes 95 2.1. September 25, 2002 Minutes 97 EAP Design Team Meeting Minutes 98 Scribe: Paul Congdon, HP 99 09/25/02 101 Yoshi's Paper 103 a. Issue 1 - How to handle notational conventions within state 104 diagrams. There is also an issue relating to handling of the timing. 106 Suggest two solutions - use an already defined convention (e.g. 107 IEEE 802.1X) or use other current and more formal conventions. Chuck 108 believes current format is less formal and unclear on how steps within a 109 state are executed and whether they are atomic or not. Paul suggests 110 adding words from 802 documents that clarify. Other believe that real 111 events should be noted in the transitions not just variables. 112 Bernard raises a question about sub-machine interactions and the 113 entrance points. Unclear what information is available to methods. For 114 example, is information in an Identity exchange available to the method? 115 What about NAK? Notification? Wording can be added to clarify entry 116 points. 118 Do methods need to know about one another? If so, how is 119 communication facilitated? We don't want to allow this to be an exercise 120 for the reader. Perhaps RFC2284bis needs an abstract API to allow this? 121 The concept of an EAP mux helps clarify how the state machines 122 interact. 124 Seems to be some agreement that we can slightly deviate from the 125 802 machine format, but keep the spirit intact such that it is obvious to 126 the reader. This makes it easier to synch the EAP and 802.1X state 127 machines. 129 b. Issue 2 - Identity exchange is optional, but the authenticator 130 machine doesn't really support it well. 132 Some would prefer to see ID exchange as simply one of the methods. 133 However, would the ID method ever occur without other methods invoked? 134 Not likely, but certainly multiple IDs exchanges could be possible. 135 Methods can't interrupt other methods. There is an assumption that a 136 variable exists that controls the authenticator to send or not the ID. 137 This variable is not specified in 802.1X or the EAP state machine 138 document. 140 >From the Radius server's point of view, the ID exchange starts out 141 as a method, but RADIUS servers often receive the Access Request after the 142 ID Request has been sent by the Authenticator, answered with an ID 143 Response from the Supplicant, and the Identity placed in a User-Name 144 attribute. So the RADIUS server typically does not request an Identity 145 exchange. 147 There is a need for a needID variable that drives the backend 148 state machine as well. It actually describes what the first step is for 149 each method. How is this variable controlled when multiple methods are 150 changed. For example, if needID is set then the Authenticator starts out 151 by sending an Identity Request. If not, then it sends an Access-Request to 152 the RADIUS server (which can't contain a User-Name attribute because the 153 identity isn't known yet). 155 Consensus that a needID is needed, but unclear how it is 156 controlled still. Still unclear if ID exchange should be thought of as a 157 method. If it is a method, do we still need needID? If it is a method, 158 it should fold into the current proposed machines without significant 159 disruption. No conclusion yet if ID exchange is a method. 160 c. Issue 3 - Inconsistency when processing NAK. 162 Can't a NAK break the in-progress EAP method? Typically this 163 means the Supplicant doesn't want to run this method, so he NAKs with 164 alternatives. It is up to the authenticator to decide what method will 165 run next if any. 167 It appears that currently the NAK can be sent anytime, so perhaps 168 it should be its own machine. It can be sent in the middle of a method to 169 abort is, but some don't like this behavior, because it allows an attacker 170 to stop an authentication in progress. The objective of the NAK message 171 is to negotiate a method (it has also been used for negotiation of a 172 sub-method within the method, but not clear it is appropriate for that), 173 but should it be used to abort the method? The NAK as an abort doesn't 174 fully describe why the abort is taking place, so perhaps an error or abort 175 message needs to be created. There is no notification message from the 176 peer to the authenticator. Sending anything in the middle of an exchange 177 could be an issue anyway from a security point of view. If you simply 178 stop responding to the exchange in the middle, it will timeout eventually 179 and another method proposal will come along. This could be NAK'd at that 180 time. 182 There seems to be consensus that NAK should only be used for 183 method negotiation. For aborting we should do something different. 184 Choices include keep it the same, timeout, new message, NAK with 185 parameter, etc. These choices need to be explored further. 187 It was noted that the method really starts with the first message 188 and the NAK is a response to the first message of the method, so reception 189 of the NAK is really just a condition of the method. However, each method 190 really needs to start out in a proposal phase where NAK is one possible 191 response. How does the mux know what is going on here? Does the mux 192 keep state, and know when the proposal phase has ended (after which NAK is 193 no longer allowed)? 195 Another topic to discuss is acknowledgements of success and 196 failure messages. This isn't possible in RFC 2284, but perhaps a new 197 message is needed? 199 Timer events in the state machines aren't described. This is 200 tricky because user input changes all the timing. 202 Another issue raised is how much constraint can we put on all EAP 203 methods? Is the EAP method state machine a black box or must it conform 204 to some more specific guidelines or some specific required states. For 205 example, is there an abstract API that describes how an EAP method 206 interacts with the mux and the EAP state machine? For example, are there 207 variables set within the method that influence behavior of the mux? For 208 example, the method might tell the mux whether authentication had 209 succeeded or failed, etc. 211 Yoshihiro Ohba's Minutes 213 EAP Design Team Tele-conference Minutes 215 Date: 11am-12pm, September 25, 2002 217 Participants: Bernard Aboba, Jari Arkko, Paul Congdon*, 218 Robert Moskowitz, Yoshihiro Ohba*+, Bryan Payne, 219 Nick Petroni, John Vollbrecht 221 *Minutes takers 222 +Minutes taker of this memo 224 (Please point out if your name is missing or you were not 225 participated in the conference call.) 227 Minutes: 229 All participants agreed on the proposed approach based on two position 230 papers, one for reviewing 802.11a (topic a) and the other for reviewing 231 the EAP state machine draft (topic b). Both position papers include 232 comparison with the RFC2284bis draft. 234 The following issues related to topic b were discussed (the issues are 235 described in a write-up posted on the EAP design team mailing list by 236 Yoshihiro Ohba): 238 o Notational conventions for state diagrams 239 o Optional identity support 240 o NAK message handling 242 a. Notational conventions for state diagrams 244 Precise definition for notational conventions is required for the 245 state machine. It was agreed that using the conventions used in the 246 IEEE 802.1X specification with allowing some augmentation is better 247 for the following reasons: 249 - 802.1X conventions are precise 251 - By using 802.1X conventions, EAP state machine 252 would be better aligned with 802.1X state machine. 254 - On the other hand, boolean variable-based event transition 255 defined in 802.1X might not be useful if we consider simplicity 256 for the state machine description. So some augmentation by 257 allowing "real-event" based state transition would be better. 259 It is pointed out that in the Authenticator SM (State Machine) there 260 are multiple entrance points from a sub-SM (i.e., Method Authenticator 261 SM) and there is a question that the sub-SM behavior may depend on 262 which entrance point is used. However, in the case of EAP, the 263 sub-state machine behavior should not depend on where the transition 264 came from, meaning that some additional convention for describing each 265 method SM (e.g., every method SM starts from a single initialization 266 state) might be necessary. 268 There is another issue on what information is available from each 269 method SM (e.g., each method SM may require Identity information). 270 This might be an issue of EAP abstract API. 272 b. Optional identity support 274 The RFC2284bis draft describes that Identity message exchange 275 is an option, but the EAP state machine is not sufficient 276 to support the option. 278 A flag variable "NeedID" is needed to indicate whether identity 279 exchange is required or not. The variable is initialized within 280 initPolicy(). It is also necessary to be able to change the value of 281 this flag in the mid of authentication (at the beginning of each 282 method) when multi-authentication is used, since some methods in a 283 multi-authentication session may require identity exchange while 284 others may not. 286 There is an open issue on whether the state for handling Identity 287 exchange should be defined in a distinct method SM or in the 288 multiplexer SMs (i.e., outside of any method SM, as described in the 289 current state machine draft). 291 c. NAK message handling 293 There is an issue on where to define the state for handling NAK 294 message. 296 A NAK message MUST NOT be used for "aborting" the current method in 297 the mid of the method and should be used for the first EAP Request 298 message of the current method only. 300 There are two approaches to achieve this: 302 - define a state for handling NAK message outside of each method SM, 303 perhaps with defining a global variable that indicates whether the 304 NAK message can be processed or not (the value of the variable can 305 be set by each method SM). 307 - define a state for handling NAK message in each method SM. 309 d. Candidate issues to be discussed in the next tele-conference: 311 o Remaining issues described in the write-up by Yoshihiro Ohba 313 o Position paper from UMD 315 o EAP multiplexer issues posted by John Vollbrecht 317 o Any discussion on topic a. 319 2.2. October 2, 2002 Minutes 321 Minutes EAP State Machine Design Team 322 ------------------------------------- 323 Date: 10/2/2002 11am-12:15 EDT 324 This week's meeting completed discussion of 325 Yoshihiro Ohba's (yohba@tari.toshiba.com) position paper on 326 the EAP state machine draft (topic b). 328 * last week we discussed issues 1,2,3, this week begin with issue 4 330 * Issue 4: Support for multiple authentication methods in a single session 332 Yoshihiro's Position: We should define policy parameters common to all 333 EAP methods that provide for multiple authentication methods. 335 Discussion: the conversation ranged over a variety of subjects 336 relating to the interaction between multiple methods, when 337 notifications should be allowed, the nature of special "protected" 338 methods, protected success and failure messages, and when success 339 and failure are valid. 341 Some key points from the discussion: 342 -- Some methods run as a protection of other methods. These 343 methods appear to the MUX as a single method, but may have 344 special requirements such as being the last method run and 345 disregarding ALL unprotected messages, including 346 Notifications. The discussion thus turned to when 347 notifications should be allowed and whether methods are 348 currently using notifications or whether these are messages 349 that should be handled at the MUX layer. The decision was made 350 to separate these issues from the current discussion. 352 * A survey would be sent to the EAP list to determine current 353 usage of notification messages 355 * Position papers would be accepted on whether or not a 356 method should be implementable such that it is only the 357 last method and, if so, how that method interacts with the 358 MUX. Some felt that it should be left to policy to disallow 359 other methods after methods like PEAP and not the method itself. 361 -- The group discussed the nature of method-specific success and 362 failure and how they interact with EAP success/failure. 364 -- The group discussed and agreed that Success messages should 365 only be sent at the end of a sequence and not after each 366 individual method succeeds. This implies that it is the MUX who 367 controls sending success messages. This issue is revisited in 368 issue 5 below. 370 -- The group discussed the role of policy in deciding method 371 order and concluded that policy can be responsible for 372 specifying method order, but that a default peer policy should be 373 defined that provides for the allowed methods to be 374 accepted in any order. There was additional discussion on 375 the implications of peer and authenticator disagreeing about 376 order since there is no synchronized schema between the two. 378 * Issue 5: Pass-through EAP authenticator state machine 380 Yoshihiro's position: Should define special state machine for 381 pass-through 383 Discussion: The conversation lead primarily down two paths- 384 (a) the differences in 1x and PPP with respect to last message 385 delivery and the necessity to generalize for media 386 independence. At this point the sending of a success message by the 387 MUX was revisited considering both the 1x and PPP case 389 (b) the nature of Identity messages including the ability for 390 either Authenticator or Auth Server to request ID, the possibility 391 for different auth servers to be used depending on the ID response, 392 and the authenticator's desire to always know auth replies for 393 accounting/audit purposes. 395 Additional discussion brought up that a number of new mediums are 396 being discussed, thereby illustrating the need for a single unified 397 protocol definition 399 Next week will continue with the remaining item b position papers. 401 2.3. October 9, 2002 Minutes 403 Minutes of the EAP state machine Design Team conference call 405 Date: October 9th, 2002, 18:00-19:00 EET 407 a. Agenda 409 - Report on 802.1aa (Bob Moskowitz) 410 - University of Maryland position paper 411 - Bernard's position paper 412 - Jari's position paper 414 b. Report on 802.1aa 416 Bob was the only one present in the 802.1aa meeting, but 417 he wasn't present in the conference call. 419 c. Jari's position paper 421 This position paper studied whether the proposed EAP state 422 machine has (message, state) pairs for which no actions have 423 been defined. Several such pairs were found. Some of these 424 pair are missing on purpose, while others are either mistakes 425 or under-specification. The paper classified the issues around 426 the following main problems: 428 - When can Failure come? 429 - When can NAK come? 430 - When can Identity Request come? 431 - When can Notification come? 432 - Should 2nd, 3rd, ... internal method requests be modeled in the 433 main state machine? 434 - Should we treat protocol errors in the 435 state machine or not? 437 o Failure: 438 - The issue is whether peer should accept Failure only after 439 a method execution, or also in the unauthenticated state 440 before any methods. 441 - DECISION: Peer should accept Failure in unauthenticated state. 442 - There was a discussion of whether such failures can be based 443 on the NAI given in an Identity Response. There are security 444 issues around exposing valid / invalid user names. It was 445 unclear whether there are similar issues in exposing domains 446 for which the authenticator is unable to perform authentication. 447 - DECISION: We should document the security considerations 448 about this, but not prevent / mandate any specific behavior. 449 - Bernard: Filters may prevent failure messages if the method 450 is protected and wants a protected failure report. Methods 451 may install such filters. 453 o NAK: 454 - We decided to talk about this in more general manner 455 in the context of protocol errors. 457 o Identity request: 458 - The issue is whether Identity Request can be NAK'd, 459 whether Identity Request can be repeated, whether it 460 can come during the execution of a method or only in between. 461 - Also, can a method ask for an identity request to be sent? 462 - Can a method get the information from an identity response? 463 - John asked whether the state machine goes through the unauthenticated 464 state as it moves from one method to another. The answer is yes. 465 - Bernard said that we should avoid having to give policy for 466 EAP nodes; this is usually a sign of a lack of specification. 468 Sequences of methods, different combinations can create problems 469 and lots of NAKking if policies dictate too much. 470 - Is identity a method? Can you NAK identity? RFC says no, and some 471 implementations are known to not be able to process such NAKs. 472 - Bernard: RFC set Identity Requests to be optional, but 802.1x made 473 it mandatory. This is a conflict. What if both sides don't want it? 474 - Bernard: Perhaps we should request 802.1x to make it optional also. 475 This may not be easily adopted by 802.1aa, however. One issue is that 476 they would like to have a solution from the IETF that works without 477 configuration. 478 - Jari: There is a danger that if we don't allow NAKs, we will soon 479 develop a convention where an empty NAI implies that the identity 480 does not exist or we don't want to give it. 481 - DECISION: Identity request/response can only appear between methods 482 - DECISION: Our preference is that identity requests be optional. (And 483 we are leaning towards making NAK disallowed.) 484 - DECISION: Work on the text on the list. 485 - DECISION: Talk with 802.1aa about the situation. 487 o Notification: 488 - DECISION: Discussion elsewhere appears to lead to allowing 489 Notification in all states. 490 - DECISION: Can not be NAK'd. 492 o 2nd, 3rd messages 493 - John: Multiplexor model will make this clearer 494 - Can we execute methods in parallel, 1st message 495 from 1st method, 1st message from 2nd method, ... 496 2nd message from the 1st method, 2nd message from 497 the 2nd method, ...? 498 - DECISION: No. Methods must be done one at a time. 499 - There must be a concept of activating and deactivating 500 a method. 501 - Bernard: Acceptance locks you to the method 502 - Jari: Do we need to model this in state machine? 503 - John: yes 505 o Protocol errors: 506 - The issue is whether the state machine should say 507 something about what to do when invalid EAP messages 508 arrive. This may be necessary for recovery etc. purposes. 509 - Bernard: There's certainly errors in individual methods. 510 - Not all protocol errors need the same treatment 511 - Bernard: Its a reasonable question to ask what to do in a protocol 512 error situation, if the spec says something is that 513 - Should silent discard be used? 514 - We should avoid making Denial-of-Service attacks too easy 515 - John would like to have positive confirmation of a failure 516 rather than stubbornly trying and timing out later 517 - Servers could send a Notification 518 - There is a usability tradeoff: failure report quickly vs better 519 Denial-of-Service resistance 520 - John: Could we send a NAK with a message? 521 - Bernard: Implementation backwards compatibility prevents NAK changes 522 - Is there a need for a new message? 523 - Jari: We have the following options to deal with 524 unexpected protocol messages: 525 1) Silent discard and wait for proper message; this often 526 leads to a timeout if the discarded message really was 527 from the authenticator. 528 2) Immediately abort everything and exit from EAP. 529 This provides a quick indication to the user, 530 but is very fragile wrt Denial-of-Service attacks. 531 3) Provide a new abort message with support for authenticating 532 that the other side really sent the offending message. 533 It is unclear how complicated this is. 534 4) A new notification message could be design for peer=>authenticator 535 direction. This would allow implementations to report problems, 536 without making the protocol very vulnerable to Denial-of-Service. 537 - DECISION: We need separate discussion on errors. 538 - Jari: I will write something about it. 540 d. Concluding remarks 541 - Other two position papers will be dealt with later. 542 - John: We've made a lot of progress lately in the issues. 543 The main remaining issues are policy issues and dealing 544 with protocol errors. 545 - Jari: We will continue with the conference calls, but probably 546 need also to do e-mail reviews of the position papers. 548 2.4. October 23, 2002 Minutes 550 Present: Bob Moskowitz, Nick Petroni, Jari Arkko, Yoshihiro Ohba, Glen 551 Zorn, John Vollbrecht, Paul Congdon, Joseph Salowey 552 Scribe: Jari Arkko 554 1. John's position paper. 556 - Was submitted, but bounced the list. 557 He started to do state tables which 558 assumes the methods can also provide 559 information to the EAP mux. Clearly needs 560 more work, but he'd be happy to pursue it. 562 - There's a couple of main things: 563 - It would be possible to map this back to the states 564 that are in the state machine now. Though it doesn't 565 make any distinction about methods, even identity 566 is seen as a method. 567 - Assumes policing. Some of the actions assume 568 that policies will dictate certain things. 569 - Starts to imply things about the API. 571 - Bernard: This is fairly complete. 572 - Bernard: There are two cases when you receive 573 method X request. One, we are done and should 574 change state. Two, we need further requests. 575 In addition, there are error situations. 577 - Bernard: If within a method, you receive 578 another method, is this NAK'd or silently 579 discarded. 580 - DECISION: NAK is better than silent discard. 582 - Question: Is a failure of a method terminal? 583 We could either terminate EAP, or allow 584 continuation with another method per policy? 585 - John thinks we should allow the latter. 586 - Jari thinks we should not. 588 - Question: is the treatment of final success 589 or fail dependent on whether the previous method 590 failed or succeeded? 591 - Proposal: We need a new state for this. 593 - Question: is there a global state, what has 594 happened on all methods, useful maybe for 595 re-authentication? How can re-authentication 596 - Answer: Good question. 598 - Jari: Why is not authenticated vs. no current 599 methods there? 600 - Jari: Reformulated question: is Success / Fail 601 illegal at the beginning? 602 - Bernard: Maybe this is policy? 603 - Jari: If we can avoid policy, we should. 605 2. Moving Forward 607 o Drafts: 609 - Bernard: I encourage John to write up this 610 state machine with this draft. 611 - Jari: Should we have an individual draft by 612 John, or merge drafts to WG draft status. 613 - DECISION: Too early now. 614 - Bernard: It would be better if Brian and Nick 615 could do another revision of their draft as well. 617 - DECISION: Priorities are: 1) follow decisions 2) be complete 3) follow 802 618 format. 619 - Jari: Need to capture current decisions. Bernard: We are tracking 620 the issues. 622 - Bernard: One of the open issues is described above 624 - Yoshihiro: We also need to consider the pass-through state machine. 625 - Jari: That can also be done as a separate draft. 627 - DECISION: By the I-D deadlines, we will have the following: 628 - 2-3 state machines 629 - rfc2248 updated to -07 630 - some solved issues 631 - many unsolved issues 632 - position papers and minutes will also be published 634 o IETF-55 and where do we go from there 636 - We will have a total of 4.5 hours and 2 slots. 637 - On the first day, state machine is important 638 and the issues are important 639 - Second day is still unclear 640 - What kind of method discussion we can have 641 is under discussion. 642 - John: Method discussion is key for EAP. 643 - Bernard: We need to try to discuss issues in the methods, 644 see if they are affected by state machine modifications etc. 645 - Process for evaluating methods. 646 Drafts solicited. Luca, Glen are writing something 647 about this. 648 - Glen: Cart is pushing the horse. Compatibility 649 with 802.1x is not so important. Bernard: Tony Jeffrey 650 views the 802 state machine as a way to shuffle 651 EAP packets around. The job of the IETF state 652 machine is to decide what to do with the packets. 653 Because the IETF state machine is link layer 654 independent, it is at a higher abstraction 655 layer. We will use similar format, but it 656 is not the intention to force this state 657 machine to comply with 802 state machine. 659 o Continue with dt meetings after initial I-D deadline? 660 - John: Not available next week. 661 - Jari: We should continue. 662 - DECISION: Meetings continue and next week we will go 663 over the open issues. 665 2.5. October 30, 2002 Minutes 667 EAP Design Team meeting, Wednesday October 30th, 2002. 668 Minutes taker: Jari Arkko 670 o Agenda 672 Discussion of unresolved EAP issues: 673 http://www.drizzle.com/~aboba/EAP/eapissues.html 675 Discussion of cryptographic binding problems: 676 http://www.drizzle.com/~aboba/EAP/draft-puthenkulam-eap-binding-01.txt 677 http://www.saunalahti.fi/~asokan/research/mitm.html 679 Latest RFC 2284bis draft: 680 http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-07.txt 682 o Issue 2: Alternative indications 684 - Should these be kept or not? 686 - Are protected success and failure a form of alternative 687 indications 689 - Can the 802.1X messages be considered alternative indications 691 - Proposal: rate of loss is low enough, not a problem. Bernard: But 692 PANA folks are expecting to run this on GPRS! 694 - Question: what is the right thing to do from a security point of 695 view? Bob: we should require a success. Jari: depends on whether 696 the indication is protected. Bernard proposes that if a protected 697 indication is available, no alternative indications should be 698 listened. 700 - Is link up and down an alternative indication? Bernard thinks its 701 a different issue. In PPP, you would get back to LCP. 703 - EAPOL logoff, is it an indication or not? What if there's link 704 layer security? Will it help? 706 - Bernard: We probably need to listen to these alternative forms of 707 failure indication. This will open a DoS attack. Jari: The 708 question is if this makes the situation any worse, there may be 709 other equivalent attacks already. 711 - Bernard: I don't like the argument but I can't argue much about 712 it. Let's look at EAPOL logoff as an example. Attacker sends 713 unencrypted EAPOL logoff messages to a multicast address. The 714 access point will have to relay those to all devices on the 715 wireless media, or even to the wired media. Debate whether peer 716 will act on this? Bernard: it doesn't matter, we can get mac 717 addresses and send unicast messages. 719 - Proposal (Bernard): Lots of ways to do these DoS attacks. Doesn't 720 seem possible to ignore these indications. 722 - Bob: we will see link ups and downs all the time anyway, we need 723 to ignore them in case the link comes back online soon. Bernard: 724 Agree. 726 - Bernard: This is like IPsec and ICMP; most implementations don't 727 believe ICMP but rather wait for an IKE timeout. 729 - Jari: the action depends on link layer, e.g. l2tp vs. physical 730 link. Bob: this should go to the link layer specific specs. 732 - DECISION Bernard & Jari: if an authenticated indication exists, 733 should not believe alternative indications (unless have to, like 734 the link really went away). In the absence of authenticated 735 indication, alternative failure indications may be accepted if the 736 lower layer specs say so. Success indication should not be 737 believed. 739 - Jari: I'm still unsure about this. What if I have successfully and 740 mutually authenticated the other side? Why would I not believe an 741 alternative success indication. Jari promises to write something 742 about this later. 744 o Issue 7: How to run multiple methods one after another 746 - Bob: What would a non-supported peer do if it get another method 747 and was expecting success or failure? Bernard: This ties to the 748 last issue. If it gets a packet it can't make any assumption about 749 the state. In Windows, authentication will time out. In a later 750 version with support, how would you know if the peer supports 751 sequences or not? Invent a new method to signal that you support 752 them or have it written in the specification that the methods 753 always support sequencing. Or negotiate? Bernard doesn't want to 754 add a round-trip for negotiation. 756 - Bernard: We also need to discuss whether the end points have to be 757 the same all the time. 759 - Questions: 1) How to do sequences? 2) how to prevent mitm attacks? 761 - Question: Could we add a continuation flag to the header in a 762 backwards compatible way? (Bernard go look at the header.) 764 - Question: Can we send a NAK? Bob: In the Windows version it just 765 sits there and can't even NAK after having executed a method. So 766 we can't rely on NAK. The same applies to a new Command. So 767 the end result is in any case a timeout. The good news is that 768 all the latency is at the end. 770 - Yoshihiro says that if this results in a failure it is not a 771 problem. This is because if the authenticator wanted to do 772 multiple methods, the authentication will fail anyway. 774 - Bernard: Can we change the identity request to specify 775 if the peer can do multiple methods? Or we could have 776 this as a part of the user data base. 778 - DECISION (Jari): Its better to take the timeout at the 779 end for the people who will fail, than spend negotiation 780 time for everyone at the beginning. 782 o Issue 10: Lack of authenticated success and failure indications 784 - Bob: Security people want to have one point where success or 785 failure is indicated. 787 - Bernard: Can we require authenticated indications in some 788 situations, such as for sequences or tunnels? Probably we can't 789 mandate it for existing clients and the basic EAP situation. 791 - Bernard: Can't have authentication until keys are generated. Bob: 792 We can always do a Chap-like request-response which authenticates 793 an indication. 795 We could have an acknowledge-accept approach, and have it 796 mandatory for some new places where EAP is used, such as 797 GPRS or PANA EAP-over-IP. 799 - Jari: One idea is that if someone supports sequences, 800 they could use a protected success -method as the last 801 one in the sequence. 803 - Question: Is it sufficient to protect tunneled 804 indications, or do we really have to support 805 also secure indications in sequences? (No opinion) 807 - DECISION: We can't put this in situations where 808 there are no sequences or tunnels. The rest of 809 the discussion has to be taken in IETF #55. 811 o Issue 13: Identifier usage not specified? 813 - Can we specify it to start from 0? It appears 814 more important to specify how it increases and 815 how ordering / duplicates are detected. 817 - Seems like the existing text is quite appropriate. 818 Does not mandate too much, but specifies enough. 820 - DECISION: Existing text is OK for #13 & #18. 822 o Issue 23: Contents of identity request payload 824 - The problem is if we have enough information in Identity Request 825 to be able to answer? In most cases we have some lower layer 826 information, such as the dialed phone number that tells you which 827 identity to use. Do we need something like this in the Identity 828 Request message? 830 - Bernard: Should the authenticator tell its NAI? Jari: Isn't this 831 a chicken and egg problem, how can the authenticator know what to 832 tell before it knows from which roaming ISP this user is from? 833 Bernard: There's methods out-of-band to EAP for knowing e.g. that 834 we clicked the AOL icon so we are looking to give AOL identity. 836 - Bob: I'm working on an extension to give a list of NAIs in the 837 identity request (or in the response). The request contents are 838 treated just as an advertisement. Bernard: This sounds good. 840 o Next meeting 842 - We will have a meeting next week (the last meeting 843 before IEEE and IETF) 845 2.6. December 11, 2002 Minutes 847 Date: Wednesday, December 11, 2002 848 Time: 8 AM PDT 849 Present: Bernard Aboba, Jari Arkko, Bob Moskowitz, John Vollbrecht, 850 Paul Congdon, Glen Zorn, ? 851 Scribe: Jari Arkko 852 1. Preliminary discussion 854 This was the first meeting after IETF 55. 856 Based on looking at the state machine drafts, they look good but not 857 all design team decisions are yet adopted in them. The two drafts 858 are being merged into one and some more issues are resolved in them 859 at the same time. 861 IEEE 802.1aa ballot may affect state machine. We encourage people to 862 read the document and comment. 864 2. Discussion of EAP issues 866 http://www.drizzle.com/~aboba/EAP/eapissues.html 868 - 43: Security properties 870 Jari: Worry about requiring proofs. Bernard: Yes, it may not be 871 desirable. DECISION: We should encourage people to include 872 references to proofs and other analysis, but not require 873 proofs. Jari to write alternative text. 875 Bernard: Is the text on dictionary attack sufficient? Glen: Does 876 not sound too good yet. Bernard: Even liveness doesn't prove 877 resistance. Glen: Last part makes sense. Jari: I would just put 878 in that the spec must describe whether you are vulnerable to 879 dictionary attacks. Glen: There is a difference between dictionary 880 attack to a weak password vs. a method. DECISION: The following 881 text can be used: Assuming 882 there is a weak password in the secret, does the method allow a 883 an attack better than brute force? John: There is a further 884 distinction between off-line and on-line attacks. DECISION: 885 Let's not describe different variants of dictionary attacks, 886 instead reference text books on the subject. 888 Key strength determination: How do we count key strength, do we 889 count clear text nonces during EAP TLS negotiation to the 890 entropy? There is some counter-intuitive input on this subject 891 from known cryptographers. It is unclear if adding a PRF 892 function will create additional entropy or not. DECISION: 893 Bernard will ask the cfrg IRTF group what a good definition of 894 key strength is, but we will not give a full definition in the 895 specification. 897 - 2 Alternative indications 899 Bernard has new text on the issue site. Question: If after 900 receiving a protected success indication within a method, do you 901 accept unprotected failure after the method has completed? 902 Bernard: The current text prevents you only from spoofing a 903 success. If the method has not completed, you will throw both 904 failure and success indications away. How all this is handled 905 must be described in the state machines. 907 Also, within a tunnel are the state machines separate or joined? 908 Bernard: We should think them as a single state 909 machine. Bernard: There are two issues here: whether the methods 910 are completed or not, and whether the methods have sent their 911 success/failure indications to the other side. 913 DECISION: If the method hasn't told the EAP mux layer that its 914 done, the failure/success indications will be thrown 915 away. Bernard: A method will just tell the mux when it is 916 done. It may not know exactly about its success, but it 917 indicates that it has completed successfully. If a method says 918 success (e.g. within PEAP) and after that an unprotected failure 919 comes, what then? Jari: It is enough with the current text and 920 protecting the success. Protecting the failure may not make 921 sense as there are other DoS attacks in any case, e.g., on the 922 methods. 924 Bernard: Is the primitive for completion just for my own 925 success, or do we indicate also the other side's success? If we 926 indicate the peer's success, then we could avoid spoofed 927 failures. Jari: However, if we are running a sequence of 928 methods, then it is no longer clear when a failure can be 929 accepted. One possible semantics is that the protected 930 indication applies only to what follows the protected method 931 immediately -- but not what happens after the method. However, 932 an attacker who can inject messages can always cause DoS by 933 sending random messages, sending only the first message of a 934 method etc. 936 DECISION: We will provide an indication from a method for both our 937 own completion as well as the peer's completion. 939 - 25: Spoofing and duplicate detection 941 This attack is like attacking TLS TCP, but easier since the 942 sequence number space is smaller in EAP. 944 Is there a difference in EAP methods as to how they want to 945 receive their messages, either letting the Mux handle the 946 sequencing or doing it by themselves using some kind of 947 integrity protection to avoid these attacks. This is analogous 948 to the TLS over TCP vs. IKE situation. 950 Should we have a primitive from the method to the mux which 951 says 'take me back to the previous sequence number'? This is 952 also related to retransmission of broken packets. DECISION: 953 We should have a primitive for tossing out messages that 954 fail integrity protection. 956 There's also a timing issue: What if the real message arrives 957 during the integrity verification? DECISION: The state machine 958 must act in a lock-step; the EAP mux will not handle any new 959 messages before the method processing has indicates that the 960 previous message has been either processed or thrown away. 962 - 41: NAK of extended types 964 This is has proven to be complicated if you mix regular and 965 extended types. Bernard proposes that we only allow one kind of 966 types in NAK.DECISION: We will allow NAK of 1 or more regular 967 types OR a NAK of one vendor. 969 2.7. December 18, 2002 Minutes 971 EAP Design Team Notes 12/18/02 Scribe: Paul Congdon 973 802.1aa discussion 975 [1] In Paul's ballot comments for 802.1aa/D4.1 he brought up some 976 issues between the interface of 802.1X and the EAP layer. There 977 have been many new checks put into the EAP layer and subsequent EAP 978 Methods that may cause silent discards or state changes the 802.1X 979 layer may need to know about. The current 802.1aa draft always 980 assumes it sends a response to every request, so this doesn't 981 support silent discards. The two machines need to be looked at 982 side-by-side to assure a proper interface exists for the expected 983 behavior. 985 [2] It was agreed to prepare a reconciliation between the two layers 986 and present at the 802.1aa interim meeting in Vancouver (1/6 - 987 1/10). Paul to send mail to Tony to request a specific time for 988 the AA meeting. John and Bernard to suggest times when they could 989 possibly attend the 802.1aa meeting to schedule this particular 990 aspect. 992 [3] Discussing the interface between media layers and EAP layers. It 993 should be simple handshakes and should avoid putting media into 994 particular modes or states if possible. Something that simply 995 acknowledges the receipt of EAP frames from the media layer. 997 EAP state machine discussions 999 [1] We need to consider EAP DoS attacks that can come from the wired 1000 side as well now that pre-auth is part of 802.11i. With Pre- 1001 authentication, an attacker can authenticate to an AP, and then 1002 attack another AP within the same ESS. This means that EAP attacks 1003 do not have to be local, as would a DoS attack on an 802.11 cipher 1004 such as TKIP. 1006 [2] In the proposed state machine if any method in a sequence fails, 1007 the authentication fails. 1009 [3] There is a question about what happens on the peer when it 1010 perceives the authentication to have failed. For example, say the 1011 authenticator failed to authenticate to the peer, or it send a 1012 protected failure indication to the peer. Does the peer have to 1013 wait until receipt of an EAP-Failure? Or can it transition to 1014 another state immediately? What if the Authenticator thinks that 1015 the method is still ongoing and keeps retransmitting? How does the 1016 Peer terminate the conversation? There is a need for the peer to 1017 be able to signal termination of the authentication. A way to know 1018 that the peer has "hung up", so to speak. This is media specific, 1019 since not all media may have this ability. For example, with PPP, 1020 an LCP-Terminate can be sent; in IEEE 802.11, you can send a 1021 Dissociate or De-authenticate. But what do you do on an Ethernet? 1022 Lower carrier? 1024 [4] Some methods may support protected success/failure indications. In 1025 such a method, the authenticator will tell the peer that 1026 authentication has failed, and perhaps the Peer can respond, 1027 ACK'ing that assessment. In this case, assuming the exchange is 1028 completed, then both sides are in synch as to the outcome. 1030 [5] Retransmissions need to be checked by the EAP layer and tossed if 1031 necessary. How will you know the frame is truly a retransmission? 1032 John: All the bits must be checked to know this and the EAP layer 1033 isn't currently doing that. You can't just check the identifier. 1034 Bernard: Do you really want to require a comparison between a 1035 received frame and previously received frames for that identifier? 1036 Wouldn't this be creating a significant amount of work that would 1037 make a DoS attack easier? Remember, the underlying media is assumed 1038 to have a CRC check -- both PPP and IEEE 802 have this. If the CRC 1039 check fails, then the EAP packet isn't even processed by the EAP 1040 layer, it is discarded. 1042 [6] One possible approach here is for the EAP layer to queue packets 1043 for the method and then pass queued Requests up to the method, one 1044 at a time. If the EAP method replies with a Response, the EAP layer 1045 should empty the queue since there should not be any additional 1046 packets in flight. If the Authenticator retransmit timer is off, it 1047 may have retransmitted earlier before receiving a Response, but 1048 that is not of concern to the Peer - clearing those packets from 1049 the queue has no ill effects. The Peer sends its Response; if a 1050 retransmission comes in after that, it can respond again; if not, 1051 it can handle the next Request. Clearing the queue is a DoS attack 1052 optimization. 1054 [7] If the EAP method didn't like the request it got (presumably 1055 because it failed an integrity check) it would tell the EAP layer 1056 "packet not accepted" and then the EAP layer will hand the next 1057 packet in the queue to the EAP method. Alternatively, the method 1058 could abort because it doesn't know how to handle integrity check 1059 failures (EAP TLS). 1061 [9] This implies that the EAP layer only does some basic checks: given 1062 the state of the method, is the Peer accepting packets other than 1063 Requests? Is the Type field acceptable? Is the length of the packet 1064 appropriate? There is no duplicate checking per se - the EAP layer 1065 just maintains a queue that is cleared after a Response is sent. 1066 This seems consistent with the behavior desired by Token Card 1067 methods. It could take a while for a person to enter in a Response 1068 - and if there is a retransmission during that time, you don't want 1069 to prompt the user again. You let them type in their Response, send 1070 it, clear the queue and then see if a retransmission occurs after 1071 that. 1073 [10] Some methods may not be able to survive an integrity check failure. 1074 For example, Yoshi pointed out that TLS cannot survive a MAC 1075 failure, so that presumably EAP TLS cannot survive this either. 1076 Bernard agreed to check on this. 1078 [11] Notification is handled differently than other methods. A 1079 Notification Request can be sent at any time, a Response is sent 1080 automatically by the EAP layer, and there is no state change 1081 resulting from this (other than perhaps Identifier state). John V 1082 was under the impression that Notification Request cannot occur in 1083 the middle of the method, but this was agreed upon in a previous 1084 Design Team meeting. In the ESTEEM draft we found the previous 1085 discussion that indicates the Notification Requests can be sent at 1086 any time and can't be NAK'd. We will stick to this decision, and 1087 John agreed to update the state machine document to reflect this. 1088 On the peer side it is fairly easy to just respond to the Notify, 1089 but on the authenticator, you must process the Notification Request 1090 like any other packet, wait for a response and retransmit as 1091 necessary, etc. 1093 [12] John would like to re-visit this issue before making the changes. 1094 Could we meet on the 27th in the early afternoon or the 30th (the 1095 following Monday). Paul will get a phone line for the 30th to 1096 close this issue unless Bernard can secure the Microsoft line. 1098 3. Position papers 1100 3.1. Issues with the EAP State Machine Paper 1102 By Yoshihiro Ohba (yohba@tari.toshiba.com) 1103 Date: September 23, 2002 1105 ------------------------------------------------- 1106 Issue 1: Need for detailed notational conventions 1107 for state diagrams. 1108 ------------------------------------------------- 1110 I think more work on the notational conventions of the current EAP 1111 State Machine is needed. For example, there is an ambiguity about the 1112 timing when the action defined in each state is executed. There are 1113 two possibilities: 1115 a) The action defined in a state is executed immediately after 1116 the state machine enters the state. 1118 b) The action defined in a state is executed immediately before 1119 the state machine leaves the state (and after testing 1120 branching conditions.) 1122 It seems that the EAP state machine document assumes case a), but 1123 it is not clear. 1125 In addition, although a state machine has a sub-state machine, it is 1126 not clear whether a sub-state machine's behavior depends on the 1127 entrance point from which the sub-state machine is entered when there 1128 are multiple entrance points. 1130 Discussion: 1132 Is it better to use the same conventions defined in section 8.5 "EAPOL 1133 state machines" of IEEE 802.1X specification (EAPOL state machines 1134 always uses case a), in which changes in boolean state variables are 1135 used as state transition events? Or is it better to use and improve the 1136 current conventions? 1138 ---------------------------------- 1139 Issue 2: Optional Identity support 1140 ---------------------------------- 1142 The current EAP Authenticator State Machine is not sufficient 1143 to support optional Identity exchange. 1145 Suggestion: 1147 a. Define a variable "needID" which is initialized within initPolicy(). 1149 b. Add a text tag "isSet(needID) to the arrow connecting 1150 "Unauthenticated" state and "Peer Identification" state. 1152 c. Add a text tag "! isSet(needID)" to the arrow connecting 1153 "Unauthenticated" state and "EAP Method Authenticator State Machine" 1154 state. 1156 ----------------------------- 1157 Issue 3: NAK message handling 1158 ----------------------------- 1160 In the current EAP Authenticator State Machine, a state transition 1161 from "Unauthenticated" state to "EAP Method Authenticator State Machine" 1162 occurs when the Authenticator receives a NAK message. 1164 Since both NAK and Identity messages are Native EAP type, it is better 1165 to have a distinct state for handling NAK reception events like the 1166 one used for handling Identity message. 1168 Suggestion: 1170 a. Remove the transition arrow connected between "Unauthenticated" 1171 state and "EAP Method Authenticator State Machine". Also remove 1172 the text tag "Rec(NAK)" associated with the arrow. 1174 b. Add a new state "NAKReceived" and connect it to other 1175 states as follows (only the related states and transitions 1176 are shown for simplicity): 1178 ------------------- Rec(NAK) ------------------- 1179 | Unauthenticated |----------------->| NAKReceived | 1180 |===================| |===================| 1181 |authMethodSucc = 0 |<-----------------| updatePolicy() | 1182 |authMethodFail = 0 |policySatisfied() | idCount = 0 | 1183 ------------------- ------------------- 1184 !policySatisfied() | 1185 | 1186 V 1187 ------------------- 1189 | Failure | 1190 |===================| 1191 | Send(Failure) | 1192 ------------------- 1194 Figure 1. A Part of EAP Authenticator State Machine 1196 ----------------------------------------------------- 1197 Issue 4: Support for multiple authentication methods 1198 in a single session 1199 ----------------------------------------------------- 1201 In order to support multiple authentication methods in a single 1202 session, it would be better to define policy parameters to support the 1203 functionality. Also, it would be better to define a primitive set of 1204 policy parameters which is common to all EAP methods. The policy 1205 parameters handling for multiple authentication methods can be included 1206 in the primitive policy set. Additional policy parameters can be 1207 defined in addition to the primitive policy set. All policy 1208 parameters including the primitive policy set are initialized when 1209 initPolicy() is called and dynamically modified when updatePolicy() is 1210 called. 1212 Suggestion: 1214 Define the following parameters for the primitive policy set: 1216 EAPMultiAuthPolicy 1218 A list of AuthPolicyElement's, where each AuthPolicyElement 1219 consists of the following entries: 1221 - EAPMethodType 1223 Contains an EAP Method Type used for the current round of 1224 authentication. 1226 - SuccessPolicy 1228 Contains a pointer to an AuthPolicyElement to be used for the next 1229 round of authentication when the current authentication round 1230 succeeds. If the value is null, the entire rounds of EAP 1231 authentication end with Success message. 1233 - FailurePolicy: 1234 Contains a pointer to an AuthPolicyElement to be used for the next 1235 round of authentication when the current authentication round 1236 fails. If the is null, the entire rounds of EAP authentication 1237 end with Failure message. 1239 CurrentAuthPolicy: 1241 Contains a pointer to the AuthPolicyElement used for the current 1242 authentication round. The pointer is updated to the value contained 1243 in either SuccessPolicy or FailurePolicy of the current 1244 authentication round, depending on the result of the current 1245 authentication round. An optimization is possible when a NAK is 1246 received with non-null Type-Data. In that case, the 1247 CurrentAuthPolicy is updated by traversing the FailurePolicy side of 1248 each AuthPolicyElement until the pointer points to an 1249 AuthPolicyElement that has an EAPMethodType listed in the Type-Data 1250 of the NAK message. 1252 Note: 1254 The following variables can also be included in the primitive policy 1255 set. 1257 idCountMax 1259 This variable is already defined in the EAP state machine document. 1261 needID 1263 A flag to indicate whether Identity exchange is needed or not (see 1264 Issue 1). 1266 ------------------------------------------------------ 1267 Issue 5: Pass-Through EAP Authenticator State Machine 1268 ------------------------------------------------------ 1270 It would be useful to define a special EAP Method Authenticator State 1271 Machine used for pass-through mode Authenticator. By defining this, 1272 the same state machine definition can be used for Authenticator and 1273 authentication server, except that authentication server will not use 1274 the "Pass-Through" Method Authenticator State Machine. 1276 The "Pass-Through" Method Authenticator State Machine is defined as 1277 follows: 1279 Variables: 1281 initialize 1282 A variable that is set to TRUE when this state machine is created. 1284 enterMethod 1286 A variable that is assumed to be set to TRUE by the Authenticator 1287 State Machine when this state machine needs to be entered. 1289 rxAuthReply 1291 A variable that is set to TRUE when an authentication reply 1292 message is received from the backend authentication server. 1294 rxAuthAccept 1296 A variable that is set to TRUE when an authentication accept 1297 message from the backend authentication server. 1299 rxAuthReject 1301 A variable that is set to TRUE when an authentication reject 1302 message is received from the backend authentication server. 1304 rxEAPResponse 1306 A variable that is set to TRUE when an EAP Response message on 1307 this EAP method is received from the Peer. 1309 error 1311 A variable that is set to TRUE when an errornous event occurs, 1312 e.g., failure to send/receive message, etc. (Timeout event is 1313 excluded based on the convention described in the Introduction 1314 section of the state machine draft.) 1316 Procedures: 1318 txAuthRequest 1320 send an authentication request message to the backend 1321 authentication server. 1323 txEAPRequest 1325 send an EAP Request message on this EAP method to the Peer. 1327 States: 1329 INITIALIZED 1330 This state is entered when this state machine is created 1331 or the method-specific authentication ends. 1333 AUTH_REQUEST_SENT 1335 This state is entered when the Authenticator sent an 1336 authentication request to the backend authentication server and 1337 is waiting a response from the authentication server. 1339 EAP_REQUEST_SENT 1341 This state is entered when the Authenticator sent an 1342 EAP Request message on this authentication method 1343 to the Peer and is waiting an EAP Response message 1344 from the authentication server. 1346 SUCCESS 1348 This state is entered when the Authenticator receives 1349 an authentication accept message from the backend authentication 1350 server. 1352 FAILURE 1354 This state is entered when the Authenticator receives 1355 an authentication reject message from the backend authentication 1356 server. 1358 | 1359 | initialize 1360 v 1361 --------------------- 1362 UCT | INITIALIZED | UCT 1363 +---------------->|=====================|<------------+ 1364 | | | | 1365 | --------------------- | 1366 | | | 1367 | | enterMethod | 1368 | v | 1369 | -------------------- rxAuthReject | 1370 | rxAuthAccept | AUTH_REQUEST_SENT | || error | 1371 | +----------|====================|-------+ | 1372 | | | txAuthRequest | | | 1373 | | -------------------- | | 1374 | | ^ | | | 1375 | | | |rxAuthReply | | 1376 | v | | v | 1378 ---------------------- | | --------------------- 1379 | SUCCESS | | | | FAILURE | 1380 |======================| | | |=====================| 1381 | authMethodSucc = 1 | | | | authMethodFail = 1 | 1382 ---------------------- | | --------------------- 1383 | | ^ 1384 rxEAPResponse | v | 1385 ------------------------- | 1386 | EAP_REQUEST_SENT | | 1387 |=========================|-------+ 1388 | txEAPRequest | error 1389 ------------------------- 1391 Figure 2. Pass-Through Method Authenticator State Machine 1393 Note: 1395 This diagram uses the notation conventions follows the ones used for 1396 the EAPOL state machines. 1398 3.2. Comparison of EAP state machines with RFC 2284bis 1400 Authors: 1401 Bryan D. Payne (bdpayne@cs.umd.edu) 1402 Nick L. Petroni, Jr. (npetroni@cs.umd.edu) 1404 Date: 1405 22 September 2002 1407 References: 1408 EAP State Machine Draft 1409 http://www.ietf.org/internet-drafts/draft-payne-eap-sm-00.txt 1411 RFC 2284bis 1412 http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-06.txt 1414 ---------------------------------------- 1416 INTRODUCTION 1418 This paper outlines inconsistencies between the EAP state machine draft and 1419 the most recent revision of the EAP RFC. Suggestions are made for 1420 correcting any issues that are presented. In addition to inconsistencies, 1421 some typographic corrections and clarifications for the state machine draft 1422 are presented at the end of this paper. 1424 INCONSISTENCIES 1425 Below is a listing of the current known inconsistencies between the state 1426 machine draft and the EAP RFC: 1428 Issue #1: The authenticator state machine is too restrictive in how an ID 1429 request may be used. Specifically, the state machines require each ID 1430 request to be followed by an Auth request, while the EAP RFC does not 1431 make this restriction. 1433 Resolution #1: The authenticator state machine should be updated to 1434 transition from the Peer Identification state to the Unauthenticated 1435 state, instead of directly sending an Auth request. 1437 Issue #2: The authenticator state machine does not provide any 1438 compatibility with RFC 2869bis. Specifically, there is no transition 1439 from the authenticator's unauthenticated state directly to the success 1440 and failure states due to receipt of a message from the back-end server. 1442 Resolution #2: We do not propose a resolution for this issue at this time 1443 due to the complexity of the issues involved. However, we would like to 1444 leave this idea open to discussion. 1446 Issue #3: The peer and authenticator state machines do not depict the 1447 re-authentication scenario. Instead, the state machines have a "dead 1448 end" at the authenticated states. 1450 Resolution #3: Create a state transition from authenticated to 1451 initialization in both the peer and authenticator state machines. 1452 Indicate that this transition is to be used for re-authentication. 1454 Issue #4: The state machine draft provides incorrect information 1455 regarding retransmission of messages (see Introduction, paragraph 4) 1457 Resolution #4: Reword the discussion of retransmissions to indicate that 1458 the peer will never retransmit messages. In addition, note that the 1459 authenticator is allowed to retransmit up to a pre-specified number of 1460 times. Finally, note that both the peer and authenticator must return 1461 to the initialization state after "timing out" in any other state. Note 1462 that the definition of a time out is not provided in the EAP RFC. 1463 Therefore, this is implementation dependent, but should be a predefined 1464 amount of time with no activity. 1466 Note that this is independent of the situation where the authenticator 1467 is permitted to retransmit messages after receiving invalid ID replies. 1468 Also, note that the authenticator must never retransmit a success or 1469 failure message, per the RFC. 1471 CLARIFICATIONS & TYPOGRAPHICAL CORRECTIONS 1472 Below is a listing of topics that are viewed as correct in the current 1473 state machine draft, but that require additional clarification in the 1474 text of the draft to alleviate confusion or require a simple typographical 1475 correction. 1477 Clarification #1: The state machines implicitly support the concept of a 1478 silent discard of the SUCCESS message. This is because the peer will not 1479 transition into an authenticated state unless its policy is satisfied and 1480 because messages that arrive at the peer, but are not handled by the 1481 current state must be dropped (see Introduction, paragraph 2). 1483 While this support is present, it should be made more explicit due to the 1484 importance of the concept. 1486 Clarification #2: In the peer state machine diagram, the lower arrow 1487 between the Peer Identification and the Unauthenticated states is 1488 pointing in the wrong direction. 1490 Clarification #3: The definition of the authMethodSuccess variable in 1491 the peer state machine should be made more clear. 1493 PROTOCOL LIMITATIONS 1495 In the course of reviewing the state machine work, we were reminded of a 1496 protocol issue with EAP that should be understood by all. Unfortunately, 1497 this is not something that can be resolved by the state machine, so we only 1498 present it here for completeness. 1500 The idea of doing a silent discard of success messages on the peer results 1501 in a bit of a problem. For example, let's say that the authenticator sends 1502 a success message, but the peer isn't ready to declare success. The 1503 authenticator will consider itself to be done, while the peer will have 1504 discarded the success message. Now what happens? The peer has no power 1505 (per the protocol) to send a request message...it must instead just wait 1506 for the authenticator to send one. So the peer has no way of indicating 1507 that it is unhappy with the situation. 1509 There is a variable (authMethodSuccess) in the peer state machine to 1510 address this, but it is not an actual solution. It simply allows the peer to 1511 re-init if it isn't happy with the result of the auth method. However, 1512 since there is no way for the peer to tell the authenticator that it is 1513 unhappy, this could still leave the authenticator and the peer believing 1514 that the protocol has had different outcomes. This problem is touched on in 1515 EAP issue 10 ([1]). 1517 Currently, we do not see any resolution to this problem. However, people 1518 should be aware that it exists. 1520 SUMMARY 1522 We have made several recommendations for corrections and clarifications 1523 to the state machine draft. We now encourage peer review of this work 1524 and are open to comments. 1526 REFERENCES 1527 [1] http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2010 1529 3.3. Completeness review 1531 EAP State Machine Completeness 1532 Position Paper, Oct 1, 2002 1533 Jari Arkko, Ericsson Research NomadicLab 1535 A. INTRODUCTION 1537 The completeness of the state machine from draft-payne-eap-sm-00.txt 1538 was analyzed. By completeness, we mean that the state machine contains 1539 a description of what to do for all possible events in all states. 1541 Note that in some cases we may well ignore an event, but this 1542 should be done on purpose and we should document it clearly. 1543 If not, we often tend to forget some events that should have 1544 been handled with something else than silent discard. We 1545 have already debated a number of issues which are specific 1546 examples of the current under-specification that the original 1547 RFCs as well as the state machine proposals have, such as 1548 when can NAKs come. 1550 B. EVENTS 1552 The events that can come to a peer are: 1554 - ID Request 1555 - Method Request (many types and subtypes) 1556 - Notification 1557 - Success 1558 - Failure 1559 - Protocol error (i.e. anything else, such as a NAK 1560 sent to the client -- this could be debatable 1561 whether we need to deal with this. But some 1562 protocols make a state transition e.g. close 1563 connection upon getting these.) 1565 The events that can come to an authenticator are: 1567 - ID response 1568 - Methods response 1569 - Notification ack 1570 - NAK 1571 - Protocol error 1573 C. PEER STATE MACHINE 1575 Some states in this state machine are just temporary transitions, 1576 such as the peer identification state, where we simply respond 1577 with an identity response and return back to unauthenticated state: 1579 - Initialized 1580 - Peer identification 1581 - Invalid request 1582 - Authenticated 1584 The states on which some waiting of events occur are as follows: 1586 - Unauthenticated 1587 - Method state machine 1589 We will study these two states in detail. We note that the Unauthenticated 1590 state does not handle the Failure, Notification, or protocol error events. 1592 The method state machine state does not handle Identity request, Method 1593 request (perhaps this is thought to be on a lower level at the specific 1594 method state machine), Notification, and protocol error events. 1596 D. AUTHENTICATOR STATE MACHINE 1598 Again, the states which aren't real states in the usual definition 1599 of the term are: 1601 - Initialization 1602 - Failure 1603 - Authenticated 1605 The real states which we will study are: 1607 - Unauthenticated 1608 - Peer identification 1609 - Method state machine 1611 The Unauthenticated state does not handle Notification Response, 1612 NAK, and protocol error events (we suspect the right action 1613 in these cases would be silent discard). 1615 The Peer identification state does not handle 1616 Method response, NAK, Notification, or protocol error 1617 events. Note that we have already discussed the situation 1618 where NAK might be used to signal that we don't want to 1619 give an identity. 1621 The Method state machine state does not handle Notification response, 1622 Identity response, or protocol error events. It also doesn't 1623 really handle Method response event, but again we suspect this 1624 was expected to be done at the lower layer, in the specific 1625 method state machine. 1627 E. FURTHER WORK 1629 It is necessary to ensure that the state machines are complete and 1630 we have knowingly decided to ignore the events that currently are 1631 ignored. We have already begun to debate some of the individual 1632 issues around this, such as when can NAKs come. 1634 In the above analysis, we have not yet taken a final stand 1635 on whether the right action in some of these cases is something 1636 else than silent discard. If the right action is silent discard, 1637 then everything is currently OK. 1639 It is also necessary to take a similar look at the 802.1aa D3 1640 state machines. 1642 3.4. When can packets be sent? 1644 Bernard Aboba 1645 Date: 10/2/02 1647 When can a NAK be sent? 1649 The authenticator proposes a method. The peer can accept the proposal (by 1650 replying with an EAP method of the same type), or NAK the proposal. Once 1651 the proposal is accepted, a NAK cannot be sent by the peer until a new 1652 method has been proposed. NAKs are never sent by the authenticator, nor 1653 are they sent by the peer in response to a method whose proposal has 1654 already been accepted. 1656 When can a Notification be sent? 1658 EAP Notification is *not* an error message, and so sending or receiving 1659 Notification Request/Responses does not change the state of the peer or 1660 authenticator. The peer MUST send a Notification Response to a 1661 Notification Request sent by the authenticator. 1663 An EAP Notification Request may be sent at the behest of an EAP method 1664 running on the Authenticator, as part of the method. This implies that a 1665 Notification Request may only be sent after a method has been proposed 1666 by the authenticator and accepted by the peer. 1668 Use of EAP Notification messages MUST be described as part of the method 1669 specification. Since the EAP Response does not contain any data, and no state changes 1670 result from receipt of a Notification message, it should not be assumed that the 1671 Notification Request message is processed by the EAP method on the peer; the 1672 Notification Response is sent automatically. 1674 When can an Identity Request be sent and accepted? 1676 The rules for sending an Identity Request are the same as with any other 1677 method. An Identity Request may be sent multiple times within a single EAP 1678 conversation, as is the case for any other method. 1680 When are Success or Failure message sent? 1682 EAP Success or Failure messages are sent by the authenticator EAP 1683 layer. When it completes, an EAP method indicates the result of the 1684 authentication to the EAP layer, by setting the Result=Success or Failure. 1685 If the method is the last in a sequence of methods, then the authenticator 1686 EAP layer will send the corresponding EAP Success or Failure message to the 1687 peer. If the method is not the final in the sequence, then the 1688 authenticator EAP layer will propose another EAP method to the peer. 1690 Note that in order for a method to be usable within a sequence of methods, 1691 the final message sent within the method (prior to transmission of an EAP 1692 Failure or Success) MUST be an EAP Response. Otherwise, since EAP is an 1693 ACK/NAK protocol, there would be no way for the authenticator to send an 1694 EAP Request proposing another method. 1696 When can a Success or Failure message be accepted? 1698 EAP methods may include their own (protected) success and failure 1699 indications. Since EAP does not provide support for error messages, several methods 1700 have implemented method-specific error message capabilities. For example, 1701 TLS-based methods utilize TLS alerts, which are protected within the TLS channel, 1702 in order to transmit error messages. 1704 Similarly, methods also implement method-specific success indications. For 1705 example, a method supporting mutual authentication will expect the 1706 authenticator to complete authentication prior to completion of the method. 1708 As a result, a method specification may indicate that the method only 1709 expects to receive clear text EAP Failure and Success messages under 1710 certain conditions. For example, a clear text Success message is only expected 1711 once mutual authentication has been completed, or a clear text Failure 1712 message is only expected after receipt of a protected failure 1713 indication such as a TLS alert. 1715 These directives can be indicated via a filter interface between the 1716 method and the EAP layer. An EAP method can install a filter in the EAP 1717 layer, requesting it to discard EAP packets not meeting the filter 1718 criteria prior to completion of the EAP method. The operation of the filter 1719 MUST be described in detail within the EAP method specification, to enable 1720 interoperability. Filters installed by methods are automatically removed 1721 once the method completes. 1723 For example, an EAP method can negotiate a key early on, and after that, 1724 may want to require that all EAP packets be protected using the derived 1725 key until a protected success/failure indication is received. To achieve 1726 this, the method on the peer may install the following filter within the 1727 EAP layer: 1729 (1) ACCEPT: Code = Request, Type=MyMethod 1730 (2) DENY: all 1732 This will cause the peer EAP layer to silently discard messages of types 1733 Identity, Notification, Success and Failure until the filter is removed or 1734 the method completes. Once a protected Success indication is received 1735 (e.g. the authenticator completes mutual authentication), the filter list 1736 can be changed to: 1738 (1) ACCEPT: Code = Request, Type=MyMethod 1739 (2) ACCEPT: Code = Success 1740 (3) DENY: all 1742 Similarly, once a protected failure message is received, a filter can be 1743 plumbed enabling the reception of an EAP Failure: 1745 (1) ACCEPT: Code = Request, Type=MyMethod 1746 (2) ACCEPT: Code = Failure 1747 (3) DENY: all 1749 3.5. EAP method layer primitives 1751 Communication between the Method and EAP layer 1752 Bernard Aboba 1753 October 15, 2002 1755 One of the major issues that has arisen in the EAP Design Team discussion 1756 is the communication that occurs between EAP methods and the EAP layer, 1757 and what this enables. 1759 Find below a strawman diagram of the EAP stack: 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 | | | | | | | | 1763 | EAP method| EAP method| Native | | EAP method| EAP method| Native | 1764 | Type = X | Type = Y | Methods | | Type = X | Type = Y | Methods | 1765 | | | (MD5) | | | | (MD5) | 1766 | ! | | | | ^ | | | 1767 | ! | | | | ! | | | 1768 +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 | ! | | ! | 1770 | ! EAP | | ! EAP | 1771 | (NAK, ! Success,Failure,Notif.,Id) | | (NAK, ! Success,Failure,Notif.,Id) | 1772 | ! | | ! | 1773 +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 | ! | | ! | 1775 | ! Link Layer | | ! Link Layer | 1776 | ! | | ! | 1777 +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 ! ! 1779 ! ! 1780 +----------------------->----------------+ 1782 As discussed in earlier conversations, methods require the following primitives: 1784 a. EAP-Method.GET_IDENTITY (Peer and Authenticator) 1786 Obtains access to the EAP Identity Response(s) that were sent prior to 1787 method invocation, if one is available. This is important so that the method 1788 can know the identity in cases where it does not itself have a method-specific 1789 identity exchange. 1791 b. EAP-Method.SEND_IDENTITY (Authenticator) 1793 This primitive requests that the EAP layer send an Identity Request to the 1794 peer. This is important so that the Authenticator can obtain the Identity if 1795 it has not already been requested. 1797 c. EAP-Method.COMPLETE (Authenticator and Peer) 1799 This primitive indicates to the EAP layer that the method considers itself to have 1800 completed EAP authentication, and if so, the result. This is important so that the 1801 EAP layer can know whether it is appropriate to accept or discard illegal messages. 1802 This includes Identity, NAK, Success or Failure messages sent in the middle of an 1803 EAP conversation, or messages of another EAP Type. The EAP-Method.COMPLETE primitive 1804 also results in the removal of filters installed by the EAP method, if any. 1806 d. EAP-Method.REQUEST_KEYS (Authenticator and Peer) 1808 This primitive requests that the EAP layer provide the method with the keys 1809 derived by previous methods in the EAP conversation. This is important to enable 1810 cryptographic binding between methods in a sequence of methods or within a tunnel. 1811 This enables the endpoints to know that the entity in 1812 method #N is the same one that they were talking to in method #i where i=1,N-1. For 1813 example, if method #1 derives a key, then method #2 should demonstrate mutual knowledge 1814 of this key, in addition to deriving its own key, which subsequent methods can utilize 1815 to prove their binding. Without this binding, EAP tunneling or sequences of EAP methods is 1816 subject to man-in-the-middle attack. 1818 e. EAP-Method.PROVIDE_KEYS (Authenticator, Peer) 1820 This primitive provides keying material from the EAP method to the EAP layer. 1821 This is needed in order to allow the AAA server to communicate keying material to 1822 the NAS device. 1824 f. EAP-Method.INSTALL_FILTER (Authenticator, Peer) 1826 This primitive requests that the EAP layer install a filter. 1827 This allows the EAP layer to reject additional packets in addition to the built-in 1828 filters. For example, the method could choose to reject notification messages 1829 while it is running, even though these don't change the state. 1831 g. EAP-Method.REMOVE_FILTER (Authenticator, Peer) 1833 This primitive requests that the EAP layer remove a filter. This allows the filter 1834 to be removed prior to completion of the EAP method. EAP filters are always removed 1835 on completion. 1837 h. EAP-Method.SEND_PACKET (Authenticator, Peer) 1839 This primitive requests that the EAP layer send an EAP packet. 1841 i. EAP-Method.RECEIVE_PACKET (Authenticator, Peer) 1843 This primitive requests that the EAP method receive an EAP packet from the EAP layer. 1845 j. EAP-Method.SEND_NOTIFICATION (Authenticator) 1847 This primitive requests that the EAP layer send a Notification request. 1849 3.6. EAP State Machine Position paper 1851 The following is my proposal for changes to the state machine to support 1852 enhanced protection against DOS attacks. 1854 State Machine changes 1856 This note describes changes to the Peer state machine. The major intent 1857 is to protect it from a attacks that send EAP messages with the intent 1858 of creating an sequencing error. If this approach seems reasonable I 1859 can make corresponding changes to the authenticator state machine. 1861 As a simplification of my earlier state machine I have also changed the 1862 state machine to assume that a method failure terminates the EAP 1863 exchange. Methods may sequence, and selection of the sequence may be 1864 negotiated with NAKs of requests, but once a method is negotiated it 1865 must succeed or the sequence fails and stops. Note: This puts a burden 1866 on EAP method implementers: a failure noted by the peer must be 1867 communicated to the authenticator, and the authenticator method must 1868 also signal failure. 1870 The state machine assumes that the peer EAP Switch gets inputs from the 1871 remote Authenticator EAP Switch in the form of EAP 1872 Requests/Success/Failure messages. It gets inputs from EAP methods via 1873 an API which allows the method to pass EAP response and a signal about 1874 the state of the method. 1876 As of the conversation at the last 12/11/2002 EAP Design Team call, my 1877 understanding is that it is worthwhile to expect additional information 1878 from the method. The method will provide the following signals 1879 (including 2 new signals as noted) to the the EAP Switch when finished 1880 processing a Request. 1882 1. Continuing - Method expects additional requests in order to 1883 successfully complete 1885 2. Integrity-Check-Failure - Method did not recognize the Request. Treat 1886 as a NoOp [new] 1888 2. Done - Method is done. It does not expect more Requests for this 1889 method 1891 2.1 Method accepts authenticator 1892 2.2 Method fails authenticator 1893 2.3 Method accepts authenticator and authenticator accepts peer [new] 1895 The reason for adding 2.3 is to encourage writing methods where each end 1896 knows that it is accepted by the other without having to send an EAP 1897 Success. The method can do this in a protected way, and if it does the 1898 information can be used to protect against DOS attacks. In the 1899 following state machine if a method signals the mutual acceptance (2.3) 1900 then it will not accept an EAP fail, and on timeout it assumes that the 1901 EAP success was lost in transit and acts accordingly. 1903 Each of the signals noted above can be supported by a different state 1904 and each of the states has a set of "expected" messages and silently 1905 discards unexpected messages. This means that an unexpected request 1906 would be discarded rather than NAK'd. This is safer from DOS point of 1907 view, but perhaps less desirable if one wants a "positive indication of 1908 failure" in operation. 1910 Retransmissions 1912 In addition to the new signals we discussed dealing with retransmissions 1913 in the presence of attacks that insert random EAP requests. Note that 1914 the Peer does not retransmit, it has to sort out retransmitted requests 1915 from original or bogus requests. It's timer signal means it has waited 1916 for as long as it thinks reasonable for the authenticator to retry. 1918 In what follows I assume that the EAP Switch will catch the "obvious" 1919 retransmissions. That is it will track the current method/seq and not 1920 present it twice. Since EAP is a REQ/REPL protocol it needs to be track 1921 that the req it just received is not a duplicate of one just processed. 1922 I assume this is done by the EAP Switch prior to passing it to the state 1923 machine. 1925 Messages which seem valid to the EAP Switch may not seem valid to the 1926 method itself. The method is the authority and should do integrity 1927 checks on incoming messages. If a message fails an integrity check then 1928 the method signals this failure to the Switch and the Switch treats this 1929 as a no-op. This is actually a problem because no-op means that the 1930 Switch must keep not only its current state but its previous state. 1931 Getting an integrity check message causes it to go back to the previous 1932 state. 1934 Paul Congdon has suggested an alternative to the method proposed here. 1935 As I understand it, his suggestion is to leave all the handling of 1936 retransmissions to the method. This is an interesting approach and 1937 worth considering. The problem I see with it is that the method can be 1938 done and still have to deal with follow on messages. However, since the 1939 method must make this check anyway, it does not seem unreasonable to 1940 have it also deal with the how retransmissions. I have not worked out 1941 how this would work in this state machine, but it does not seem an 1942 insuperable problem - it is worth more discussion to work out which way 1943 is better. 1945 To tie this all together, the following is a revised description of the 1946 Peer EAP Switch State Machine, section 5 in the draft/internet-draft 1947 emailed to the group before the last IETF meeting. 1949 Peer EAP State Machine 1950 Peer EAP States 1952 The peer EAP switch has the following states: 1954 1.inactive/not authenticated - waiting for an EAP request 1955 2.active/waiting-method1 - waiting for 1st method response 1956 3.active/waiting-methodc - waiting for ongoing method resp 1957 4.active/method=x - waiting for next EAP request 1958 5.active/method-ok - waiting for method/Success/Fail 1959 6.active/method-succeeds - waiting for method/Success 1960 7.active/failed method - waiting for EAP Fail 1961 8.inactive/authenticated - authenticated; reauth possible 1963 The typical sequence for a successful authentication is as follows. The 1964 Peer receives an EAP request from the Authenticator, going to state 2 1965 and forwarding the request to the appropriate method. It receives a 1966 response from the method, going to state 4 and sending the EAP response 1967 to the Authenticator. It receives the next EAP Req from the 1968 Authenticator and goes to state 3, forwarding the Req to the method. It 1969 receives a "final" response from the method and goes to state 5 (or 6) 1970 and sends the Response to the authenticator. It then receives an EAP 1971 Success from the authenticator and goes to state 8, authenticated. 1973 Peer EAP Events 1975 Events recognized by the peer EAP switch are listed below. Some Switch 1976 policy is implied in the events; e.g. EAP-Req/ok implies that the policy 1977 evaluated the Req as ok at this point. 1979 >From Authenticator 1981 1. EAP-req/meth=x - EAP req for method x 1982 2. EAP-req/notok - req for method not allowed by policy 1983 3. EAP Success 1984 4. EAP- Fail 1986 >From Method 1988 5. Method-resp.done.ok - peer accepts authenticator 1989 6. Method-resp.done.scs - peer and authenticator mutually ok 1990 7. Method-resp.done.fai - failure termination from method 1991 8. Method-resp-cont - continuing response from method 1992 9. Method-resp-IC - Integrity Check failed 1994 Other 1995 10. Timeout 1997 Peer EAP Actions 1998 Actions initiated by the peer EAP layer are: 2000 To Authenticator 2002 1. Send EAP-NAK 2003 2. Send EAP-Resp 2005 To Method 2007 3. Forward EAP-req to method 2008 4. Send method terminate to method 2010 To System 2012 5. Signal accept or reject to system 2014 Other 2016 6. Silent Discard 2018 EAP Peer State Table 2020 State Event Next State Action Action2 2022 inactv/unauth EAP-rq/meth=x actv/wtng-mth1 EAP-rq to mth 2023 EAP-rq/notok not-actv/auth snd NAK 2024 EAP-Scess/ok inactv/auth Signal - acpt 2025 EAP-Scess/notok not-actv/auth Signal-rej 2027 actv/wtng-mth1 mth-rsp.done.ok actv/no mth snd EAP rsp 2028 mth-rsp.done.fail actv/failed-mth snd EAP rsp 2029 mth-rsp.done.sccs actv/sccs-mth snd EAP rsp 2030 mth-rsp-cont actv/mth=x snd EAP rsp 2031 mth-rsp-IC prev-state 2032 tmout not-actv/auth term to mth=x 2033 * actv/wtng-mth silent discard 2035 actv/wtng-mthc mth-rsp.done.ok actv/no mth snd EAP rsp 2036 mth-rsp.done.fail actv/failed-mth snd EAP rsp 2037 mth-rsp.done.sccs actv/sccs-mth snd EAP rsp 2038 mth-rsp-cont actv/mth=x snd EAP rsp 2039 mth-rsp-IC prev-state 2040 tmout not-actv/auth term to mth=x 2041 * actv/wtng-mth silent discard 2043 actv/mth=x EAP-rq/mth=x actv/wtng-mth EAP-rq to mth 2044 EAP-rq/not mth=x actv/mth=x Silent Discard 2045 EAP-Scess actv/mth=x Silent Discard 2046 EAP-Fail actv/mth=x Silent Discard 2047 tmout inactv/unauth Signal-rej term-mth 2048 * actv/mth=x silent discard 2050 actv/mth-ok EAP-rq/meth=x actv/mth-ok Silent Discard 2051 EAP-rq/notok actv/mth-ok Silent Discard 2052 EAP-Scess inactv/auth Signal - acpt 2053 EAP-Fail inactv/unauth Signal-rej 2054 tmout inactv/unauth Signal-rej 2055 * actv/no mth Silent Discard 2057 actv/sccs-mth EAP-rq/meth=y actv/wtg-mth1 EAP-rq to mth 2058 EAP-rq/notok actv/mth-ok snd NAK 2059 EAP-Scess inactv/auth Signal - acpt 2060 EAP-Fail inactv/unauth Silent Discard 2061 tmout inactv/auth Signal-acpt 2062 * actv/no mth Silent Discard 2064 actv/fail-mth EAP-rq/mth=x actv/failed-mth snd NAK 2065 EAP-rq/notok actv/failed-mth snd NAK 2066 EAP-Fail not-actv/auth Signal-rej 2067 EAP-Scess actv/fail-mth Silent discard 2068 tmout inactv/auth Signal-rej 2069 * actv/failed-mth silent discard 2071 inactv/auth EAP-rq/ok actv/mth=x EAP-rq to mth 2072 EAP-rq/notok inactv/auth snd NAK 2073 * inactv/auth silent discard 2075 4. Surveys 2077 4.1. NAK Survey 2079 Date: Sun, 6 Oct 2002 02:37:28 -0700 (PDT) 2080 From: Bernard Aboba 2081 To: eap@frascone.com 2082 Subject: NAK survey 2084 During the last EAP design team meeting, there were also questions about 2085 the NAK Type (see issues #35 and 36). 2087 Please answer the following questions relating to the operation of your 2088 implementation: 2090 a. May the NAK be sent by the peer in response to any EAP request? For 2091 example, may it be sent in the middle of an EAP method? OR 2092 b. May the NAK be sent by the peer only in response to a method proposal 2093 (e.g. the first EAP Request for a given Type)? 2095 c. Does your implementation tolerate sending more than one Type within a 2096 NAK (e.g. may not recognize additional Types, but doesn't blow up)? 2098 d. Does your implementation permit a NAK to be sent in response to an 2099 Identity Request? If so, what does it do if a NAK is sent? 2101 Date: Mon, 7 Oct 2002 07:13:34 -0400 2102 From: James Carlson 2103 To: Bernard Aboba 2104 Cc: eap@frascone.com 2105 Subject: Re: [eap] NAK survey 2107 Bernard Aboba writes: 2108 > During the last EAP design team meeting, there were also questions about 2109 > the NAK Type (see issues #35 and 36). 2110 > 2111 > Please answer the following questions relating to the operation of your 2112 > implementation: 2114 ftp://playground.sun.com/pub/eap/index.html 2116 > a. May the NAK be sent by the peer in response to any EAP request? For 2117 > example, may it be sent in the middle of an EAP method? OR 2119 Yes, it can be sent at any time. 2121 > b. May the NAK be sent by the peer only in response to a method proposal 2122 > (e.g. the first EAP Request for a given Type)? 2124 No, at any time. I don't see how it could be otherwise -- for a 2125 multi-stage method, it's entirely possible to get part way down an 2126 authentication attempt only to discover that some required feature is 2127 missing in the peer and that some other mechanism is necessary. 2129 > c. Does your implementation tolerate sending more than one Type within a 2130 > NAK (e.g. may not recognize additional Types, but doesn't blow up)? 2132 It ignores any additional Types included in a NAK and uses only the 2133 first one. (If *no* suggested Type is included with the message, then 2134 it logs this fact, and treats it as a failure of the current message.) 2136 No, it doesn't "blow up," even though including multiple Types (or any 2137 other data) would be a violation of RFC 2284. ;-} 2139 > d. Does your implementation permit a NAK to be sent in response to an 2140 > Identity Request? If so, what does it do if a NAK is sent? 2142 If the identity of the peer was supplied by explicit configuration, 2143 then it accepts the NAK and continues with authentication using the 2144 suggested Type (if permitted). 2146 If the identity was not supplied by explicit configuration, then it 2147 treats this case as authentication failure, sends EAP Failure, and 2148 shuts down the link. 2150 There's one other case that your survey didn't cover (perhaps it's not 2151 a bone of contention?): what do you do when you get a NAK Type that 2152 isn't one that you want to deal with (either by administrative 2153 configuration or because you don't recognize it)? I examine my 2154 current state and ask for the "next" possible method on the list, 2155 returning to Identify if I fall off the end. 2157 -- 2158 James Carlson, Solaris Networking 2159 SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 2160 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 2162 Date: Mon, 7 Oct 2002 10:22:28 -0700 2163 From: Sachin Sheth 2164 To: aboba@internaut.com 2165 Subject: RE: NAK survey (fwd) 2167 a. May the NAK be sent by the peer in response to any EAP request? For 2168 example, may it be sent in the middle of an EAP method? OR 2170 EAP will send out only in the first packet after the EAP-Resp/Id. It 2171 will not be sent out at any other time. 2173 b. May the NAK be sent by the peer only in response to a method proposal 2174 (e.g. the first EAP Request for a given Type)? 2176 Yes 2178 c. Does your implementation tolerate sending more than one Type within a 2179 NAK (e.g. may not recognize additional Types, but doesn't blow up)? 2181 There is no way to program this. EAP will only send out one EAP-type 2182 in the NAK packet. 2184 d. Does your implementation permit a NAK to be sent in response to an 2185 Identity Request? If so, what does it do if a NAK is sent? 2186 The NAK is sent out only after the EAP-Req/Identity is sent out. 2188 Date: Mon, 7 Oct 2002 14:12:42 -0400 2189 From: James Carlson 2190 To: Bernard Aboba 2191 Cc: eap@frascone.com 2192 Subject: Re: [eap] RE: NAK survey 2194 Bernard Aboba writes: 2195 > For what it's worth, here's what Microsoft Windows XP does: 2196 > 2197 > a. May the NAK be sent by the peer in response to any EAP request? For 2198 > example, may it be sent in the middle of an EAP method? OR 2199 > 2200 > Windows XP peer will send a NAK only for the first packet after the 2201 > EAP-Response/Identity is sent. It does not NAK an EAP-Request/Identity. 2203 Interesting question here: was the question above about what you'd 2204 *accept* or about what you'd possibly *send*? 2206 It looks like I read the question as the former (because "sent by the 2207 peer" implies "received by the local system" to me), and you might 2208 have read it as the latter. If it's intended as the latter, then I'd 2209 say this: I never send NAK in response to an Identity message, but I 2210 *do* send NAK in response to *any* message that is malformed for the 2211 method in use. In other words, if the method specifies a 16 octet 2212 message for the given message subtype, and you send me fewer than 16 2213 octets, then I assume that you're running some new or different 2214 version of the protocol, and I send NAK to suggest a different 2215 authentication protocol since we're not going to converge. 2217 -- 2218 James Carlson, Solaris Networking 2219 SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 2220 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 2222 4.2. Notification Survey 2224 Based on the survey results (see below), we propose the 2225 following conclusions. Comments welcome. 2227 a. EAP Notification Requests may be sent at any time by the authenticator. 2228 For example, they may arrive in the middle of a method exchange. An 2229 EAP Notification Request cannot be NAK'd. 2230 b. An EAP Notification Response MUST be sent by the peer in response to 2231 an EAP Notification Request. The Response is sent automatically by 2232 the peer and confirms receipt, but does not indicate whether the user 2233 took any action in response to the message, or even whether the message 2234 was displayed to the user at all (e.g. it may be consumed by an 2235 embedded device). 2236 c. EAP Notification Requests SHOULD be displayed or logged by the peer. 2237 It cannot be assumed that Notification Requests are available for 2238 processing by the running method. 2239 d. EAP Notification Requests or Responses do not result in a state 2240 change. 2241 e. EAP Notification is *not* an error indication. 2243 Below find the original survey and posted responses. 2245 Date: Wed, 2 Oct 2002 12:22:42 -0700 (PDT) 2246 From: Bernard Aboba 2247 To: eap@frascone.com 2248 Subject: [eap] Notification survey 2250 In the EAP Design team meeting today, we discussed the use of EAP 2251 Notification. The question arose as to what people are using this for 2252 today, and why. If you have implemented EAP Notification in your method 2253 (or your EAP implementation), can you let us know: 2255 a. Whether you are using Notification as part of the method (e.g. 2256 Notification Request is delivered to the method) 2258 b. Whether you allow Notification to be sent at any time (in the middle of 2259 a method exchange) 2261 c. Whether Notification results in a state change within the EAP state 2262 machine or not 2264 d. Whether you would be affected if EAP Notification were to be eliminated 2265 or deprecated, and why this would be bad (or good) 2267 --__--__-- 2269 Date: Wed, 02 Oct 2002 23:02:10 +0200 2270 To: Bernard Aboba 2271 From: Jacques Caron 2272 Subject: Re: [eap] Notification survey 2273 Cc: eap@frascone.com 2275 Hi, 2277 I don't use it (yet), but: 2279 a. I definitely believe a method on the client side shouldn't expect any 2280 such messages (there should be a generic method handler for it that will 2281 just display the message to the user - a bit like there should be a generic 2282 identity method handler that just returns the identity). 2284 b. It should be possible to possible to send this nearly at any time: 2285 - there should be only one outstanding request (i.e. not possible to send a 2286 Notification request just after some other method request before the 2287 response came back) 2288 - at the very least it should be possible to use it between two requests 2289 from different methods, not necessarily in the middle of the exchanges of 2290 one given method. 2292 c. Receiving a Notification request should prompt a Notification response, 2293 and then return to the same state. If the message is displayed via some 2294 kind of alert/dialog box (that requires user action), the question of 2295 whether the response is sent immediately or once the user acknowledges the 2296 dialog box remains open (in that last case there would be an intermediate 2297 state, I guess). 2299 d. I believe it's useful to be able to send clear-text messages to the 2300 client, in the following (non-exhaustive list of) cases: 2301 - an authentication method failed, and the method wants to give the user 2302 more information about why 2303 - a method (maybe not an authentication one, more an authorization one) got 2304 a NAK back, and the method wants to tell something to the user anyway (e.g. 2305 connection cost) 2306 Of course the problem of the authenticity of the message is present, but 2307 that's a more general problem of EAP messages... 2308 An important point is that one should just not consider that the message 2309 will actually be seen and/or interpreted by anyone, it's purely informative. 2311 Just my 0.02 EUR. 2313 Jacques. 2315 --__--__-- 2317 Date: Thu, 03 Oct 2002 13:00:01 +0300 2318 From: Preeti Vinayakray 2319 Organization: Nokia Research Centere 2320 To: ext Bernard Aboba 2321 CC: eap@frascone.com 2322 Subject: Re: [eap] Notification survey 2324 Hello: 2326 Following ans. relevant to my EAP implementation 2328 ext Bernard Aboba wrote: 2330 > In the EAP Design team meeting today, we discussed the use of EAP 2331 > Notification. The question arose as to what people are using this for 2332 > today, and why. If you have implemented EAP Notification in your method 2333 > (or your EAP implementation), can you let us know: 2334 > 2335 > a. Whether you are using Notification as part of the method (e.g. 2336 > Notification Request is delivered to the method) 2337 > 2339 Yes, it is used as a part of the method 2341 > 2342 > b. Whether you allow Notification to be sent at any time (in the middle of 2343 > a method exchange) 2344 > 2346 No, 2348 > 2349 > c. Whether Notification results in a state change within the EAP state 2350 > machine or not 2351 > 2353 No 2355 > 2356 > d. Whether you would be affected if EAP Notification were to be eliminated 2357 > or deprecated, and why this would be bad (or good) 2358 > 2360 This very much depends on how implementation is done. In terms of my 2361 implementation I consider it is 'good 'as a part of methods I have 2362 supported, But it does not change any state info for client/peer. It just 2363 provides some line display. So elimination of this not going to affect. 2365 -Preeti 2367 >From carlsonj@phorcys.east.sun.com Fri Oct 4 09:53:16 2002 2368 To: Bernard Aboba 2369 Subject: Re: [eap] Notification survey 2371 I have this implementation: 2373 ftp://playground.sun.com/pub/eap/index.html 2375 and I'm working on updating it and integrating it into 'pppd' (since 2376 I'm now one of the maintainers of that software) for the next release. 2378 > a. Whether you are using Notification as part of the method (e.g. 2379 > Notification Request is delivered to the method) 2381 No, it's not part of the method. 2383 > b. Whether you allow Notification to be sent at any time (in the middle of 2384 > a method exchange) 2386 Sure. 2388 > c. Whether Notification results in a state change within the EAP state 2389 > machine or not 2391 No. Nothing in the RFC describes it being used that way ... 2393 > d. Whether you would be affected if EAP Notification were to be eliminated 2394 > or deprecated, and why this would be bad (or good) 2396 I wouldn't be affected. I never send them, and I just log them if 2397 received (and of course send ack). 2399 I don't think it would be good to remove this message. I like having 2400 a "I think this is interesting for you to log" message for debug and 2401 deployment reasons. If, however, we fixed 'Success' and 'Failure' to 2402 be able to include a debug text message (as I think they ought to have 2403 from the start), then I'd be somewhat happier with losing 2404 Notification. (Not perfect, but good enough.) 2406 (I also think that the possible i18n concerns and the spamming 2407 concerns are misplaced -- the receiver can do anything it likes with 2408 these, including discarding the text.) 2410 -- 2411 James Carlson, Solaris Networking 2412 SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 2413 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 2415 Date: Thu, 3 Oct 2002 09:54:36 -0700 (PDT) 2416 From: Bernard Aboba 2417 To: eap@frascone.com 2418 Subject: [eap] RE: Notification survey 2420 For what it's worth, here are some details on how Windows implements 2421 Notification: 2423 - EAP-Notification is out-of-band. The EAP layer automatically sends a 2424 Notification Response; the Notification Request is not passed to the 2425 currently running method. 2427 - EAP-Notification can be sent at any time. There are no checks done when 2428 the EAP-Notification arrives. 2430 - Since EAP-Notification is not passed to the method, it does not result 2431 in a state change. 2433 - EAP Notification does not have support for internationalization. The 2434 lack of language support means that there is no easy way to display a 2435 message to the user in a language that they can be guaranteed to 2436 understand. 2438 - EAP-Notification does not result in a display to the user at present. 2440 --__--__-- 2442 5. Normative references 2444 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 2445 RFC 1661, July 1994. 2447 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 2448 Protocol (CHAP)", RFC 1994, August 1996. 2450 [RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode 2451 and ISO 10646", RFC 2044, October 1996. 2453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2454 Requirement Levels", RFC 2119, March 1997.] 2456 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 2457 10646", RFC 2279, January 1998. 2459 [RFC2434] Alvestrand, H. and Narten, T., "Guidelines for Writing an 2460 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2461 October 1998. 2463 [RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission 2464 Timer", RFC 2988, November 2000. 2466 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 2467 Overview and Architecture, ANSI/IEEE Std 802, 1990. 2469 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 2470 Port based Network Access Control, IEEE Std 802.1X-2001, 2471 June 2001. 2473 6. Informative references 2475 [DECEPTION] Slatalla, M., and Quittner, J., "Masters of Deception." 2476 HarperCollins, New York, 1995. 2478 [RFC1510] Kohl, J., Neuman, C., "The Kerberos Network 2479 Authentication Service (V5)", RFC 1510, September 1993. 2481 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 2482 RFC 2246, November 1998. 2484 [RFC2486] Beadles, M., Aboba, B., "The Network Access Identifier", 2485 RFC 2486, January 1999. 2487 [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the 2488 Internet Protocol", RFC 2401, November 1998. 2490 [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J., 2491 "Internet Security Association and Key Management 2492 Protocol (ISAKMP)", RFC 2408, November 1998. 2494 [RFC2433] Zorn, G., Cobb, S., "Microsoft PPP CHAP Extensions", RFC 2495 2433, October 1998. 2497 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 2498 G., and Palter, B., "Layer Two Tunneling Protocol L2TP", 2499 RFC 2661, August 1999. 2501 [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication 2502 Protocol", RFC 2716, October 1999. 2504 [KRBATTACK] Wu, T., "A Real-World Analysis of Kerberos Password 2505 Security", Stanford University Computer Science 2506 Department, http://theory.stanford.edu/~tjw/krbpass.html 2508 [KRBLIM] Bellovin, S.M., Merritt, M., "Limitations of the kerberos 2509 authentication system", Proceedings of the 1991 Winter 2510 USENIX Conference, pp. 253-267, 1991. 2512 [KERB4WEAK] Dole, B., Lodin, S., and Spafford, E., "Misplaced trust: 2513 Kerberos 4 session keys", Proceedings of the Internet 2514 Society Network and Distributed System Security 2515 Symposium, pp. 60-70, March 1997. 2517 [PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE 2518 Credential Provisioning Protocol", Internet draft (work 2519 in progress), draft-ietf-ipsra-pic-05.txt, February 2002. 2521 [PPTPv1] Schneier, B, Mudge, "Cryptanalysis of Microsoft's Point- 2522 to- Point Tunneling Protocol", Proceedings of the 5th ACM 2523 Conference on Communications and Computer Security, ACM 2524 Press, November 1998. 2526 [IEEE8023] ISO/IEC 8802-3 Information technology - 2527 Telecommunications and information exchange between 2528 systems - Local and metropolitan area networks - Common 2529 specifications - Part 3: Carrier Sense Multiple Access 2530 with Collision Detection (CSMA/CD) Access Method and 2531 Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 2532 1996), 1996. 2534 [IEEE80211] Information technology - Telecommunications and 2535 information exchange between systems - Local and 2536 metropolitan area networks - Specific Requirements Part 2537 11: Wireless LAN Medium Access Control (MAC) and 2538 Physical Layer (PHY) Specifications, IEEE Std. 2539 802.11-1997, 1997. 2541 Acknowledgments 2543 Many thanks to the volunteers of the EAP Design team. 2545 Authors' Addresses 2547 Bernard Aboba 2548 Microsoft Corporation 2549 One Microsoft Way 2550 Redmond, WA 98052 2552 EMail: bernarda@microsoft.com 2553 Phone: +1 425 706 6605 2555 Full Copyright Statement 2557 Copyright (C) The Internet Society (2002). All Rights Reserved. 2558 This document and translations of it may be copied and furnished to 2559 others, and derivative works that comment on or otherwise explain it or 2560 assist in its implementation may be prepared, copied, published and 2561 distributed, in whole or in part, without restriction of any kind, 2562 provided that the above copyright notice and this paragraph are included 2563 on all such copies and derivative works. However, this document itself 2564 may not be modified in any way, such as by removing the copyright notice 2565 or references to the Internet Society or other Internet organizations, 2566 except as needed for the purpose of developing Internet standards in 2567 which case the procedures for copyrights defined in the Internet 2568 Standards process must be followed, or as required to translate it into 2569 languages other than English. The limited permissions granted above are 2570 perpetual and will not be revoked by the Internet Society or its 2571 successors or assigns. This document and the information contained 2572 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 2573 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 2574 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2575 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2576 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2577 Open issues 2579 Open issues relating to this specification are tracked on the following 2580 web site: 2582 http://www.drizzle.com/~aboba/EAP/eapissues.html 2584 Expiration Date 2586 This memo is filed as , and expires July 2587 24, 2003.