idnits 2.17.1 draft-ietf-pppext-eapisakmp-00.txt: ** The Abstract section seems to be numbered -(274): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(598): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. ** 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([EAP], [RFC1962], [RFC1661], [RFC1968], [Oakley], [ISAKMP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 134: '...Exchange SHOULD be an ISAKMP/Oakley ph...' RFC 2119 keyword, line 195: '...tion derived the ISAKMP Initiator MUST...' RFC 2119 keyword, line 234: '...re-Shared Keys the Initiator MUST take...' RFC 2119 keyword, line 239: '...re-shared keys the Initiator MUST send...' RFC 2119 keyword, line 241: '...data portion MUST contain an ISAKMP Id...' (24 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...), its areas...' == Line 12 has weird spacing: '...and its worki...' == Line 16 has weird spacing: '...and may be u...' == Line 17 has weird spacing: '...afts as refer...' == Line 20 has weird spacing: '...To learn the...' == (23 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Oakley' is mentioned on line 42, but not defined == Missing Reference: 'DOI' is mentioned on line 90, but not defined == Missing Reference: 'ECP' is mentioned on line 91, but not defined == Missing Reference: 'CCP' is mentioned on line 91, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 95, but not defined == Unused Reference: 'OAKLEY' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'RFC2058' is defined on line 781, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-pppext-eaptls-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-pppext-eaptls (ref. 'EAPTLS') == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-isakmp-08 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'ISAKMP') ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-oakley (ref. 'OAKLEY') == Outdated reference: A later version (-07) exists of draft-ietf-ipsec-isakmp-oakley-04 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'IO') ** Obsolete normative reference: RFC 2058 (Obsoleted by RFC 2138) ** Downref: Normative reference to an Informational draft: draft-ietf-pppext-hpppc (ref. 'HPPPC') Summary: 18 errors (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Extensions Working Group G. Carter 3 INTERNET-DRAFT Entrust Technologies 4 November 19 1997 6 PPP EAP ISAKMP Authentication Protocol 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 The distribution of this memo is unlimited. It is filed as , and expires June 1, 1998. Please send 27 comments to the authors. 29 2. Abstract 31 The Point-to-Point Protocol (PPP) [RFC1661] provides a standard 32 method for transporting multi-protocol datagrams over point-to-point 33 links. PPP also defines an extensible Link Control Protocol (LCP), 34 which can be used to negotiate authentication methods, as well as an 35 Encryption Control Protocol (ECP) [RFC1968], used to negotiate data 36 encryption over PPP links, and a Compression Control Protocol (CCP) 37 [RFC1962], used to negotiate compression methods. The Extensible 38 Authentication Protocol (EAP) [EAP] is a PPP extension that provides 39 support for additional authentication methods within PPP. 41 The Internet Security Association and Key Management Protocol [ISAKMP] 42 combined with the Oakley [Oakley] key exchange protocol enables secure, 43 mutually authenticated security association exchanges between two 44 endpoints. This document describes how ISAKMP provides for these 45 mechanisms within EAP. 47 3. Introduction 49 The Extensible Authentication Protocol (EAP), described in [EAP], 50 provides a standard mechanism for support of additional 51 authentication methods within PPP. Through the use of EAP, support 52 for a number of authentication schemes may be added, including smart 53 cards, Kerberos, Public Key, One Time Passwords, and others. 55 When PPP servers are access via public networks it is desirable for a 56 client to be able to cryptographically prove the identity of the server 57 with which it is establishing a connection. Recently EAP-TLS [EAPTLS] 58 has been proposed as a method of EAP which provides mutual 59 authentication. This document describes an alternative to EAP-TLS which 60 uses the Internet Security Association and Key Management Protocol 61 combined with Oakley (ISAKMP/Oakley [IO]) to provide the mutual 62 authentication. 64 In addition to mutual authentication, as with EAP-TLS, EAP-ISAKMP 65 provides a means to derive session keys for use with PPP encryption 66 protocols. EAP-ISAKMP has a number of unique characteristics not found 67 in other EAP methods which make it a desirable authentication method: 69 Identity Protection - When used in Main Mode. 71 Authentication Protocol Independence - public key or shared secret. 73 Supports Revocation information exchange - when appropriate ISAKMP 74 authentication method is selected. 76 Easy transition from PAP or CHAP - User password can become ISAKMP 77 Pre-Shared Secret. 79 Designed specifically for session key establishment and related 80 rekeying. 82 Prefect Forward Secrecy of Session keys. 84 Ability to shared ISAKMP SA negotiated during PPP establishment with 85 IPSec if so desired. 87 Code sharing between IPSEC and EAP. 89 Readers of this document should familiarize themselves with ISAKMP 90 [ISAKMP], ISAKMP/Oakley [IO], IPSEC-DOI [DOI], PPP-EAP [EAP], PPP_ECP 91 [ECP], and PPP-CCP [CCP]. 93 3.1 Requirements language Keywords "MUST", "MUST NOT", "REQUIRED", 94 "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be 95 interpreted as described in [RFC 2119]. 97 3.2 Terminology 99 Initiator - The entity which initiates the ISAKMP exchange. EAP has the 100 notion of an authenticator which is the end requesting authentication. 101 While EAP-ISAKMP provides mutual authentication the Initiator is usually 102 the entity commonly associated as being the authenticator, the network 103 access device (NAS, Router, RAS, etc�). 105 Responder - The entity which is replying to an ISAKMP request. Usually 106 the EAP peer. 108 SA - Security Association. A grouping of parameters which defines the 109 cryptographic protection to apply to data transmitted or received. 111 Phase 1 - The exchange during which mutual authentication occurs and 112 keys are derived which are used to protect the subsequent session key 113 establishment phase. Results in ISAKMP SA. 115 Phase 2 - The exchange during which ECP and CCP algorithms are 116 negotiated. As well keys are derived for ECP. 118 ISAKMP SA - The SA established as a result of an ISAKMP phase 1 119 exchange. This SA is used to protect ISAKMP phase 2 and ISAKMP Notify 120 exchanges. 122 EAP SA - The SA established as a result of an ISAKMP phase 2 exchange. 123 This SA contains session keys for use with ECP (if so desired). 125 ISAKMP/Oakley - The resolution of ISAKMP combined with Oakley as defined 126 in [IO]. 128 4. Protocol Overview 130 After EAP is negotiated during Link Establishment phase the initiator 131 sends the first EAP packet with the type field set to EAP-ISAKMP. The 132 data portion contains the first ISAKMP packet consisting of the ISAKMP 133 header followed by ISAKMP Exchange dependent data. The first ISAKMP 134 Exchange SHOULD be an ISAKMP/Oakley phase 1 exchange which authenticates 135 the peers and establishes a protection suite. The protection suite is 136 used during session key establishment and notification exchanges, this 137 is the ISAKMP SA. ISAKMP/Oakley defines two types of phase 1 exchanges 138 MAIN MODE and AGGRESSIVE MODE. MAIN MODE allows for identity 139 protection, AGGRESSIVE MODE requires fewer exchanges but at the cost of 140 identity protection. Pictured below is ISAKMP in Main Mode. Appendix A 141 contains examples of ISAKMP/Oakley in AGGRESSIVE MODE. 143 MAIN MODE: 145 Initiator Responder 147 EAP-Request, uID, Length, 148 EAP-ISAKMP,ISAKMP Hdr, SA --> 150 The Responder replies by choosing an acceptable ISAKMP SA (see [ISAKMP], 151 [IO]) and sends back an EAP Response packet. 153 Initiator Responder 155 <-- EAP-Response, uID, Length, 156 EAP-ISAKMP, ISAKMP Hdr, SA 158 The process continues as outlined in [IO]. As an example detailed below 159 are the remaining exchanges when the ISAKMP authentication mode is RSA 160 Signatures: 162 Initiator Responder 164 EAP-Request, uID, Length, 165 EAP-ISAKMP,ISAKMP Hdr, KE, Ni --> 167 <-- EAP-Response, uID, Length, 168 EAP-ISAKMP,ISAKMP Hdr, KE, Nr 170 EAP-Request, uID, Length, 171 EAP-ISAKMP, ISAKMP Hdr*, IDii, --> 172 [CERT, ] SIG_I 174 <-- EAP-Response, uID, Length, 175 EAP-ISAKMP, ISAKMP Hdr*, IDir, 176 [CERT,] SIG_R 178 Upon completion of this exchange the peers have mutually authenticated 179 each other and have arrived at an acceptable ISAKMP SA. If the 180 Initiator does not wish to negotiate PPP encryption or PPP compression 181 using ISAKMP the EAP Success message should be sent to the Responder to 182 signal that the authentication has completed successfully. 184 Initiator Responder 186 EAP-Success, uID, Length --> 187 The EAP-Success message does not require authentication because this has 188 already been provided within ISAKMP. 190 Note ECP and CCP negotiation may still take place, however ISAKMP will 191 not be able to provide session keys unless a phase 1 exchange is 192 followed by at least one phase 2 exchange. 194 If PPP Encryption or Compression is to be used and it is desirable to 195 have session keys for PPP Encryption derived the ISAKMP Initiator MUST 196 begin an ISAKMP/Oakley QUICK_MODE Negotiation after the first ISAKMP SA 197 has been negotiated but BEFORE the first EAP-Success message is sent. 198 Subsequent QUICK_MODE negotiations may occur to freshen the keying 199 material. 201 4.1 QUICK_MODE 203 Initiator Responder 205 EAP-Request, uID, Length, 206 EAP-ISAKMP, ISAKMP Hdr*,HASH(1), --> 207 SA, Ni [, KE] [, IDui, IDur] 209 <-- EAP-Response, uID, Length, 210 EAP-ISAKMP,ISAKMP Hdr*, HASH(2), 211 SA, Nr [, KE] [, IDui, IDur] 213 EAP-Request, uID, Length, 214 EAP-ISAKMP, ISAKMP Hdr*, HASH(3) --> 216 <-- EAP-Response, uID, Length, 217 EAP-ISAKMP 219 EAP-Success, uID, Length --> 221 Note that in order to maintain the EAP Request - Response exchange 222 format it is necessary for the responder to reply to the Initiators 223 final HASH(3) ISAKMP message. This is done by sending an empty EAP - 224 Response message with type set to EAP-ISAKMP. This message as well as 225 the final EAP - Success message do not require authentication because 226 this has taken place within ISKAMP (HASH payloads). 228 After the QUICK MODE exchange has occurred each entity will posses two 229 security associations, one for inbound traffic and one for outbound 230 traffic. The session keys derived for each direction will be unique. 232 4.2 ISAKMP with Pre-Shared Keys 233 When ISAKMP/Oakley is used in MAIN MODE (and only MAIN MODE) and the 234 agreed authentication method is Pre-Shared Keys the Initiator MUST take 235 special action in order to assure that both entities have received valid 236 identity information that can be used to identify the correct pre-shared 237 key to use. Therefore after the SA exchange of the ISAKMP SA 238 negotiation in MAIN MODE if the Initiator determines that the agreed 239 ISAKMP authentication method is pre-shared keys the Initiator MUST send 240 an EAP-Identity/Request message to the peer. The EAP-Identity/Request 241 data portion MUST contain an ISAKMP Identity payload with the Initiators 242 identity. The Responder MUST reply with an EAP-Identity/Response with 243 the data portion encapsulating one ISAKMP Identity payload containing 244 the responders identification information. After the Initiator has 245 received the EAP-Identity/Response it continues on with the ISAKMP SA 246 Negotiation. 248 * note * -- Because the entities require the identity information 249 prior to ISAKMP key establishment the Identities are sent in the 250 clear, therefore one of the primary benefits of MAIN MODE, Identity 251 Protection, is lost. If the Initiator believes that the ISAKMP 252 authentication method will likely be Pre-Shared Keys the Initiator 253 SHOULD use ISAKMP/Oakley in AGGRESSIVE MODE. Aggressive mode allows 254 the entities to examine the ISAKMP identity before lookup of the 255 pre-shared key, however at the expense of Identity protection. 257 Initiator Responder 259 EAP-Request, uID, Length, 260 EAP-ISAKMP, ISAKMP Hdr, SA --> 262 <-- EAP-Response, uID, Length, 263 EAP-ISAKMP,ISAKMP Hdr, SA 265 Initiator examines agreed SA and determines Pre Shared Keys are to be 266 used, therefore must send own ID and receive responders ID. 268 EAP-Identity/Request, uID, 269 EAP-ISAKMP, Length, IDii --> 271 <-- EAP-Identity/Response, uID, 272 Length, EAP-ISAKMP, IDir 274 At this point both sides have received the other�s identity information. 275 The ISAKMP exchange continues. 277 Initiator Responder 279 EAP-Request, ID, Length, 280 EAP-ISAKMP, ISAKMP Hdr, --> 281 KE, Ni 283 <-- EAP-Response, ID, Length, 284 EAP-ISAKMP,ISAKMP Hdr, KE, Nr 286 EAP-Request, ID, Length, 287 EAP-ISAKMP, ISAKMP Hdr*, --> 288 IDii, HASH_I 290 <-- EAP-Response, ID, Length, 291 EAP-ISAKMP, ISAKMP Hdr*, IDir, HASH_R 293 EAP-Success, ID, Length --> 295 4.3 Informational Exchanges 297 There are two situations where an Informational exchange may take place 298 within ISAKMP/Oakley. These are: 300 Failed SA Establishment 302 All other Notify exchanges, including SA Delete. 304 4.3.1 Failed SA Establishment 306 When SA establishment fails the entity which has detected the failure 307 may optionally send an ISAKMP notify message to the peer informing the 308 peer of the failure. In the examples below the failure is assumed to 309 occur during phase 1, hence the notify is sent without protection. If 310 the failure were to occur during phase 2 the notify would be sent 311 encrypted with an additional HASH payload to authenticate the message. 313 4.3.1.1 Responder Side SA Failure 315 If the failure is detected on the Responder the ISAKMP Notify message 316 MUST be sent. The ISAKMP Notify message is sent in the EAP - Response 317 packet. Upon receiving the error Notify the Initiator MUST send an 318 EAP-Failure message. The responder must send a notify in order to 319 comply with the EAP Request - Response exchange. 321 Initiator Responder 322 EAP-Request, uID, Length, 323 EAP-ISAKMP,ISAKMP Hdr, SA --> 325 Responder detects an error and sends back an ISAKMP Notify. 327 <-- EAP-Response, uID, Length, 328 EAP-ISAKMP, ISAKMP Hdr, Notify 330 EAP - Failure - ID - Length --> 332 4.3.1.2 Initiator Side SA Failure 334 If the failure occurs on the Initiator the Initiator may send an ISAKMP 335 Notify message in an EAP - Request message to notify the peer of the 336 error and provide additional information. The Responder MUST reply to 337 the notify with an EAP - Response with an empty data field. The 338 Initiator then replies with a final EAP - Failure message. If the 339 Initiator does not wish to send an ISAKMP Notify message it MUST 340 immediately send an EAP - Failure message. 342 4.3.1.2.1 Initiator Side SA Failure with Notify 344 Initiator Responder 345 EAP-Request, uID, Length, 346 EAP-ISAKMP,ISAKMP Hdr, SA --> 348 <-- EAP-Response, uID, Length, 349 EAP-ISAKMP, ISAKMP Hdr, SA 351 Initiator detects a failure, sends back notify. 353 EAP-Request, uID, Length, 354 EAP-ISAKMP, ISAKMP Hdr, Notify --> 356 <-- EAP-Response, uID, Length 358 EAP-Failure, uID, Length --> 360 4.3.1.2.2 Initiator Side SA Failure without Notify 362 Initiator Responder 363 EAP-Request, uID, Length, 364 EAP-ISAKMP,ISAKMP Hdr, SA --> 366 <-- EAP-Response, uID, Length, 367 EAP-ISAKMP, ISAKMP Hdr, SA 369 Initiator detects a failure, immediately sends back EAP-Failure. 371 EAP-Failure, uID, Length --> 372 4.3.2 Other ISAKMP Notify Exchanges 374 Other types of ISAKMP Notify messages may be sent at any time with 375 ISAKMP. Each notify is sent in side an EAP - Request packet and MUST be 376 acknowledged with an empty EAP - Response packet. Either side may 377 initiate the notify. 379 4.4 Security Parameter Index and EAP-ISAKMP 381 Neither ECP nor CCP require the use of SPIs, however in order to 382 generate unique keying material derived using QUICK MODE both peers MUST 383 supply an SPI. The SPI MUST be 4 octets in length. The Responder MUST 384 choose an SPI value which is not equal to the Initiators. There are no 385 other restrictions on the SPI. [SHOULD THIS GO IN DOI SECTION?] 387 4.5 Re-keying and EAP-ISAKMP 389 Since ECP does not use SPIs there needs to be some other way for an 390 entity to signal the other that the most recently negotiated key is now 391 in use. To do this the ECP sequence number is reset to 0 to indicate to 392 the peer that the new key/IV was used to protect the packet. [IS THIS A 393 GOOD IDEA?] 395 4.6 Fragmentation 397 Refer to [EAP]. [SUGGESTION - MOVE TLS FRAGMENTATION DESCRIPTION TO 398 BASE EAP DOC] 400 5. EAP Interaction with ECP and CCP 402 When EAP is used with ISAKMP the negotiation phase of ECP and CCP can be 403 bypassed, instead providing the ECP and CCP components of PPP the values 404 negotiated with EAP-ISAKMP. 406 6. EAP ISAKMP DOI 408 [Note this will become a separate document. For simplicity it is 409 currently combined with this document] 411 For information on EAP-DOI treatments of situation, security policies, 412 and naming schemes please see the IPSEC DOI. The EAP-DOI adds no new 413 information in these areas. 415 6.1 EAP-ISAKMP Assigned Numbers 417 The EAP type for this protocol is ?. 419 The DOI value for this protocol is ?. 421 The following table lists the values for the Security Protocol 422 Identifiers referenced in the ISKAMP Proposal Payload for the EAP-ISAKMP 423 DOI: 425 Protocol ID Value 426 -------------- ------- 427 RESERVED 0 428 PROTO_ISAKMP 1 429 PROTO_PPP_ECP 2 430 PROTO_PPP_CCP 3 432 The size of the field is one octet. The values 2-248 are reserved for 433 to IANA. Values 249-255 are reserved for private use. 435 6.1.1 PROTO_ISAKMP 437 The PROTO_ISKAMP type specifies message protection required during phase 438 1 of the ISAKMP protocol. The specific protection mechanism used for 439 the EAP DOI is described in [IO]. All implementations within the EAP 440 DOI MUST support PROTO_ISAKMP. 442 NB: ISAKMP reserves the value (1) across all DOI definitions. 444 6.1.2 PROTO_PPP_ECP 446 The PROTO_PPP_ECP type specifies PPP packet confidentiality usually 447 negotiated during the Encryption Control Protocol phase of PPP 448 establishment. 450 6.1.3 PROTO_PPP_CCP 452 The PROTO_PPP_CCP type specifies PPP packet compression usually 453 negotiated during the Compression Control Protocol phase of PPP 454 establishment. 456 6.2 PPP ISAKMP Transform Values 458 These values are the same as those defined in the IPSEC DOI section 459 4.4.2. 461 6.3 PPP ECP Transform Values 463 The ECP protocol currently defines two transform values, neither is 464 mandatory, used to provide confidentiality of PPP datagrams. The 465 following table lists the defined PPP ECP transform identifiers for the 466 ISAKMP Proposal Payload for the PPP DOI: 468 Transform ID Value 469 ---------------- ------- 470 ECP_OUI 0 471 ECP_DESE 1 472 ECP_DESE_BIS 2 474 The size of the field is one octet. The values 4-254 are reserved to 475 IANA. 477 6.3.1 ECP_OUI 479 The ECP_OUI type specifies a proprietary encryption transform. The 480 ECP_OUI type MUST be accompanied by an Encryption OUI attribute which 481 further identifies the specific vendor algorithm and parameters. 483 6.3.2 ECP_DESE 485 The ECP_DESE type specifies the DESE transform detailed in RFC1969. 486 This value may be negotiated for compatibility with older systems. The 487 ECP_DESE type MUST be accompanied by an Encryption Nonce attribute. 489 6.3.3 ECP_DESE_BIS 491 The ECP_DESE_BIS type specifies the DESE transform detailed in draft- 492 ietf-pppext-des-encrypt-v2-00.txt. Implementations are encouraged to 493 support this transform. The ECP_DESE_BIS type MUST be accompanied by an 494 Encryption Nonce attribute. Note however that this value is chosen by 495 the Initiator (the responder can not specify a value to use for its IV 496 generation), however since ISAKMP/Oakley in Quick Mode derives unique 497 keys for each entity the resulting IV will be different for traffic to 498 each peer. Therefore uniqueness of IV�s is preserved 500 6.4 PPP CCP Transform Values 502 The CCP protocol currently defines a number of transform values, none of 503 which are mandatory, used to provide compression of PPP datagrams. The 504 following table lists the defined PPP CCP transform identifiers for the 505 ISAKMP Proposal Payload for the PPP DOI: 507 Transform ID Value 508 ---------------- ------- 509 0 OUI 510 1 Predictor type 1 511 2 Predictor type 2 512 3 Puddle Jumper 513 4-15 unassigned 514 16 Hewlett-Packard PPC 515 17 Stac Electronics LZS 516 18 Microsoft PPC 517 19 Gandalf FZA 518 20 V.42bis compression 519 21 BSD LZW Compress 520 255 Reserved 522 The size of the field is one octet. Values 22-254 are reserved by IANA. 524 6.4.1 CCP_OUI 526 The CCP_OUI type specifies a proprietary encryption transform. The 527 CCP_OUI type MUST be accompanied by a Compress OUI attribute which 528 further identifies the specific vendor algorithm and parameters. 530 6.4.2 CCP_PREDICTOR_1 532 Identifies the compression transform detailed in RFC1978. 534 6.4.3 CCP_PREDICTOR_2 536 Identifies the compression transform detailed in RFC1978. 537 6.4.4 CCP_PUDDLE_JUMPER 538 ? 540 6.4.5 CCP_HP_PCC 541 Identifies the compression transform detailed in [HPPPC]. 543 6.4.6 CCP_STAC_LZS 544 Identifies the compression transform detailed in RFC1974. 546 6.4.7 CCP_MS_PPC 547 Identifies the compression transform detailed in RFC2118. 549 6.4.8 CCP_GANDALF_FZA 550 Identifies the compression transform detailed in RFC1993. 552 6.4.9 CCP_V42_BIS 553 Identifies the compression transform detailed in ? 555 6.4.10 CCP_ BSD_LZW 556 Identifies the compression transform detailed in RFC1977. 558 6.5 EAP Security Association Attributes 560 The following SA attribute definitions are used in phase 2 of an 561 ISAKMP/Oakley negotiation. Attribute types can be either Basic (B) or 562 Variable-Length (V). Encoding of these attributes is defined in the 563 base ISAKMP specification. 565 Attribute Classes: 566 Class Value Type 567 ------ ------- ------- 568 SA Life Type 1 B 569 SA Life Duration 2 B/V 570 Group Description 3 B 571 Key Length 4 B 572 Key Rounds 5 B 573 Compress Dictionary Size6 B 574 Compress OUI 7 V 575 Encryption Nonce 8 V 576 Encryption OUI 9 V 577 Session ID 10 B/V 579 The size of the attribute class field is two octets, with the high bit 580 reserved for ISAKMP B/V encoding indicator. The values 10 - 32000 are 581 reserved for IANA, values 32001 - 32767 are for experimental use. 583 Class Values 585 SA Life Type 586 SA Duration 588 Specifies the time to live for the overall security association. When 589 the SA exipers, all keys negotiated under the association (PPP_ECP) must 590 be renegotiated. The life type values are: 592 RESERVED 0 593 Seconds 1 594 kilobytes 2 596 Values 3-61439 are reserved for IANA. Values 61440 - 65535 are for 597 experimental use. For a given life type the value of the life duration 598 attribute defines the actual length of the component lifetime � either a 599 number of seconds, or a number of kilobytes that can be 600 protected/compressed. 602 If unspecified the default value shall be assumed to be 28800 seconds (8 603 hours). 605 Group Description 607 RESERVED 0 608 Group 1 - 768 Prime 1 609 Group 2 - 1024 Prime 2 611 Values 2-61439 are reserved for IANA. Values 61440 - 65535 are for 612 experimental use. 614 This attribute is used for PFS in phase 2 negotiations. See 615 ISAKMP/Oakley for a description of the Diffie - Hellman parameters which 616 make up these groups. If PFS is desired this attribute MUST be sent. 618 Key Length 620 RESERVED 0 622 There is no default value for Key Length. It is used for ECP Transforms 623 which have variable length keys. However transform documents may define 624 a default value for the particular transform. 626 Key Rounds 628 RESERVED 0 630 There is no default value for Key Rounds. It is used for ECP Transforms 631 which have variable key rounds. However transform documents may define 632 a default value for the particular transform. 634 Compression Dictionary Size 636 RESERVED 0 638 Specifies the log2 maximum size of the dictionary. There is no default 639 value. 641 Compression OUI 643 Specifies a private vendor compression algorithm using the vendors 644 Organization Unique Identifier. The first three (3) octets MUST be the 645 most signification three (3) octets of an Ethernet Physical Address, 646 assigned to the vendor by IEEE 802. The next octet may be vendor 647 specific compression algorithm subtype, followed by zero or more octets 648 of vendor data. 650 This attribute MUST accompany requests for transforms of type CCP_OUI. 652 Encryption Nonce 654 Supplied by the Initiator to the Responder. This value is used in the 655 calculation of the initial IV for PPP_ECP encryption. 657 This attribute MUST accompany requests for transforms of type ECP_DESE 658 and ECP_DESE_BIS. 660 Encryption OUI 662 Specifies a private vendor encryption algorithm using the vendors 663 Organization Unique Identifier. The first three (3) octets MUST be the 664 most signification three (3) octets of an Ethernet Physical Address, 665 assigned to the vendor by IEEE 802. The next octet may be vendor 666 specific encryption algorithm subtype, followed by zero or more octets 667 of vendor data. 669 This attribute MUST accompany requests for transforms of type ECP_OUI. 671 Session ID 673 Multilink sessions may be setup between the EAP peer and the 674 authenticator. To avoid repeated authentication during multilink setup 675 the EAP server MAY provide a Session ID during the first EAP SA 676 establishment (EAP authenticator always initiates first EAP SA). The 677 EAP peer MAY include the Session ID in subsequent EAP SA negotiations 678 where it acts as the Initiator. 680 6.5.1 Required Attribute Support 682 To ensure basic interoperability all implementations MUST be prepared to 683 negotiate all of the following attributes: 685 SA Life Type 686 SA Duration 687 Encryption Nonce 689 6.6 Payload Specifications 691 This DOI does not define any new payload formats other than those 692 defined in the IPSEC DOI. See IPSEC DOI. 694 6.7 EAP Key Exchange Types 695 This DOI defines no new key exchange types. 697 7.0 Security Considerations 699 7.1 Revocation Data 701 If ISAKMP is used with a certificate scheme supporting revocation an EAP 702 authenticator MUST be prepared to provide revocation lists to the EAP 703 peer if the EAP peer requests those lists within ISAKMP. This allows an 704 otherwise �off-line� client to obtain the necessary revocation 705 information it needs to validate the EAP authenticator�s certificate. 707 7.2 Pass Through EAP and EAP Servers 709 EAP discusses the use of a back-end security server allowing EAP data to 710 pass through the NAS on to the server performing the actual EAP 711 authentication. At this time no IETF standard exists which allows the 712 exchange between the NAS and EAP Server to posses the same degree of 713 security as that offered by ISAKMP/Oakley. Therefore it is REQUIRED 714 that if EAP-ISAKMP is to be used with a back-end security server that 715 the link between the NAS and the security server be protected with IPSec 716 or another comparable protocol which provides full packet authentication 717 and confidentiality. If this condition is meet then the session keys 718 derived on the security server may be passed to the NAS. 720 8. Acknowledgments 722 This document is the result of combining EAP with ISAKMP/Oakley, it 723 borrows heavily from EAP-TLS and from IPSEC DOI. 725 9. Copyright notice 727 Copyright (C) The Internet Society, 1997. All Rights Reserved. 729 This document and translations of it may be copied and furnished to 730 others, and derivative works that comment on or otherwise explain it 731 or assist in its implmentation may be prepared, copied, published and 732 distributed, in whole or in part, without restriction of any kind, 733 provided that the above copyright notice and this paragraph are 734 included on all such copies and derivative works. However, this 735 document itself may not be modified in any way, such as by removing 736 the copyright notice or references to the Internet Society or other 737 Internet organizations, except as needed for the purpose of 738 developing Internet standards in which case the procedures for 739 copyrights defined in the Internet Standards process must be followed, 740 or as required to translate it into languages other than English. 742 The limited permissions granted above are perpetual and will not be 743 revoked by the Internet Society or its successors or assigns. 745 This document and the information contained herein is provided on an 746 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 747 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 748 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 749 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 750 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 752 10.0 References 754 [RFC1661] Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 755 1661. 757 [RFC1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 758 1968, Spider Systems, June 1996. 760 [RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", 761 RFC 1962, Novell, June 1996. 763 [EAP] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible 764 Authentication Protocol (EAP)." Work in progress, draft-ietf- 765 pppext-eap-auth-02.txt, Merit Network, Inc., June 1996. 767 [EAPTLS] B. Aboba, D. Simon, "PPP EAP TLS Authentication Protocol", 768 Work in progress, draft-ietf-pppext-eaptls-02.txt, Microsoft, October 769 1997. 771 [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., 772 "Internet Security Association and Key Management Protocol (ISAKMP)," 773 Work in progress, draft-ietf-ipsec-isakmp-08.{ps,txt}. 775 [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," Work 776 in progress, draft-ietf-ipsec-oakley-01.txt. 778 [IO] Harkins, D., Carrel, D., "The Resolution of ISAKMP with Oakley," 779 Work in progress, draft-ietf-ipsec-isakmp-oakley-04.txt. 781 [RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens, 782 "Remote Authentication Dial In User Service (RADIUS)", RFC 2058, 783 January 1997. 785 [HPPPC] Petty, J., "PPP H-P Packet-by-Packet Compression Protocol", 786 Work in progress, draft-ietf-pppext-hpppc-00.txt. 788 11. Authors' Addresses 790 Greg Carter 791 Entrust Technologies 792 750 Heron Road, Suite E08 793 Ottawa, Ontario 794 Canada, K1V 1A7 796 email: greg.carter@entrust.com 798 A Aggressive Mode ISAKMP 800 Detailed below is ISAKMP in AGGRESSIVE MODE using an authentication 801 method of Signatures. 803 Initiator Responder 805 EAP-Request, uID, Length, 806 EAP-ISAKMP,ISAKMP Hdr, SA, --> 807 KE, Ni, IDii 809 The Responder replies by choosing an acceptable ISAKMP SA (see [ISAKMP], 810 [IO]) and sends back an EAP Response packet. 812 Initiator Responder 814 <-- EAP-Response, uID, Length, 815 EAP-ISAKMP, ISAKMP Hdr, SA, 816 KE, Nr, IDir, [CERT,] SIG_R 818 EAP-Request, uID, Length, 819 EAP-ISAKMP,ISAKMP Hdr, --> 820 [CERT,] SIG_I 822 <-- EAP-Response, uID, Length 824 In the final response from the Responder an empty EAP-Response packet is 825 sent.