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 other’s 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 IV’s 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 authenticator’s 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]