PPP Extensions Working Group G. Carter INTERNET-DRAFT Entrust Technologies <draft-ietf-pppext-eapisakmp-00.txt> November 19 1997 PPP EAP ISAKMP Authentication Protocol Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as <draft- ietf-pppext-eapisakmp-00.txt>, and expires June 1, 1998. Please send comments to the authors. 2. Abstract The Point-to-Point Protocol (PPP) [RFC1661] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which can be used to negotiate authentication methods, as well as an Encryption Control Protocol (ECP) [RFC1968], used to negotiate data encryption over PPP links, and a Compression Control Protocol (CCP) [RFC1962], used to negotiate compression methods. The Extensible Authentication Protocol (EAP) [EAP] is a PPP extension that provides support for additional authentication methods within PPP. The Internet Security Association and Key Management Protocol [ISAKMP] combined with the Oakley [Oakley] key exchange protocol enables secure, mutually authenticated security association exchanges between two endpoints. This document describes how ISAKMP provides for these mechanisms within EAP. Carter [Page 1]
INTERNET DRAFT November 19 1997 3. Introduction The Extensible Authentication Protocol (EAP), described in [EAP], provides a standard mechanism for support of additional authentication methods within PPP. Through the use of EAP, support for a number of authentication schemes may be added, including smart cards, Kerberos, Public Key, One Time Passwords, and others. When PPP servers are access via public networks it is desirable for a client to be able to cryptographically prove the identity of the server with which it is establishing a connection. Recently EAP-TLS [EAPTLS] has been proposed as a method of EAP which provides mutual authentication. This document describes an alternative to EAP-TLS which uses the Internet Security Association and Key Management Protocol combined with Oakley (ISAKMP/Oakley [IO]) to provide the mutual authentication. In addition to mutual authentication, as with EAP-TLS, EAP-ISAKMP provides a means to derive session keys for use with PPP encryption protocols. EAP-ISAKMP has a number of unique characteristics not found in other EAP methods which make it a desirable authentication method: Identity Protection - When used in Main Mode. Authentication Protocol Independence - public key or shared secret. Supports Revocation information exchange - when appropriate ISAKMP authentication method is selected. Easy transition from PAP or CHAP - User password can become ISAKMP Pre-Shared Secret. Designed specifically for session key establishment and related rekeying. Prefect Forward Secrecy of Session keys. Ability to shared ISAKMP SA negotiated during PPP establishment with IPSec if so desired. Code sharing between IPSEC and EAP. Readers of this document should familiarize themselves with ISAKMP [ISAKMP], ISAKMP/Oakley [IO], IPSEC-DOI [DOI], PPP-EAP [EAP], PPP_ECP [ECP], and PPP-CCP [CCP]. Carter [Page 2]
INTERNET DRAFT November 19 1997 3.1 Requirements language Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC 2119]. 3.2 Terminology Initiator - The entity which initiates the ISAKMP exchange. EAP has the notion of an authenticator which is the end requesting authentication. While EAP-ISAKMP provides mutual authentication the Initiator is usually the entity commonly associated as being the authenticator, the network access device (NAS, Router, RAS, etc ). Responder - The entity which is replying to an ISAKMP request. Usually the EAP peer. SA - Security Association. A grouping of parameters which defines the cryptographic protection to apply to data transmitted or received. Phase 1 - The exchange during which mutual authentication occurs and keys are derived which are used to protect the subsequent session key establishment phase. Results in ISAKMP SA. Phase 2 - The exchange during which ECP and CCP algorithms are negotiated. As well keys are derived for ECP. ISAKMP SA - The SA established as a result of an ISAKMP phase 1 exchange. This SA is used to protect ISAKMP phase 2 and ISAKMP Notify exchanges. EAP SA - The SA established as a result of an ISAKMP phase 2 exchange. This SA contains session keys for use with ECP (if so desired). ISAKMP/Oakley - The resolution of ISAKMP combined with Oakley as defined in [IO]. 4. Protocol Overview After EAP is negotiated during Link Establishment phase the initiator sends the first EAP packet with the type field set to EAP-ISAKMP. The data portion contains the first ISAKMP packet consisting of the ISAKMP header followed by ISAKMP Exchange dependent data. The first ISAKMP Exchange SHOULD be an ISAKMP/Oakley phase 1 exchange which authenticates the peers and establishes a protection suite. The protection suite is used during session key establishment and notification exchanges, this is the ISAKMP SA. ISAKMP/Oakley defines two types of phase 1 exchanges MAIN MODE and AGGRESSIVE MODE. MAIN MODE allows for identity protection, AGGRESSIVE MODE requires fewer exchanges but at the cost of identity protection. Pictured below is ISAKMP in Main Mode. Appendix A Carter [Page 3]
INTERNET DRAFT November 19 1997 contains examples of ISAKMP/Oakley in AGGRESSIVE MODE. MAIN MODE: Initiator Responder EAP-Request, uID, Length, EAP-ISAKMP,ISAKMP Hdr, SA --> The Responder replies by choosing an acceptable ISAKMP SA (see [ISAKMP], [IO]) and sends back an EAP Response packet. Initiator Responder <-- EAP-Response, uID, Length, EAP-ISAKMP, ISAKMP Hdr, SA The process continues as outlined in [IO]. As an example detailed below are the remaining exchanges when the ISAKMP authentication mode is RSA Signatures: Initiator Responder EAP-Request, uID, Length, EAP-ISAKMP,ISAKMP Hdr, KE, Ni --> <-- EAP-Response, uID, Length, EAP-ISAKMP,ISAKMP Hdr, KE, Nr EAP-Request, uID, Length, EAP-ISAKMP, ISAKMP Hdr*, IDii, --> [CERT, ] SIG_I <-- EAP-Response, uID, Length, EAP-ISAKMP, ISAKMP Hdr*, IDir, [CERT,] SIG_R Upon completion of this exchange the peers have mutually authenticated each other and have arrived at an acceptable ISAKMP SA. If the Initiator does not wish to negotiate PPP encryption or PPP compression using ISAKMP the EAP Success message should be sent to the Responder to signal that the authentication has completed successfully. Initiator Responder EAP-Success, uID, Length --> Carter [Page 4]
INTERNET DRAFT November 19 1997 The EAP-Success message does not require authentication because this has already been provided within ISAKMP. Note ECP and CCP negotiation may still take place, however ISAKMP will not be able to provide session keys unless a phase 1 exchange is followed by at least one phase 2 exchange. If PPP Encryption or Compression is to be used and it is desirable to have session keys for PPP Encryption derived the ISAKMP Initiator MUST begin an ISAKMP/Oakley QUICK_MODE Negotiation after the first ISAKMP SA has been negotiated but BEFORE the first EAP-Success message is sent. Subsequent QUICK_MODE negotiations may occur to freshen the keying material. 4.1 QUICK_MODE Initiator Responder EAP-Request, uID, Length, EAP-ISAKMP, ISAKMP Hdr*,HASH(1), --> SA, Ni [, KE] [, IDui, IDur] <-- EAP-Response, uID, Length, EAP-ISAKMP,ISAKMP Hdr*, HASH(2), SA, Nr [, KE] [, IDui, IDur] EAP-Request, uID, Length, EAP-ISAKMP, ISAKMP Hdr*, HASH(3) --> <-- EAP-Response, uID, Length, EAP-ISAKMP EAP-Success, uID, Length --> Note that in order to maintain the EAP Request - Response exchange format it is necessary for the responder to reply to the Initiators final HASH(3) ISAKMP message. This is done by sending an empty EAP - Response message with type set to EAP-ISAKMP. This message as well as the final EAP - Success message do not require authentication because this has taken place within ISKAMP (HASH payloads). After the QUICK MODE exchange has occurred each entity will posses two security associations, one for inbound traffic and one for outbound traffic. The session keys derived for each direction will be unique. 4.2 ISAKMP with Pre-Shared Keys Carter [Page 5]
INTERNET DRAFT November 19 1997 When ISAKMP/Oakley is used in MAIN MODE (and only MAIN MODE) and the agreed authentication method is Pre-Shared Keys the Initiator MUST take special action in order to assure that both entities have received valid identity information that can be used to identify the correct pre-shared key to use. Therefore after the SA exchange of the ISAKMP SA negotiation in MAIN MODE if the Initiator determines that the agreed ISAKMP authentication method is pre-shared keys the Initiator MUST send an EAP-Identity/Request message to the peer. The EAP-Identity/Request data portion MUST contain an ISAKMP Identity payload with the Initiators identity. The Responder MUST reply with an EAP-Identity/Response with the data portion encapsulating one ISAKMP Identity payload containing the responders identification information. After the Initiator has received the EAP-Identity/Response it continues on with the ISAKMP SA Negotiation. * note * -- Because the entities require the identity information prior to ISAKMP key establishment the Identities are sent in the clear, therefore one of the primary benefits of MAIN MODE, Identity Protection, is lost. If the Initiator believes that the ISAKMP authentication method will likely be Pre-Shared Keys the Initiator SHOULD use ISAKMP/Oakley in AGGRESSIVE MODE. Aggressive mode allows the entities to examine the ISAKMP identity before lookup of the pre-shared key, however at the expense of Identity protection. Initiator Responder EAP-Request, uID, Length, EAP-ISAKMP, ISAKMP Hdr, SA --> <-- EAP-Response, uID, Length, EAP-ISAKMP,ISAKMP Hdr, SA Initiator examines agreed SA and determines Pre Shared Keys are to be used, therefore must send own ID and receive responders ID. EAP-Identity/Request, uID, EAP-ISAKMP, Length, IDii --> <-- EAP-Identity/Response, uID, Length, EAP-ISAKMP, IDir At this point both sides have received the others identity information. The ISAKMP exchange continues. Initiator Responder EAP-Request, ID, Length, EAP-ISAKMP, ISAKMP Hdr, --> Carter [Page 6]
INTERNET DRAFT November 19 1997 KE, Ni <-- EAP-Response, ID, Length, EAP-ISAKMP,ISAKMP Hdr, KE, Nr EAP-Request, ID, Length, EAP-ISAKMP, ISAKMP Hdr*, --> IDii, HASH_I <-- EAP-Response, ID, Length, EAP-ISAKMP, ISAKMP Hdr*, IDir, HASH_R EAP-Success, ID, Length --> 4.3 Informational Exchanges There are two situations where an Informational exchange may take place within ISAKMP/Oakley. These are: Failed SA Establishment All other Notify exchanges, including SA Delete. 4.3.1 Failed SA Establishment When SA establishment fails the entity which has detected the failure may optionally send an ISAKMP notify message to the peer informing the peer of the failure. In the examples below the failure is assumed to occur during phase 1, hence the notify is sent without protection. If the failure were to occur during phase 2 the notify would be sent encrypted with an additional HASH payload to authenticate the message. 4.3.1.1 Responder Side SA Failure If the failure is detected on the Responder the ISAKMP Notify message MUST be sent. The ISAKMP Notify message is sent in the EAP - Response packet. Upon receiving the error Notify the Initiator MUST send an EAP-Failure message. The responder must send a notify in order to comply with the EAP Request - Response exchange. Initiator Responder EAP-Request, uID, Length, EAP-ISAKMP,ISAKMP Hdr, SA --> Responder detects an error and sends back an ISAKMP Notify. <-- EAP-Response, uID, Length, EAP-ISAKMP, ISAKMP Hdr, Notify Carter [Page 7]
INTERNET DRAFT November 19 1997 EAP - Failure - ID - Length --> 4.3.1.2 Initiator Side SA Failure If the failure occurs on the Initiator the Initiator may send an ISAKMP Notify message in an EAP - Request message to notify the peer of the error and provide additional information. The Responder MUST reply to the notify with an EAP - Response with an empty data field. The Initiator then replies with a final EAP - Failure message. If the Initiator does not wish to send an ISAKMP Notify message it MUST immediately send an EAP - Failure message. 4.3.1.2.1 Initiator Side SA Failure with Notify Initiator Responder EAP-Request, uID, Length, EAP-ISAKMP,ISAKMP Hdr, SA --> <-- EAP-Response, uID, Length, EAP-ISAKMP, ISAKMP Hdr, SA Initiator detects a failure, sends back notify. EAP-Request, uID, Length, EAP-ISAKMP, ISAKMP Hdr, Notify --> <-- EAP-Response, uID, Length EAP-Failure, uID, Length --> 4.3.1.2.2 Initiator Side SA Failure without Notify Initiator Responder EAP-Request, uID, Length, EAP-ISAKMP,ISAKMP Hdr, SA --> <-- EAP-Response, uID, Length, EAP-ISAKMP, ISAKMP Hdr, SA Initiator detects a failure, immediately sends back EAP-Failure. EAP-Failure, uID, Length --> Carter [Page 8]
INTERNET DRAFT November 19 1997 4.3.2 Other ISAKMP Notify Exchanges Other types of ISAKMP Notify messages may be sent at any time with ISAKMP. Each notify is sent in side an EAP - Request packet and MUST be acknowledged with an empty EAP - Response packet. Either side may initiate the notify. 4.4 Security Parameter Index and EAP-ISAKMP Neither ECP nor CCP require the use of SPIs, however in order to generate unique keying material derived using QUICK MODE both peers MUST supply an SPI. The SPI MUST be 4 octets in length. The Responder MUST choose an SPI value which is not equal to the Initiators. There are no other restrictions on the SPI. [SHOULD THIS GO IN DOI SECTION?] 4.5 Re-keying and EAP-ISAKMP Since ECP does not use SPIs there needs to be some other way for an entity to signal the other that the most recently negotiated key is now in use. To do this the ECP sequence number is reset to 0 to indicate to the peer that the new key/IV was used to protect the packet. [IS THIS A GOOD IDEA?] 4.6 Fragmentation Refer to [EAP]. [SUGGESTION - MOVE TLS FRAGMENTATION DESCRIPTION TO BASE EAP DOC] 5. EAP Interaction with ECP and CCP When EAP is used with ISAKMP the negotiation phase of ECP and CCP can be bypassed, instead providing the ECP and CCP components of PPP the values negotiated with EAP-ISAKMP. 6. EAP ISAKMP DOI [Note this will become a separate document. For simplicity it is currently combined with this document] For information on EAP-DOI treatments of situation, security policies, and naming schemes please see the IPSEC DOI. The EAP-DOI adds no new information in these areas. 6.1 EAP-ISAKMP Assigned Numbers The EAP type for this protocol is ?. The DOI value for this protocol is ?. Carter [Page 9]
INTERNET DRAFT November 19 1997 The following table lists the values for the Security Protocol Identifiers referenced in the ISKAMP Proposal Payload for the EAP-ISAKMP DOI: Protocol ID Value -------------- ------- RESERVED 0 PROTO_ISAKMP 1 PROTO_PPP_ECP 2 PROTO_PPP_CCP 3 The size of the field is one octet. The values 2-248 are reserved for to IANA. Values 249-255 are reserved for private use. 6.1.1 PROTO_ISAKMP The PROTO_ISKAMP type specifies message protection required during phase 1 of the ISAKMP protocol. The specific protection mechanism used for the EAP DOI is described in [IO]. All implementations within the EAP DOI MUST support PROTO_ISAKMP. NB: ISAKMP reserves the value (1) across all DOI definitions. 6.1.2 PROTO_PPP_ECP The PROTO_PPP_ECP type specifies PPP packet confidentiality usually negotiated during the Encryption Control Protocol phase of PPP establishment. 6.1.3 PROTO_PPP_CCP The PROTO_PPP_CCP type specifies PPP packet compression usually negotiated during the Compression Control Protocol phase of PPP establishment. 6.2 PPP ISAKMP Transform Values These values are the same as those defined in the IPSEC DOI section 4.4.2. 6.3 PPP ECP Transform Values The ECP protocol currently defines two transform values, neither is mandatory, used to provide confidentiality of PPP datagrams. The following table lists the defined PPP ECP transform identifiers for the ISAKMP Proposal Payload for the PPP DOI: Carter [Page 10]
INTERNET DRAFT November 19 1997 Transform ID Value ---------------- ------- ECP_OUI 0 ECP_DESE 1 ECP_DESE_BIS 2 The size of the field is one octet. The values 4-254 are reserved to IANA. 6.3.1 ECP_OUI The ECP_OUI type specifies a proprietary encryption transform. The ECP_OUI type MUST be accompanied by an Encryption OUI attribute which further identifies the specific vendor algorithm and parameters. 6.3.2 ECP_DESE The ECP_DESE type specifies the DESE transform detailed in RFC1969. This value may be negotiated for compatibility with older systems. The ECP_DESE type MUST be accompanied by an Encryption Nonce attribute. 6.3.3 ECP_DESE_BIS The ECP_DESE_BIS type specifies the DESE transform detailed in draft- ietf-pppext-des-encrypt-v2-00.txt. Implementations are encouraged to support this transform. The ECP_DESE_BIS type MUST be accompanied by an Encryption Nonce attribute. Note however that this value is chosen by the Initiator (the responder can not specify a value to use for its IV generation), however since ISAKMP/Oakley in Quick Mode derives unique keys for each entity the resulting IV will be different for traffic to each peer. Therefore uniqueness of IVs is preserved 6.4 PPP CCP Transform Values The CCP protocol currently defines a number of transform values, none of which are mandatory, used to provide compression of PPP datagrams. The following table lists the defined PPP CCP transform identifiers for the ISAKMP Proposal Payload for the PPP DOI: Carter [Page 11]
INTERNET DRAFT November 19 1997 Transform ID Value ---------------- ------- 0 OUI 1 Predictor type 1 2 Predictor type 2 3 Puddle Jumper 4-15 unassigned 16 Hewlett-Packard PPC 17 Stac Electronics LZS 18 Microsoft PPC 19 Gandalf FZA 20 V.42bis compression 21 BSD LZW Compress 255 Reserved The size of the field is one octet. Values 22-254 are reserved by IANA. 6.4.1 CCP_OUI The CCP_OUI type specifies a proprietary encryption transform. The CCP_OUI type MUST be accompanied by a Compress OUI attribute which further identifies the specific vendor algorithm and parameters. 6.4.2 CCP_PREDICTOR_1 Identifies the compression transform detailed in RFC1978. 6.4.3 CCP_PREDICTOR_2 Identifies the compression transform detailed in RFC1978. 6.4.4 CCP_PUDDLE_JUMPER ? 6.4.5 CCP_HP_PCC Identifies the compression transform detailed in [HPPPC]. 6.4.6 CCP_STAC_LZS Identifies the compression transform detailed in RFC1974. 6.4.7 CCP_MS_PPC Identifies the compression transform detailed in RFC2118. 6.4.8 CCP_GANDALF_FZA Identifies the compression transform detailed in RFC1993. 6.4.9 CCP_V42_BIS Carter [Page 12]
INTERNET DRAFT November 19 1997 Identifies the compression transform detailed in ? 6.4.10 CCP_ BSD_LZW Identifies the compression transform detailed in RFC1977. 6.5 EAP Security Association Attributes The following SA attribute definitions are used in phase 2 of an ISAKMP/Oakley negotiation. Attribute types can be either Basic (B) or Variable-Length (V). Encoding of these attributes is defined in the base ISAKMP specification. Attribute Classes: Class Value Type ------ ------- ------- SA Life Type 1 B SA Life Duration 2 B/V Group Description 3 B Key Length 4 B Key Rounds 5 B Compress Dictionary Size6 B Compress OUI 7 V Encryption Nonce 8 V Encryption OUI 9 V Session ID 10 B/V The size of the attribute class field is two octets, with the high bit reserved for ISAKMP B/V encoding indicator. The values 10 - 32000 are reserved for IANA, values 32001 - 32767 are for experimental use. Class Values SA Life Type SA Duration Specifies the time to live for the overall security association. When the SA exipers, all keys negotiated under the association (PPP_ECP) must be renegotiated. The life type values are: RESERVED 0 Seconds 1 kilobytes 2 Values 3-61439 are reserved for IANA. Values 61440 - 65535 are for experimental use. For a given life type the value of the life duration attribute defines the actual length of the component lifetime either a number of seconds, or a number of kilobytes that can be Carter [Page 13]
INTERNET DRAFT November 19 1997 protected/compressed. If unspecified the default value shall be assumed to be 28800 seconds (8 hours). Group Description RESERVED 0 Group 1 - 768 Prime 1 Group 2 - 1024 Prime 2 Values 2-61439 are reserved for IANA. Values 61440 - 65535 are for experimental use. This attribute is used for PFS in phase 2 negotiations. See ISAKMP/Oakley for a description of the Diffie - Hellman parameters which make up these groups. If PFS is desired this attribute MUST be sent. Key Length RESERVED 0 There is no default value for Key Length. It is used for ECP Transforms which have variable length keys. However transform documents may define a default value for the particular transform. Key Rounds RESERVED 0 There is no default value for Key Rounds. It is used for ECP Transforms which have variable key rounds. However transform documents may define a default value for the particular transform. Compression Dictionary Size RESERVED 0 Specifies the log2 maximum size of the dictionary. There is no default value. Compression OUI Specifies a private vendor compression algorithm using the vendors Organization Unique Identifier. The first three (3) octets MUST be the most signification three (3) octets of an Ethernet Physical Address, assigned to the vendor by IEEE 802. The next octet may be vendor specific compression algorithm subtype, followed by zero or more octets Carter [Page 14]
INTERNET DRAFT November 19 1997 of vendor data. This attribute MUST accompany requests for transforms of type CCP_OUI. Encryption Nonce Supplied by the Initiator to the Responder. This value is used in the calculation of the initial IV for PPP_ECP encryption. This attribute MUST accompany requests for transforms of type ECP_DESE and ECP_DESE_BIS. Encryption OUI Specifies a private vendor encryption algorithm using the vendors Organization Unique Identifier. The first three (3) octets MUST be the most signification three (3) octets of an Ethernet Physical Address, assigned to the vendor by IEEE 802. The next octet may be vendor specific encryption algorithm subtype, followed by zero or more octets of vendor data. This attribute MUST accompany requests for transforms of type ECP_OUI. Session ID Multilink sessions may be setup between the EAP peer and the authenticator. To avoid repeated authentication during multilink setup the EAP server MAY provide a Session ID during the first EAP SA establishment (EAP authenticator always initiates first EAP SA). The EAP peer MAY include the Session ID in subsequent EAP SA negotiations where it acts as the Initiator. 6.5.1 Required Attribute Support To ensure basic interoperability all implementations MUST be prepared to negotiate all of the following attributes: SA Life Type SA Duration Encryption Nonce 6.6 Payload Specifications This DOI does not define any new payload formats other than those defined in the IPSEC DOI. See IPSEC DOI. 6.7 EAP Key Exchange Types Carter [Page 15]
INTERNET DRAFT November 19 1997 This DOI defines no new key exchange types. 7.0 Security Considerations 7.1 Revocation Data If ISAKMP is used with a certificate scheme supporting revocation an EAP authenticator MUST be prepared to provide revocation lists to the EAP peer if the EAP peer requests those lists within ISAKMP. This allows an otherwise off-line client to obtain the necessary revocation information it needs to validate the EAP authenticators certificate. 7.2 Pass Through EAP and EAP Servers EAP discusses the use of a back-end security server allowing EAP data to pass through the NAS on to the server performing the actual EAP authentication. At this time no IETF standard exists which allows the exchange between the NAS and EAP Server to posses the same degree of security as that offered by ISAKMP/Oakley. Therefore it is REQUIRED that if EAP-ISAKMP is to be used with a back-end security server that the link between the NAS and the security server be protected with IPSec or another comparable protocol which provides full packet authentication and confidentiality. If this condition is meet then the session keys derived on the security server may be passed to the NAS. 8. Acknowledgments This document is the result of combining EAP with ISAKMP/Oakley, it borrows heavily from EAP-TLS and from IPSEC DOI. 9. Copyright notice Copyright (C) The Internet Society, 1997. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Carter [Page 16]
INTERNET DRAFT November 19 1997 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Carter [Page 17]
INTERNET DRAFT November 19 1997 10.0 References [RFC1661] Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 1661. [RFC1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, Spider Systems, June 1996. [RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, Novell, June 1996. [EAP] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication Protocol (EAP)." Work in progress, draft-ietf- pppext-eap-auth-02.txt, Merit Network, Inc., June 1996. [EAPTLS] B. Aboba, D. Simon, "PPP EAP TLS Authentication Protocol", Work in progress, draft-ietf-pppext-eaptls-02.txt, Microsoft, October 1997. [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)," Work in progress, draft-ietf-ipsec-isakmp-08.{ps,txt}. [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," Work in progress, draft-ietf-ipsec-oakley-01.txt. [IO] Harkins, D., Carrel, D., "The Resolution of ISAKMP with Oakley," Work in progress, draft-ietf-ipsec-isakmp-oakley-04.txt. [RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2058, January 1997. [HPPPC] Petty, J., "PPP H-P Packet-by-Packet Compression Protocol", Work in progress, draft-ietf-pppext-hpppc-00.txt. 11. Authors' Addresses Greg Carter Entrust Technologies 750 Heron Road, Suite E08 Ottawa, Ontario Canada, K1V 1A7 email: greg.carter@entrust.com Carter [Page 18]
INTERNET DRAFT November 19 1997 A Aggressive Mode ISAKMP Detailed below is ISAKMP in AGGRESSIVE MODE using an authentication method of Signatures. Initiator Responder EAP-Request, uID, Length, EAP-ISAKMP,ISAKMP Hdr, SA, --> KE, Ni, IDii The Responder replies by choosing an acceptable ISAKMP SA (see [ISAKMP], [IO]) and sends back an EAP Response packet. Initiator Responder <-- EAP-Response, uID, Length, EAP-ISAKMP, ISAKMP Hdr, SA, KE, Nr, IDir, [CERT,] SIG_R EAP-Request, uID, Length, EAP-ISAKMP,ISAKMP Hdr, --> [CERT,] SIG_I <-- EAP-Response, uID, Length In the final response from the Responder an empty EAP-Response packet is sent. Carter [Page 19]
