[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

IPSRA Working Group                                           Y. Sheffer
INTERNET-DRAFT                                                 Personeta
Category: Standards Track                                    H. Krawczyk
<draft-ietf-ipsra-pic-06.txt>                                   Technion
9 October 2002                                             Bernard Aboba
                                                               Microsoft


            PIC, A Pre-IKE Credential Provisioning Protocol

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

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

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.

Copyright Notice

Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

This document presents a Pre-IKE Credential (PIC) provisioning protocol.
PIC is a method to bootstrap IPsec authentication via an "Authentication
Server" (AS) and user authentication mechanisms such as RADIUS. PIC
happens before IKE (the Internet Key Exchange protocol).  The client
machine communicates with the AS using a key exchange protocol where
only the server is authenticated, and the derived keys are used to
protect the user authentication.  Once the user is authenticated, the
client machine obtains credentials from the AS that can be later used to
authenticate the client in a standard IKE exchange, with no user
intervention. The proposed key exchange is based on ISAKMP (the Internet
Security Association and Key Management Protocol), similar to a
simplified IKE exchange. Arbitrary user authentication is supported via
the use of EAP (the PPP Extensible Authentication Protocol).



Sheffer, Krawczyk & Aboba    Standards Track                    [Page 1]

INTERNET-DRAFT                     PIC                    9 October 2002


Table of Contents

1.     Introduction ..........................................    3
   1.1       Requirements language ...........................    4
   1.2       Protocol entities ...............................    5
   1.3       PIC Protocol Overview ...........................    6
2.     Assumptions and Requirements ..........................    6
3.     PIC and ISAKMP ........................................    7
   3.1       The PIC Exchange ................................    7
   3.2       The PIC Transform ...............................    7
   3.3       ISAKMP Message ID ...............................    7
   3.4       Protection of Payloads ..........................    7
   3.5       Informational Exchanges and Payloads ............    8
4.     The PIC Protocol ......................................    8
   4.1       Transport .......................................    8
   4.2       Retransmission policy ...........................    8
   4.3       ISAKMP Payloads .................................    9
   4.4       Protocol Exchanges ..............................   14
5.     Security Considerations ...............................   19
6.     Intellectual Property Rights ..........................   20
7.     Normative References ..................................   20
8.     Non-normative References ..............................   21
9.     IANA Considerations ...................................   22
Appendix A - Design Considerations ...........................   24
Acknowledgments ..............................................   29
Author's Addresses ...........................................   29
Full Copyright Statement .....................................   30

Change log

-00: Initial version, schematic.
-01: Much more detail, changed XAuth to EAP.
-02: Added rationale sections. Modified hash computation, eliminated payload
     encryption in message (2), added section on retransmission.
-03: Moved rationale into an appendix. Shortened the discussion on retransmission.
-04: Introduced optional transport over TCP to avoid packet fragmentation. Added
     another message round for DoS protection. Hash computations now include the
     complete ISAKMP header. Better handling of authentication failures.
-05: Added detail to the IANA Considerations section. Changed the term "legacy
     authentication server" to "back-end authentication server".
-06: Some modifications following IESG review, mainly IANA issues.
     Several EAP-related changes.









Sheffer, Krawczyk & Aboba    Standards Track                    [Page 2]

INTERNET-DRAFT                     PIC                    9 October 2002


1.  Introduction

IKE [RFC2409] provides cryptographic mechanisms to bootstrap secure
IPsec associations between IP peers. However, for this IKE requires that
the peers possess strong secret keys (symmetric or asymmetric).
Therefore IKE does not accommodate scenarios where authentication is to
be bootstrapped from a user password or other equally weak key material.
Since the later form of authentication is something many commercial
applications still require, the IPSRA WG of the IETF was chartered with
the task to develop cryptographic mechanisms that will complement IKE by
enabling the bootstrapping of IPsec secure associations based on "legacy
user authentication" methods.

There have been several proposals to integrate legacy authentication
directly into IKE, such as [XAUTH], [CRACK], [HYBRID]. These mechanisms
define new authentication modes for IKE, an approach that is precluded
by the IPSRA charter.  Recently, Bellovin and Moskowitz [GETCERT]
proposed an alternative approach, namely, to offload the legacy
authentication task into a separate server, called an Authentication
Server (AS), which upon user authentication will provide the client
machine with credentials (based on strong keys) that allow for standard
IKE authentication. Such a process consists of a first phase where the
client machine (from which the user communicates) contacts the AS in
order to receive IKE-acceptable credentials (either public key
certificates or a strong shared key), and a second phase in which the
client machine contacts a regular IKE/IPsec security gateway and uses
these credentials in a regular IKE run for establishing secure IPsec
associations.

While this approach necessitates a large number of round-trips before an
IPsec association is established (i.e., it involves the interaction with
the AS in addition to the normal interaction under IKE), it is the most
viable solution under the IPSRA requirement of not changing IKE and not
adding new modes to it.  This approach based on a separate AS enjoys
several benefits:

[1]  The security gateway may implement IKE/IPsec only, without worrying
     about user authentication.  The same gateway can be deployed in
     PKI-based and legacy-based organizations.

[2]  Transition from a legacy-based solution implemented through a
     separate AS to the more scalable and desirable PKI-based
     authentication supported by IKE is straightforward: just eliminate
     the AS phase.

[3]  A denial-of-service attack on the AS cannot compromise existing
     connections at the gateway (thus alleviating the damage of such
     attacks).



Sheffer, Krawczyk & Aboba    Standards Track                    [Page 3]

INTERNET-DRAFT                     PIC                    9 October 2002


[4]  The AS may or may not be co-located with a gateway, per the
     organization's policy.  A separate AS off-loads the security
     gateway but may involve extra cost.

[5]  By providing a client machine with short-term credentials, a
     "single sign-on" approach can be supported where authentication
     using these credentials can be performed several times, over a
     short period of time, without involving repeated manual
     intervention by the user.

The PIC protocol described in this document realizes this approach and
secures it using simplified ISAKMP and IKE mechanisms. The protocol
embeds Extensible Authentication Protocol (EAP) messages [RFC2284] in
ISAKMP payloads to support multiple forms of user authentication. Once
this user authentication succeeds, the client machine obtains from the
AS credentials that can be later used by the client to perform regular
IKE authentication with an IPsec-enabled gateway. PIC defines several
forms of credentials and can be extended to support others. Note that
this document uses the term "credentials" for both digital certificates
and shared secret keys.

It should be emphasized that PIC requires no modification to IKE.
Instead it uses simplified elements of ISAKMP and IKE to obtain a much
less ambitious goal than general IKE, namely the secure provisioning of
credentials for successfully authenticated users. The direct use of IKE,
e.g. as compared to TLS tunneling [GETCERT], reduces complexity and
contributes to the efficiency of the protocol.

Note: EAP is a general authentication protocol, designed to allow end-
points to use multiple forms of authentication.  EAP does not require
the server (typically a PPP or IEEE 802 end-point) to authenticate the
client itself, rather it allows the server to proxy authentication
messages to a back-end authentication server, and inspect the packets to
determine if the authentication was successful. The reader is referred
to [RFC2284] for more details on EAP.

1.1.  Requirements language

In this document, the key words "MAY", "MUST,  "MUST  NOT",  "optional",
"recommended",  "SHOULD",  and  "SHOULD  NOT", are to be interpreted as
described in [RFC2119].










Sheffer, Krawczyk & Aboba    Standards Track                    [Page 4]

INTERNET-DRAFT                     PIC                    9 October 2002


1.2.  Protocol entities

User The human being at the client machine.

Client
     A client machine which communicates with the authentication server
     and the security gateway.

Authentication server (AS)
     A server at the organization which can relay the user's
     authentication request to the legacy system.

Back-end authentication server
     A RADIUS server, LDAP server and the like, which the AS uses to
     authenticate the user.

Security gateway (GW)
     An IKE-enabled IPsec gateway.

The figure below presents the relations between the entities. Note that
any of the entities may be replicated for reliability. Such redundancy
mechanisms are outside the scope of this document.

                   |====|     |======================|
              |====| AS |=====| Back-End Auth Server |
              ||   |====|  || |======================|
              ||     ||    ||
              ||     ||    ||                |====|
              ||     ||    |== (Optional) ===| CA |
              ||     ||                      |====|
              ||     ||
 ==========   ||   (optional
 | Client |===||     link)
 ==========   ||     ||
              ||   |====|
              |====| GW |
                   |====|

The PIC protocol is defined between the Client and the AS. All other
exchanges between the entities are implicit in the protocol and not
defined here. This applies in particular to user and machine
authentication between AS and Back-End Authentication Server, and
certification between AS and the CA.








Sheffer, Krawczyk & Aboba    Standards Track                    [Page 5]

INTERNET-DRAFT                     PIC                    9 October 2002


1.3.  PIC Protocol Overview

The four main stages of the proposed protocol are:


[1]  An optional round of messages provides partial protection of the AS
     from denial-of-service attacks by verifying that the initiator of
     the exchange is reachable at the purported source IP address. This
     is done before any significant CPU or memory resources are consumed
     by the AS.

[2]  The protocol establishes a one-way authenticated channel from the
     client to the AS in which only the server is authenticated.

[3]  User authentication is performed over this secured channel. User
     authentication information is transported using EAP [RFC2284]
     tunneled within ISAKMP.

[4]  The AS sends the client a (typically short-term) credential which
     can be used in subsequent IKE exchanges. This credential can be
     thought of as a certificate, or a private key generated or stored
     by the AS and accompanied by a corresponding certificate. It may
     also be a symmetric secret key, or other information for deriving
     such a key.

     To minimize the number of messages exchanged in PIC, the different
     stages share messages, and the protocol takes care to ensure
     security of the fourth stage despite the fact that it is started
     while the client is not yet authenticated.

2.  Assumptions and Requirements

The basic underlying requirements and assumptions in PIC's design are as
follows (derived from the IPSRA WG set of requirements).

[1]  The back-end authentication server software and database cannot be
     modified. They can only be accessed in a "black-box" way according
     to the existing interface (e.g., one cannot retrieve a user's
     password stored in such a database).

[2]  It is assumed that the Client possesses (e.g. by pre-configuration)
     the public key of the AS, or it has the means to obtain and
     validate a certificate for the AS (e.g., by pre-configuration of a
     CA public key).

[3]  No secret key is assumed at the client beyond legacy user
     authentication material (password). In particular, "machine
     authentication" is not supported.



Sheffer, Krawczyk & Aboba    Standards Track                    [Page 6]

INTERNET-DRAFT                     PIC                    9 October 2002


[4]  The protocol should not require any changes to IKE or to security
     gateways that support standard IKE and IPsec.

[5]  The protocol should provide a solution that supports easy
     transition to certificate-based authentication.

[6]  User authentication involves interaction with the human user and
     should be made as painless as possible. Repeated manual entry of
     credentials, e.g. passwords, should be avoided if at all possible.

[7]  The server should be protected against denial of service (DoS)
     attacks, involving both excessive CPU consumption and excessive
     memory consumption. If possible, adaptive DoS protection at the
     discretion of the server is preferred, similar to the one defined
     in the Oakley protocol [RFC2412].

3.  PIC and ISAKMP

PIC is based on ISAKMP [RFC2408] and the ISAKMP IPsec DOI [RFC2407],
with a few minor additions.

The SA created during the first exchange of PIC MUST NOT be used for any
messages other than the PIC messages described here. The SA MUST be
destroyed when the PIC exchange is concluded.

3.1.  The PIC Exchange

PIC defines a new ISAKMP exchange. This number will be allocated by
IANA.

3.2.  The PIC Transform

PIC defines a new IPsec ISAKMP Transform Identifier, KEY_PIC, for the
Proposal payload, since KEY_IKE implies mutual authentication while PIC
only provides unilateral authentication during the first exchange.

The value of KEY_PIC is 2. It should be reserved by IANA.

3.3.  ISAKMP Message ID

The Message ID field in the ISAKMP header must be 0 for all PIC
messages.  This is similar to phase 1 exchanges.

3.4.  Protection of Payloads

The new ISAKMP payloads defined below are protected in two different
ways:




Sheffer, Krawczyk & Aboba    Standards Track                    [Page 7]

INTERNET-DRAFT                     PIC                    9 October 2002


[1]  In message (2) of the protocol, the EAP payload is integrity-
     protected but not encrypted.

[2]  In all the following messages, the entire message is encrypted.

In both cases, a MAC is computed over the plaintext payloads. This
special processing of the second message results from our desire to stay
within the current framework of ISAKMP processing, while reducing the
protocol's number of messages to the minimum. See Sec. A.1 for a
justification of the lack of confidentiality-protection in message (2).

3.5.  Informational Exchanges and Payloads

ISAKMP Informational exchanges are allowed at any point during PIC.
Notification and Vendor ID payloads MAY be inserted at any point in
message (1). In all other messages, they MAY be inserted at any point
following the HASH payload.

No new Notification types are defined in PIC.

4.  The PIC Protocol

4.1.  Transport

The PIC protocol is an ISAKMP exchange. ISAKMP implementations MUST
support transport over UDP, and similarly for PIC implementations.  The
PIC port will be allocated by IANA.

At the time of writing, the issues of NAT traversal are still unresolved
in the context of IKE and IPsec. PIC will adopt whatever decision is
taken for IKE. In the meantime, the server MUST listen on the PIC port.
The server SHOULD NOT assume the UDP source port for incoming PIC
messages is equal to the PIC port, and SHOULD use the actual source port
number when it replies.

A PIC implementation deployed in the open Internet SHOULD also support
transport over TCP.  This is the only practical solution today that
enables the use of long certificates and certificate chains within PIC.
See Sec. A.6 for further discussion.

4.2.  Retransmission policy

PIC adopts the ISAKMP retransmission strategy. The retransmission
policies in EAP and ISAKMP differ, in that in EAP only the server
retransmits, while in ISAKMP both sides can retransmit. The solution we
have chosen is to completely eliminate retransmission at the EAP layer.





Sheffer, Krawczyk & Aboba    Standards Track                    [Page 8]

INTERNET-DRAFT                     PIC                    9 October 2002


The interface between ISAKMP and EAP SHOULD be engineered so that ISAKMP
serves as a transport providing EAP with a reliable and non-duplicate
stream of packets. Since [RFC2284] indicates that EAP-Responses MUST NOT
be retransmitted, this implies that ISAKMP will not provide such
duplicates to the EAP layer.

Since the ISAKMP layer will be handling retransmission, it is not
necessary for retransmission to also occur in the EAP layer. It is
recommended that the EAP retransmission timers be set longer than the
maximum ISAKMP re-transmission timers, so that retransmission at the EAP
layer will not occur.

4.3.  ISAKMP Payloads

PIC defines several new payloads:

[1]  EAP. To embed EAP messages within ISAKMP.

[2]  CREDENTIAL-REQUEST. Allows the client to request a credential.

[3]  CREDENTIAL. Allows the AS to return a credential.

The following sections define each of the payloads.

4.3.1.  The EAP Payload

The EAP payload is defined to embed EAP messages. Its payload type is
TBD by IANA.  The payload's format is:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |   RESERVED    |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Sequence    !                   RESERVED                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                         EAP Message                           ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+











Sheffer, Krawczyk & Aboba    Standards Track                    [Page 9]

INTERNET-DRAFT                     PIC                    9 October 2002


The EAP Payload fields are defined as follows:

Next Payload

   The Next Payload field is a single octet and identifies the payload
   type of the next payload in the message. If the current payload is
   the last in the message, then this field will be 0.

RESERVED

   A single octet field, must be 0.

Payload length

   Payload length is a two octet field. It represents the length in
   octets of the current payload, including the generic payload header,
   the transaction-specific header and the embedded message. If the
   length does not match the length of the payload headers plus the
   embedded message, then the entire payload MUST be discarded.

Sequence

   The Sequence field is a single octet. It represents the sequence
   number of EAP payloads in the current exchange, starting at 1. A
   single payload sequence is maintained between the Client and Server.

RESERVED

   A three octet field, must be 0.

EAP Message

   This field is of undetermined length. It includes an EAP message as
   defined in [RFC 2284], including any later additions to the standard.
   This includes the Code, Identifier, Length and Data fields.
















Sheffer, Krawczyk & Aboba    Standards Track                   [Page 10]

INTERNET-DRAFT                     PIC                    9 October 2002


4.3.2.  The CREDENTIAL-REQUEST Payload

The CREDENTIAL-REQUEST payload is defined to allow the client to request
a credential.  Its payload type is TBD by IANA. Its format is:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |   RESERVED    |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Subtype     |           RESERVED            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   Type-Specific Information                   ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Payload

   A single octet field, providing the payload type of the next payload
   in the message.  If the current payload is the last in the message,
   then this field will be 0.

RESERVED

   A single octet field, must be 0.

Payload length

   Payload length is a two octet field. It represents the length in
   octets of the current payload, including the generic payload header,
   the transaction-specific header and any additional information.  If
   the length does not match the length of the payload headers plus
   additional information, then the entire payload MUST be discarded.

Type

   A single octet field, denoting the type of credential. Values are:

   Value       Description
   -----       -----------
   0           None.
   1           The Client provides a public key and a certificate
               request for that key. The AS responds with a
               certificate for the Client.
   2           The AS provides a pair of private key and certificate
               for the Client.
   3           The AS provides a shared secret. This type is reserved



Sheffer, Krawczyk & Aboba    Standards Track                   [Page 11]

INTERNET-DRAFT                     PIC                    9 October 2002


               for future use.
   4-127       Reserved for future versions.
   128-255     Reserved for private use.

   The value None MUST NOT be sent.

Sub-type

   A single octet field, denoting the specific type of certificate.
   This is only applicable when the Type field is 1 or 2. Otherwise, the
   value is 0. Values are as defined in the ISAKMP CERTIFICATE payload
   (Sec. 3.9 of [RFC2408]).  The value None MUST NOT be sent.

RESERVED

   A two octet field, must be 0.

Type-Specific Information

This is a variable field, whose contents depend on the Type and Subtype
fields.  This version of the protocol defines the contents for 3 cases
only.

Type 1, Subtype 1
     PKCS #7 [RFC2315] wrapped X.509 certificate. This field contains a
     certificate request in PKCS #10 [RFC2314] format
     (CertificationRequest). The receiver MUST verify correctness of the
     "signature" component, which proves possession of the private key
     corresponding to the public key being certified.

Type 1, Subtype 4
     X.509 Certificate - Signature. This field contains a certificate
     request in PKCS #10 [RFC2314] format (CertificationRequest). The
     receiver MUST verify correctness of the "signature" component,
     which proves possession of the private key corresponding to the
     public key being certified.

Type 2, Subtype 4
     For this type and subtype the field is omitted.

All other Type-Subtype combinations are undefined.  They MUST NOT be
sent, and MUST be rejected if received.









Sheffer, Krawczyk & Aboba    Standards Track                   [Page 12]

INTERNET-DRAFT                     PIC                    9 October 2002


4.3.3.  The CREDENTIAL Payload

The CREDENTIAL payload is defined to allow the AS to send various types
of credentials.  Its payload type is TBD by IANA. Its format is:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  !   RESERVED    !         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     !   Subtype     !            RESERVED           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   Type-Specific Information                   ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Payload

   A single octet field, providing the payload type of the next payload
   in the message.  If the current payload is the last in the message,
   then this field will be 0.

RESERVED

   A single octet field, must be 0.

Payload length

   Payload length is a two octet field. It represents the length in
   octets of the current payload, including the generic payload header,
   the transaction-specific header and any additional information. If
   the length does not match the length of the payload headers plus
   additional information, then the entire payload MUST be discarded.

Type

   Type is a one octet field, denoting the type of credential.  Values
   are as defined for the CREDENTIAL-REQUEST payload.  The value None
   means that a credential according to the Client's request is not
   available. The entire PIC exchange is failed, and any further
   behavior is outside the scope of this document. Reserved values MUST
   be rejected by the receiver.

Sub-type

   A single octet field, denoting the specific type of certificate.
   This is only applicable when the Type field is 1 or 2. Otherwise, the



Sheffer, Krawczyk & Aboba    Standards Track                   [Page 13]

INTERNET-DRAFT                     PIC                    9 October 2002


   value is 0. Values are as defined in the ISAKMP CERTIFICATE payload
   (Sec. 3.9 of [RFC2408]).

RESERVED

   A two octet field, must be 0.

Type-Specific Information

This is a variable field, whose contents depend on the Type and Subtype
fields.  This version of the protocol defines the contents for 3 cases
only.

Type 1, Subtype 1
     PKCS #7 wrapped X.509 certificate.  This field contains a
     certificate or certificate chain in PKCS#7 [RFC2315] format.

Type 1, Subtype 4
     X.509 Certificate - Signature. This field contains an X.509
     certificate.

Type 2, Subtype 4
     The Information field contains a private key and corresponding
     certificate, wrapped in a PKCS #12 [PKCS12] PFX PDU.

     Note: for Type 2, it is up to the server's local policy to decide
     whether a certificate is fetched from storage or generated from new
     material.

All other Type-Subtype combinations are undefined.  They MUST NOT be
sent, and MUST be rejected if received.

4.4.  Protocol Exchanges

The protocol consists of a variable number of messages, with a minimum
of 4 messages.

As in ISAKMP, '*' signifies payload encryption after the ISAKMP header.
This encryption MUST begin immediately after the ISAKMP header and all
payloads following the ISAKMP header MUST be encrypted.

As in ISAKMP, payload_b denotes the base payload, stripped of its
generic ISAKMP header.








Sheffer, Krawczyk & Aboba    Standards Track                   [Page 14]

INTERNET-DRAFT                     PIC                    9 October 2002


4.4.1.  Establishing the PIC SA: Messages (1'), (2'), (1) and (2)

These messages, which establish the PIC SA for protection of all
following messages, are adopted from IKE Aggressive Mode with Signature
Authentication, with the addition of a DoS-defense mechanism via a
"routability cookie".

     Client                              AS
     ------                              --

(1') HDRi, SA, KE, Ni [, IDii]      ==>

(2')                                <==  HDRr, Nrc

(1)  HDRi, SA, KE, Ni, Nrc [, IDii] ==>

(2)                                 <==  HDRr, SA, KE, Nr, IDir,[ CERT, ]
                                         SIG_R, HASH, EAP

These messages establish the PIC SA for all the following messages.

The pair of messages (1') and (2') is introduced to protect the AS from
DoS attacks, by verifying that the sender is indeed reachable at the
purported IP address, before any CPU resources or memory are consumed.

When receiving message (1'), the server decides according to its
security policy whether DoS protection is to be enforced. This decision
can be based on dynamic factors, such as the momentary load on the AS,
and the source IP address of the packets received.  If DoS protection is
enforced, the server discards message (1'), computes Nrc (per Sec. 4.4.3
below) and replies with message (2').  We note that the AS is stateless
at this point with respect to this session. The Client MUST include an
identical Nrc payload in its message (1), and the AS MUST verify the
validity of this payload.  If no DoS protection is desired, the AS
treats message (1') as if it were message (1), and replies with message
(2).

Implementation note: message (1') is small enough that on typical
transports, it need not be fragmented. It is RECOMMENDED that an
implementation use the technique proposed in Sec. 2.6 of [IKEv2] to
provide information to the IP reassembly layer, in order to prevent
fragmentation DoS attacks.

Refer to Sec. 5.1 of [RFC2409] and Sec. 3 of [RFC2408] for a description
of the payloads.  The field Nrc("routability cookie") which is not part
of IKE is defined here as an ISAKMP Nonce Payload and its contents are
described below. The value SKEYID and its derivatives SKEYID_a, SKEYID_d
and SKEYID_e are computed in the exact same way as defined in Sec. 5 of



Sheffer, Krawczyk & Aboba    Standards Track                   [Page 15]

INTERNET-DRAFT                     PIC                    9 October 2002


[RFC2409] for the case of signature authentication. Similarly for the
Initialization Vector (IV), when applicable.  SA encryption keying
material is derived as in [RFC2409], Appendix B. Note that SKEYID_d is
not used here and is discarded after the other derived keys are
computed.

The Transform Identifier in the SA payloads MUST be KEY_PIC. The
Authentication Method in the SA payload MUST be RSA Signatures or DSS
Signatures. Proposal negotiation takes place as in [RFC2409], for Phase
1.

Payloads are ordered as in Sec. 5 of [RFC2409], for Aggressive Mode with
Signatures.

SIG_R is derived from HASH_R, as in [RFC2409]. HASH_R is computed
differently in PIC. It includes both initiator's and responder's SA
payloads (in particular, this corrects a typo in [RFC2409]) and the
complete ISAKMP headers.

HASH_R = PRF(SKEYID, g^xr | g^xi | HDRi | SAi_b [| IDii_b]|
         HDRr | SAr_b | IDir_b)

IDii MUST be included in HASH_R if it was sent by the Client.

The Client MUST validate the correctness of the SIG_R payload. If a
certificate is transmitted, the Client MUST verify that it is trusted.

HASH_R may differ from the illustration above if any optional payloads,
for example a notify payload, have been included in message (1) (at any
location) or (2) (at any location up to the SIG_R payload). In such
cases HASH_R MUST include all such payloads, and in the order they
appear, possibly interleaved with the mandatory payloads.

The HASH payload is calculated over the ISAKMP header, and the
concatenated (plaintext) EAP payload:

HASH = PRF(SKEYID_a, HDRr | EAP_b)

The HASH may differ from the illustration above if any optional
payloads, for example a notify payload, have been included in the
message. In such cases the HASH MUST include all such payloads, and in
the order they appear, before or after the EAP payload. HASH is computed
over all optional payloads following SIG_R.

The EAP payload in message (2) is not encrypted, as explained in Sec.
A.1, however, it is integrity-protected.





Sheffer, Krawczyk & Aboba    Standards Track                   [Page 16]

INTERNET-DRAFT                     PIC                    9 October 2002


4.4.2.  Messages (3) and (4)

Messages (3) and (4) may be repeated as required by the user
authentication method, alternating between the Client and the AS, that
is, message (3) is always followed by message (4) and vice versa.

     Client                            AS
     ------                            --

(3)  HDR*, HASH, EAP            ==>
     [CREDENTIAL-REQUEST]

(4)                             <==   HDR*, HASH, EAP
                                      [CREDENTIAL]

     [Repeat of message (3)     ==>

                                <==   Repeat of message 4]...

Both Client and AS MUST verify correctness of the Sequence field in the
received EAP payload. This is to prevent replay of these payloads. The
Sequence numbers should be strictly consecutive from one EAP payload to
the next.

If an IDii payload was sent by the Client in message (1), the AS SHOULD
match it against a Response/Identity EAP message, if one is received.
This document does not specify the mapping between the two identities.

A CREDENTIAL-REQUEST payload MUST be sent exactly once, in the first
message (3) sent by the Client. When user authentication succeeds, a
CREDENTIAL payload MUST be sent exactly once, in the last message sent
by the AS. If user authentication was unsuccessful (e.g.  a method-
specific failure message or an EAP Failure was sent), a CREDENTIAL
payload MUST NOT be sent.

The Server SHOULD NOT process the CREDENTIAL-REQUEST before the Client
completes its authentication, i.e. just before the AS sends the EAP
Success message (or an equivalent method-specific message).  This is to
protect against denial of service by a yet-unauthenticated client.

The protocol does not define how the AS produces the CREDENTIAL payload,
whether internally, in cooperation with a gateway or with a CA. However,
the Type/Subtype combination for the CREDENTIAL MUST be the same as in
the CREDENTIAL-REQUEST, unless the Type returned is None (no credential
is available).

The HASH payload is defined over the ISAKMP header and the concatenated
payloads:



Sheffer, Krawczyk & Aboba    Standards Track                   [Page 17]

INTERNET-DRAFT                     PIC                    9 October 2002


HASH = PRF(SKEYID_a, HDR | EAP_b
         [| CREDENTIAL-REQUEST_b] [| CREDENTIAL_b])

The HASH may differ from the illustration above if any optional
payloads, for example a notify payload, have been included in the
message. In such cases the HASH MUST include all such payloads, and in
the order they appear, possibly interleaved with the regular PIC
payloads.

The HASH payload for each message MUST be validated by the recipient.

Each of messages 3 and 4 MUST NOT be repeated more than 20 times (not
counting retransmissions), in order to bound the length of the exchange.

4.4.3.  DoS Defense and the Routability Cookie

The contents of the Nrc payload is opaque to the client. However, to
ensure security of this mechanism, Nrc SHOULD be computed as follows:


[1]  Compute v = PRF(K, T | IPi | Ni)

[2]  Set Nrc = v | T | KID

Where PRF is a cryptographic pseudo-random function chosen by AS (e.g.
HMAC-MD5), K is a secret random key for this PRF known to AS only (if
several such keys exist, KID should identify the particular key), IPi is
the source IP address of message (1') from the Client, Ni is the nonce
included in message (1'), and T is a local variable at the AS. T may be
a time value or a counter. If a counter is used then it should be
incremented with each computation of Nrc.

When the Client receives message (2'), it sends message (1) which is
identical to (1') except that now the ISAKMP header contains the CKY-R
value received in the header of message (2'), and the Nrc payload is
added, copied from the Nrc field in message (2').

Upon receiving message (1), the AS verifies the value of Nrc as follows:

[1]  Let RC'= v'|T'|KID' be the value of the routability cookie received
     in message (1).

[2]  AS checks that T' is within  a range of values [T-w...T] where T is
     the current value of time/counter at AS and w is a window of
     freshness.

[3]  If this check fails, message (1) is silently discarded.




Sheffer, Krawczyk & Aboba    Standards Track                   [Page 18]

INTERNET-DRAFT                     PIC                    9 October 2002


[4]  Otherwise, AS computes v = PRF(K, T' | IPi' | Ni') where IPi' is
     the source IP address of message (1), and Ni' is the nonce value
     received in that message.

[5]  If v is different from v', AS silently discards the message.

Note: The above mechanism assumes that messages (1') and (1) sent by a
legitimate initiator carry the same source IP address.

Implementation note: the internal structure of Nrc poses no
interoperability issues since this string is opaque for the client. In
particular the length of each of v, T, and KID may be decided by the
local implementation. Some guidance follows.

For generating v, a PRF with output in the range of 32-64 bits is
sufficient for preventing the attacker from guessing a correct value of
v. It is permissible to use a longer-output PRF truncated to this number
of bits.  The parameter T should not wrap around during the life of a
single key K and therefore its length should typically lie in the range
of 16-64 bits depending on the number of uses expected under the same
key K (this number should consider the situation in which the AS is
under a DoS attack).  KID is used as a "key-identifier" for AS to
differentiate between different values of K in case such different
values co-exist or overlap for some period of time. In most cases this
field can be a single octet.

5.  Security Considerations

This entire document discusses a protocol for the provisioning of
security-critical information.

The Authentication Server approach involves additional security
considerations which are beyond the scope of this document: they have to
do with secure storage of user credentials, and secure communication
with other (optional) entities, the CA, Back-End Authentication Server
and gateway.

The Client is typically the less protected peer. Thus, when Type 1
credentials are used, the Client SHOULD generate a fresh key pair on
each PIC exchange.

The PIC protocol authenticates the human user. There is no attempt to
authenticate the machine from which the user is connecting. Thus the AS
is unable to make policy decisions according to the security of the
client machine. Moreover, PIC, just like IKE and IPsec, should only be
used on a physically secure client machine.





Sheffer, Krawczyk & Aboba    Standards Track                   [Page 19]

INTERNET-DRAFT                     PIC                    9 October 2002


Once the first exchange of the protocol is complete, the Client has
authenticated the AS and has full trust of the AS, for the purposes of
credential provisioning. Thus it is not required to validate the
credential it receives. Note that in some cases the Client cannot
validate the credential.

See Appendix A for some of the rationale that drove the security design
of the protocol.

6.  Intellectual Property Rights

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to  pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard.  Please address the information to the IETF Executive
Director.

7.  Normative References

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3",
          BCP 9, RFC 2026, October 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication
          Protocol (EAP)", RFC 2284, March 1998.

[RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax Version
          1.5", RFC 2314, March 1998.

[RFC2315] B. Kaliski, "PKCS #7: Cryptographic Message Syntax, Version
          1.5", RFC 2315, March 1998.




Sheffer, Krawczyk & Aboba    Standards Track                   [Page 20]

INTERNET-DRAFT                     PIC                    9 October 2002


[RFC2401] Atkinson, R., Kent, S., "Security Architecture for the
          Internet Protocol", RFC 2401, November 1998.

[RFC2402] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402,
          November 1998.

[RFC2406] Kent,S., Atkinson, R., "IP Encapsulating Security Payload
          (ESP)", RFC 2406, November 1998.

[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation
          of ISAKMP", RFC 2407, November 1998.

[RFC2408] Maughhan, D., Schertler, M., Schneider, M., and Turner, J.,
          "Internet Security Association and Key Management Protocol
          (ISAKMP)", RFC 2408, November 1998.

[RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
          RFC 2409, November 1998.

[RFC2412] Orman, H., "The Oakley Key Determination Protocol", RFC 2412,
          Nov. 1998.

[RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S.,  "Remote
          Authentication Dial In User Service (RADIUS)", RFC 2865, June
          2000.

[RFC2866] Rigney, C., "RADIUS  Accounting", RFC 2866, June 2000.

[RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", RFC
          2869, June 2000.

[PKCS12]  RSA Security Inc., "PKCS #12: Personal Information Exchange
          Syntax Standard", http://www.rsalabs.com/pkcs/pkcs-12/

[IPSRAREQ]
          Kelly, S., Ramamoorthi, S., "Requirements for IPsec Remote
          Access Scenarios", Internet draft (work in progress), draft-
          ietf-ipsra-reqmts-05.txt, October 2002.

8.  Non-normative References

[MODECFG] Dukes, D., Pereira, R., "The ISAKMP Configuration Method",
          Internet draft (work in progress), draft-dukes-ike-mode-
          cfg-00.txt, October 2000.

[IKEv2]   Harkins, D., Kaufman, C., Kent, S., Kivinen, T., Perlman, R.,
          "Proposal for the IKEv2 Protocol", Internet draft (work in
          progress), draft-ietf-ipsec-ikev2-02.txt, April 2002.



Sheffer, Krawczyk & Aboba    Standards Track                   [Page 21]

INTERNET-DRAFT                     PIC                    9 October 2002


[CRACK]   Harkins, D., Korver, B., Piper, D., "IKE Challenge/Response
          for Authenticated Cryptographic Keys", Internet draft (work in
          progress), draft-harkins-IPsec-ike-crack-00.txt, June 2000.

[HYBRID]  Litvin, Shamir, Zegman, "A Hybrid Authentication Mode for
          IKE", Internet draft (work in progress), draft-zegman-ike-
          hybrid-auth-00.txt, June 2001.

[GETCERT] Bellovin, S., and Moskowitz, B., "Client Certificate and Key
          Retrieval for IKE", Internet draft (work in progress), draft-
          bellovin-ipsra-getcert-00.txt, June 2000.

[XAUTH]   Pereira, R., Beaulieu, S., "Extended Authentication within
          ISAKMP/Oakley", Internet-draft (work in progress), draft-
          beaulieu-ike-xauth-02.txt, September, 2000.

[HOWSECURE]
          Krawczyk, H., "The order of encryption and authentication for
          protecting communications (Or: how secure is SSL?)", CRYPTO
          2001 Proceedings. Full version in: Cryptology ePrint Archive,
          http://eprint.iacr.org/2001/045

[EKE]     Bellovin,S., and Merritt, M., "Encrypted Key Exchange:
          Password- Based Protocols Secure Against Dictionary Attacks."
          Proceedings of the IEEE Symposium on Research in Security and
          Privacy, Oakland, May 1992.

9.  IANA Considerations

The following values will need to be allocated by IANA:

9.1.  Port Numbers

PIC needs a port number each for both UDP and TCP. These port numbers
should be in the "system" space, i.e. below 1024.

9.2.  ISAKMP Exchange Type

PIC needs an ISAKMP Exchange Type, as discussed in Sec. 3.1 of the
current document.  This number should be allocated from the "ISAKMP
Future Use" space. See Sec. 3.1 of [RFC2408] for details.

9.3.  IPsec ISAKMP Transform Identifier

PIC defines a new IPsec ISAKMP Transform Identifier, as discussed in
Sec. 3.2.  The number 2 should be reserved as the PIC Transform
Identifier. See Sec. 4.4.2 of [RFC2407] for details.




Sheffer, Krawczyk & Aboba    Standards Track                   [Page 22]

INTERNET-DRAFT                     PIC                    9 October 2002


9.4.  ISAKMP Payload Types

Sec. 4.3 defines three new payload types. Their types should be
allocated from the Reserved range of the "Next Payload Type", see table
in Sec. 3.1 of [RFC2408].

9.5.  Future Value Allocation in PIC

This protocol defines new Type fields in the CREDENTIAL-REQUEST and
CREDENTIAL payload types (Sec. 4.3.2, 4.3.3). Additional possible values
in the Reserved range can be permanently allocated via Standards Track
RFCs.







































Sheffer, Krawczyk & Aboba    Standards Track                   [Page 23]

INTERNET-DRAFT                     PIC                    9 October 2002


Appendix A - Design Considerations

In this appendix we discuss several design considerations behind the
specification of PIC.  This discussion is intended for analysis and
clarification and does not contain further protocol specification or
implementation details.

A.1. Protocol Security

As outlined in Sec. 1.3, PIC consists of four logical stages. The first
stage is implemented via messages (1') and (2') and is intended to
provide some protection against DoS attacks via a mechanism modeled
after Phil Karn's "stateless cookies".  Here we use the adaptive
approach suggested in Oakley [RFC2412] where the application of this
mechanism is left to the discretion of the server (on a per-session
basis). The second stage, establishment of a key between client and AS
with authentication by AS only, is carried out in messages (1) and (2).

The third stage, authentication of the client using legacy
authentication, is accomplished via the information carried in the EAP
payloads of messages (2), (3) and (4). The fourth stage, request and
delivery of client's certificate, is carried via the credential payloads
in messages (3) and (4). This multi-functionality of messages (2), (3)
and (4) is done in order to save round trips between the parties.

AS authentication is done via the use of the server's public key (which
is assumed to be known to, or verified by, the client) and then is as
secure as the underlying signature algorithm and security parameters
(such as key length). This authentication provides a guarantee for the
client that it is safe to send the user-authentication data in the third
stage encrypted under the (server-authenticated) SKEYID_e key which is
derived from the exchange in the second stage.  Thus, protection of the
user's authentication data is provided against eavesdroppers as well as
against active intruders that try to impersonate the AS. Moreover, the
authentication of the client's data under SKEYID_a in the third stage
binds the authenticity of the client to the second stage too. Finally,
encryption and authentication under SKEYID_e and SKEYID_a, respectively,
protect the secrecy and integrity of the credentials information
exchanged between client and AS in the fourth stage.

Since the exchange in the second stage is protected with perfect forward
secrecy (via Diffie-Hellman), all the encrypted data in the protocol
(including user's authentication data) is protected against key
compromise as soon as the SKEYID key, and its derived keys, are safely
erased from memory.

We note, however, that the EAP payloads transmitted from AS to client
before the successful authentication of the client is verified cannot be



Sheffer, Krawczyk & Aboba    Standards Track                   [Page 24]

INTERNET-DRAFT                     PIC                    9 October 2002


considered protected by the encryption under SKEYID_e. This is so since
a spoofing client can participate in the second stage, compute SKEYID_e,
and decrypt the information sent by the AS. Therefore, the AS MUST NOT
include confidential information in these payloads. Moreover, note that
the EAP payload piggybacked to message (2) is NOT ENCRYPTED at all. This
design decision simplifies the specification and processing of message
(2) while, by the above argument, it does not compromise security.
However, this means that PIC does not hide the AS identity and it does
not secure user authentication mechanisms that require confidentiality
of the initial data sent from AS to client (e.g., an authentication
challenge). Reasonably secure user-authentication mechanisms should not
be affected by the latter.

In practice, EAP payloads in message (2) will contain an EAP
Request/Identity message, which typically does not require any
protection.

Another design decision in PIC that is worth a clarification is the
authentication of the SA proposal sent in message (1) from client to AS.
Note that in the signature mode of IKE this information is authenticated
via HASH_I and the initiator's signature. However such a signature is
not present in PIC.  The solution adopted here is to include this
information (SAi_b) under the AS signature (HASH_R). In this way, any
change of the SAi information in its way from Client to AS will be
detected by the client upon verification of HASH_R. Also, HASH_R now
includes the full ISAKMP headers of messages (1) and (2).  This is in
contrast to [RFC2409] where only the CKY-I and CKY-R fields from the
header were covered. This protects the authenticity of all header
fields, including the Major and Minor Version numbers.

We remark on the order of encryption and authentication as applied in
PIC. Recent results show that in order for encryption functions to
really provide secrecy protection against active attackers (as required
in the PIC's scenario) the ciphertext needs to be authenticated via a
secure MAC.  As it turns out, computing the MAC on the plaintext and
encrypting the plaintext and MAC does not provide, in general, a
sufficient guarantee of secrecy [HOWSECURE]. This calls for protocols,
in particular PIC, to adopt the encrypt-then-authenticate approach in
which the authenticating MAC is applied to the ciphertext rather than to
the plaintext. However, in order to apply this safer method in PIC one
has to change the regular processing of ISAKMP which applies encryption
via the HDR* convention, namely, all information after the header is
encrypted including the HASH (or MAC) payload. Since, on the other hand,
it is also shown in [HOWSECURE] that this order of processing is secure
under the specific use of standard CBC or stream-cipher encryption,
PIC's design decision has been to favor the currently deployed ISAKMP
processing at the expense of sacrificing the robustness of the protocol
to future changes in cryptographic algorithms.  This means that any



Sheffer, Krawczyk & Aboba    Standards Track                   [Page 25]

INTERNET-DRAFT                     PIC                    9 October 2002


future change to the protocol that affects the way encryption and MAC-
generation is done will require much care and renewed analysis.

Another design decision made in order not to change the regular ISAKMP
processing is to apply authentication (under the HASH payload) to base
payloads only and not to payload headers.  Authenticating all bits,
including headers, would have been a better approach but also in this
case we have favored ISAKMP compatibility.

A.2. Design Choices

Some of the design decisions that were made in developing this protocol
are:

[1]  ISAKMP-based to reuse ISAKMP implementation.

[2]  Transport of user authentication via an already standardized
     protocol: EAP.

[3]  Negotiation is kept to a minimum for simplicity.

[4]  Reducing the number of messages via piggybacking.

[5]  AS may or may not be decoupled from the gateway.

[6]  Client is assumed to be pre-configured with the address of the AS,
     as well as the security gateway.

[7]  Full trust in AS.

[8]  Short-term certificate avoids the need for human intervention if a
     SA needs to be re-established ("single sign-on").

[9]  Server-side key generation and key storage have been merged into a
     single credential-request type. The choice of method is left to AS
     policy.

[10] The server can make the trade off between DoS protection and round
     complexity, i.e. the number of round trips until the protocol
     exchange completes. This decision may be based on policy and
     possibly on real-time factors, such as the current server's load.

A.3. User Authentication

User authentication may be performed by the Authentication Server or may
be proxied by it to a legacy server. The protocol allows for several
types of authentication to be tried by the Server before it decides that
it cannot authenticate the Client.



Sheffer, Krawczyk & Aboba    Standards Track                   [Page 26]

INTERNET-DRAFT                     PIC                    9 October 2002


We note that EAP [RFC2284] specifies that any implementation MUST
implement MD5-Challenge as an authentication method. EAP does not
support cleartext authentication mechanisms, such as PAP.

A.4. Credentials and Negotiation

The protocol as described requires the policies of Client and Server to
match regarding credentials. For example, an unrecoverable protocol
error results if the Client is unable to produce a private key but the
server requires this capability.

Several approaches for credential negotiation were considered and
rejected for this protocol, in the interest of simplicity.  The general
case would require negotiation of multiple properties in parallel, for
example:

- Is the private key generated by the Client or the AS.
- What type of certificate is required, in particular which algorithm.
- What length of keys is required, for each of the credential's components.

A.5. Round Complexity

PIC as defined in this document acts as a front-end protocol to IKE. It
requires several round trips (two at least) to obtain credentials from
the AS, and then the additional round trips of IKE's phase 1 and 2 are
needed to complete the establishment of an IPsec association. Therefore,
an obvious criticism to PIC is the high number of communication rounds
required from the moment a client contacts the AS until the time in
which the IPsec association is finally established. This communication
cost, however, is unavoidable given the IPSRA set of requirements. For
completeness, and for possible future use, we outline here some ways in
which PIC itself can be adapted (and simplified) to provide a more
efficient way of IPsec bootstrapping based on legacy user
authentication.

One option is to eliminate the authentication server (AS), and run PIC,
without the fourth stage of credential retrieval, directly against an
IKE/IPsec security gateway as a phase 1 authentication mode of IKE. The
derived SKEYID_a/d/e will then be used as in a regular phase 2 exchange
in IKE. This means that such a gateway would be required to support a
modified IKE which includes such a new mode of phase 1 authentication.
(As explained in the introduction this approach is currently precluded
by the IPSRA charter.) Moreover, this gateway will be required to
support interaction with the user authentication system (which adds to
the complexity of the gateway, and presents additional opportunities for
denial of service attacks).





Sheffer, Krawczyk & Aboba    Standards Track                   [Page 27]

INTERNET-DRAFT                     PIC                    9 October 2002


An alternative to the above is to keep the AS, run PIC without its
fourth stage against the AS (which will be responsible to verify the
user's authentication), and pass the resultant SKEYID key from the AS to
the gateway. Now the client could contact the security gateway and run
phase 2 of IKE based on this value of SKEYID. This requires secure
communication between AS and the gateway, as well as a modification of
IKE to support a direct phase-2 authentication mode.

A.6. Packet Fragmentation

The widespread deployment of IKE is held back by the incomplete support
of IP fragmentation by many current routers. In many cases, widely used
routers may drop several fragments of a very large IP packet. Since IKE
is transmitted over UDP, and often include whole certificate chains
within a single payload, this has been a real obstacle.

We considered adding an application-level fragmentation mechanism to
PIC. We finally rejected such a solution, for several reasons.

First, from an architectural point of view, fragmentation belongs to a
lower layer. IP obviously provides this functionality, and it may be
argued that ISAKMP needs to add support for fragmented payloads.

Second, fragmentation in PIC would introduce additional complexity that
we tried to avoid in this design.

And lastly, the MTU in the open Internet tends to be small.  On the
other hand, the potential length of a payload, a certificate chain, is
very large. Combined, this could mean a very long exchange, introducing
time delays, reliability problems and a large potential for DoS attacks
that could tie up the server for a large number of packets.

Instead, we have chosen to recommend using TCP as an alternative
transport, in all cases when there is a large probability of packet
fragmentation.

A.7. Other Extensions

PIC does not support machine authentication. However, we note here that
if such extension to PIC is desirable at some point, then it is possible
to add this functionality if one assumes the machine to possess a
private signing key and a certificate that can be validated by the AS.
In this case, one would add to PIC a message from client to AS, after
the current message (2), similar to the third message of IKE's
aggressive signature mode, in which the signature would be computed
using the machine's signature key. It should be noted that this solution
involves some hidden complexity (the server needs to make policy
decisions with only partial information regarding the client's



Sheffer, Krawczyk & Aboba    Standards Track                   [Page 28]

INTERNET-DRAFT                     PIC                    9 October 2002


identity). One way around this problem is to add a second ID payload to
message (1) from the Client.

Another functionality not provided by PIC is authentication based on a
shared password between user and AS, and without relying on an AS public
key. Such functionality can be provided using mechanisms such as EKE
[EKE]. However, since there is to date very little deployment of
password-based scheme such as EKE, this would fall outside of the IPSRA
charter which is to leverage legacy authentication methods.

Acknowledgments

We would like to thank Yael Dayan for her help in preparing this
document, and Udi Arie, Scott G. Kelly, and William Dixon for reviewing
earlier versions.

Authors' Addresses

Yaron Sheffer
Personeta
1 HaNagar St.
45241 Hod HaSharon
Israel

EMail: yaronf@gmx.net

Hugo Krawczyk
Dept. of Electrical Engineering
Technion
32000 Haifa
Israel

EMail: hugo@ee.technion.ac.il

Bernard Aboba
Microsoft
One Microsoft Way
Redmond, WA 98052
USA

Phone: +1 425 706 6605
EMail: bernarda@microsoft.com









Sheffer, Krawczyk & Aboba    Standards Track                   [Page 29]

INTERNET-DRAFT                     PIC                    9 October 2002


Full Copyright Statement

Copyright (C) The Internet Society (2002).  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 implementation 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.  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."

Expiration Date

This memo is filed as <draft-ietf-ipsra-pic-06.txt>, and expires April
10, 2003.
























Sheffer, Krawczyk & Aboba    Standards Track                   [Page 30]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/