One document matched: draft-ietf-ipsra-pic-01.txt
Differences from draft-ietf-ipsra-pic-00.txt
IP Secure Remote Access WG Y. Sheffer, RADGUARD
Internet Draft H. Krawczyk, Technion
Document: draft-ietf-ipsra-pic-01.txt
Expires: March 2001 September 2000
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 RFC2026 [1].
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
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document presents a method to bootstrap IPSec authentication via
an "Authentication Server" (AS) and legacy user authentication (e.g.,
RADIUS). The client machine communicates with the AS using a key
exchange protocol authenticated by the server only, and the derived
keys are used to protect the legacy 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 an IPSec-enabled security gateway. The
later stage does not require user intervention. The proposed server-
authenticated key exchange uses an ISAKMP-based protocol, similar to
a simplified IKE exchange, and arbitrary legacy authentication is
supported via the use of the standard EAP protocol.
1. Introduction
Despite the growing popularity of PKI, legacy user authentication is
not going away. There have been several proposals to integrate legacy
authentication directly into the IKE framework, such as [2] and [3].
Recently Bellovin and Moskowitz proposed to offload this task into a
separate server, called an Authentication Server (AS). Some of the
advantages of a separate authentication server are:
Sheffer, Krawczyk Internet Draft 1
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
- The security gateway may implement IKE/IPSec only, without worrying
about legacy authentication. The same gateway can be deployed in
PKI-based and legacy-based organizations.
- A denial-of-service attack on the AS cannot compromise existing
connections at the gateway (thus alleviating the damage of such
attacks). This reduces the amount of work that needs to be done to
secure the AS against DoS attacks.
- 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.
This document adopts this separation of an Authentication Server.
However, in contrast to the mechanism proposed in [5] which uses
IPSec-unrelated protocols TLS and HTTP, the current solution is based
on simplified ISAKMP and IKE mechanisms. The protocol embeds
Extensible Authentication Protocol (EAP) messages [4] in ISAKMP
payloads to support multiple forms of legacy user authentication
(e.g. RADIUS). Following the proposal in [5], at the end of the
interaction with AS the client machine obtains credentials that can
be later used by the client to perform regular IKE authentication
with an IPSec-enabled gateway. The current draft defines several
forms of credentials and can be extended to support any or all of the
forms defined in [5]. Note that this document uses the term
"credentials" for both digital certificates and pre-shared secret
keys.
The PIC proposal overcomes some of the shortcomings in the solution
of [5]. In particular, it avoids the use of HTTP-based authentication
which is not general enough to support authentication schemes in
common use today, and avoids the need to support a full TLS
implementation (this is especially advantageous in the case where the
AS is co-located with an IPSec security gateway which does not
support TLS). The end result is also significantly more efficient.
It should be emphasized that this protocol 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.
1.1. 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.
Legacy authentication server (LAS): 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.
Sheffer, Krawczyk Internet Draft 2
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
|====| |=====|
|====| AS |=====| LAS |
|| |====| || |=====|
|| || ||
|| || || |====|
|| || |== (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 legacy authentication
between AS and LAS, and certification between AS and the CA.
1.2. PIC Protocol Overview
The three main stages of the proposed protocol are:
- The protocol establishes a one-way trust relationship between the
client and the AS. This means that only the server is
authenticated. A secure channel from the client to the AS is
created.
- Legacy user authentication is performed over this secured channel.
Legacy authentication information is transported using the standard
EAP [4] tunneled within ISAKMP.
- 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, a private key generated or stored by
the AS and accompanied by a corresponding certificate, or it may
also be a symmetric secret key.
To minimize the number of messages exchanged, the second and third
stages share messages, and the protocol takes care to ensure security
of the third stage despite the fact that it is started while the
client is not yet authenticated.
We note that the protocol proposed here is architecturally very
similar to [5]. The difference is in the details: PIC uses EAP for a
more general legacy authentication, and eliminates the constraints of
TLS and HTTP.
1.3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [6].
Sheffer, Krawczyk Internet Draft 3
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
1.4. Change Log
-00: Initial version, schematic.
-01: Much more detail, changed XAuth to EAP.
2. Assumptions and Requirements
- User authentication involves interaction with the human user and
should be made as painless as possible. In particular, multiple
authentication sessions should be avoided if at all possible.
- Legacy authentication server software cannot be changed. Neither
can we modify the authentication database. The most we can do is
add external software on the same host.
- Defense against denial-of-service attacks should be maximized at
the gateway, more so than in the AS. In many cases traffic at the
gateway is more critical than remote access, e.g. when the gateway
implements VPN functions between distant sites.
- The protocol assumes that the Client is able to authenticate the
AS, i.e. it has been pre-configured with a public key (or a
certificate hash) for the server or for its CA.
See also Sec. @5.1 below for a list of lower-level requirements.
3. PIC and ISAKMP
PIC is based on ISAKMP [13] and the ISAKMP IPSec DOI [7], 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. The ISAKMP Exchange Type for PIC
is 250.
3.2. The PIC Transform
PIC defines a new 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.
3.3. Protection of Payloads
The new ISAKMP payloads defined below are protected in two different
ways:
- In the second message of the protocol, only the body of the EAP
payload(s) is encrypted under the PIC SA.
Sheffer, Krawczyk Internet Draft 4
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
- 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.
3.4. 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
following the HASH payload in PIC messages.
There are no new Notify payloads defined in PIC.
4. The PIC Protocol
4.1. Transport
The PIC protocol is an ISAKMP exchange. It inherits the following
properties from ISAKMP:
- UDP transport.
- Use of port 500.
- Retransmission policy.
While EAP defines its own retransmission policy, where retransmission
is always performed by the server (the ôauthenticatorö, in EAP
terms), PIC does not employ that policy. In accordance with ISAKMP,
both peers MUST retransmit the last message, as long as a response
has not been received.
Implementation note: stage 2 of PIC involves manual password entry.
Retransmission timeouts should allow for human speeds.
4.2. ISAKMP Payloads
PIC defines several new payloads:
- EAP û to embed EAP messages within ISAKMP.
- CREDENTIAL-REQUEST û allows the client to request a credential.
- CREDENTIAL û allows the AS to return a credential.
The following defines each of the payloads.
Sheffer, Krawczyk Internet Draft 5
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
4.2.1. The EAP Payload
The EAP payload is defined to embed EAP messages. Its payload type is
301. 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sequence ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ EAP Message ~
! !
+++++++++++++++++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The EAP Payload fields are defined as follows:
o Next Payload (1 octet) - Identifier for 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.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - 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.
o Sequence (1 octet) - a sequence number of EAP payloads in the
current exchange, starting at 1. The number is incremented for each
EAP payload when multiple payloads occur in a single message. Such
multiple payloads MUST be ordered within the ISAKMP message
according to their sequence number. A single payload sequence is
maintained between the Client and Server.
o RESERVED (3 octets) - Unused, set to 0.
o EAP Message - An EAP message as defined in [4], including any later
additions to the standard.
Sheffer, Krawczyk Internet Draft 6
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
4.2.2. The CREDENTIAL-REQUEST Payload
The CREDENTIAL-REQUEST payload is defined to allow the client to
request a credential. Its payload type is 302. 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 ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Next Payload (1 octet) - Identifier for 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.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - 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.
o Type (1 octet) - denotes the type of credential. Values are:
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
for future use.
4..127: Reserved for future versions.
128..255: Reserved for private use.
The value None MUST NOT be sent.
o Subtype (1 octet) - denotes a 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 [13]). The value None MUST NOT be sent.
o RESERVED (2 octets) - Unused, set to 0.
Sheffer, Krawczyk Internet Draft 7
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
o 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.
For Type 1 with Subtype 1 (PKCS #7 wrapped X.509 certificate): this
field contains a certificate request in PKCS #10 [8] 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.
For Type 1 with Subtype 4 (X.509 Certificate - Signature): this field
contains a certificate request in PKCS #10 [9] 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.
For Type 2 with Subtype 4, this field is omitted.
All other Type-Subtype combinations are undefined. They MUST NOT be
sent, and MUST be rejected if received.
4.2.3. The CREDENTIAL Payload
The CREDENTIAL payload is defined to allow the AS to send various
types of credentials. Its payload type is 303. 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 ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Next Payload (1 octet) - Identifier for 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.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - 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.
o Type (1 octet) - denotes the type of credential. Values are as
defined for the CREDENTIAL-REQUEST payload.
Sheffer, Krawczyk Internet Draft 8
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
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.
o Subtype (1 octet) - denotes a 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 [13]).
o RESERVED (2 octets) - Unused, set to 0.
o 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.
For Type 1 with Subtype 1 (PKCS #7 wrapped X.509 certificate): this
field contains a certificate or certificate chain in PKCS#7 [10]
format.
For Type 1 with Subtype 4 (X.509 Certificate - Signature): this field
contains an X.509 certificate.
For Type 2 with Subtype 4, the Information field contains a private
key and corresponding certificate, wrapped in a PKCS #12 [11] PFX
PDU.
All other Type-Subtype combinations are undefined. They MUST NOT be
sent, and MUST be rejected if received.
Note: for Type option 2, it is up to the serverÆs local policy to
decide whether a certificate is fetched from storage or generated
from new material.
4.3. Protocol Notation
<PAYLOAD> denotes a single ISAKMP payload, constructed by
concatenating the generic ISAKMP payload header with the encrypted
body of the payload. The body is encrypted using the negotiated
encryption transform and keyed by material generated from SKEYID_e.
Such encryption may produce a longer payload, as a result of padding.
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.
Sheffer, Krawczyk Internet Draft 9
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
4.4. Protocol Exchanges
The protocol consists of a variable number of messages, with a
minimum of 4 messages.
The first two messages are adopted from IKE Aggressive Mode with
Signature Authentication:
Client AS
------ --
(1) HDR, SA, KE, Ni ==>
(2) <== HDR, SA, KE, Nr, IDir,[ CERT, ]
SIG_R, HASH, <EAP> [, <EAP>...]
These two messages establish the PIC SA, used for the EAP payloads of
message (2) and for all the following messages.
Refer to Sec. 5.1 of [12] and Sec. 3 of [13] for a description of the
payloads. The value SKEYID and its derivatives SKEYID_a and SKEYID_e
are computed in the exact same way as defined in Sec. 5 of [12] for
the case of signature authentication. Similarly for the
Initialization Vector (IV), when applicable. SA encryption keying
material is derived as in [12], Appendix B.
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 [12], for Phase 1.
Payloads are ordered as in Sec. 5 of [12], for Aggressive Mode with
Signatures. There are no additional constraints on the order of the
HASH and EAP payloads.
SIG_R is derived from HASH_R, as in [12]. HASH_R is computed
differently in PIC, to correct a typo in [12]. The responderÆs SA
payload is used in the calculation:
HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAr_b | IDir_b )
The Client MUST validate the correctness of the SIG_R payload. If a
certificate is transmitted, the Client MUST verify that it is
trusted.
Message (2) MUST contain one or more EAP payloads. The EAP payload(s)
are encrypted under the PIC SA. The HASH payload is calculated over
the ISAKMP cookies, and the concatenated EAP payloads:
HASH = prf(SKEYID_a, CKY-I | CKY-R | EAP(1) | EAP(2)...)
The HASH may differ if any optional payloads, for example a Notify
payload, have been chained to the message.
Sheffer, Krawczyk Internet Draft 10
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
Messages (3) and (4) are:
Client AS
------ --
(3) HDR*, HASH, EAP, [EAP...,] ==>
[CREDENTIAL-REQUEST]
(4) <== HDR*, HASH, EAP, [EAP...,]
[CREDENTIAL]
[Repeat of message (3) ==>
<== Repeat of message 4]...
Messages (3) and (4) may be repeated as required by the legacy
authentication method, alternating between the Client and the AS.
The last EAP payload sent by the AS MUST be a Success or a Failure
message, in the sense of [4]. A CREDENTIAL-REQUEST payload MUST be
sent exactly once, in the first message (3) sent by the Client. A
CREDENTIAL payload MUST be sent exactly once, in the last message
sent by the AS.
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. 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 cookies and the
concatenated payloads:
HASH = prf(SKEYID_a, CKY-I | CKY-R | EAP(n) | EAP(n+1)...
[| CREDENTIAL-REQUEST] [| CREDENTIAL])
The HASH may differ from the illustration above if the order of
payloads in the message differs from the illustrative example or if
any optional payloads, for example a notify payload, have been
chained to the message.
The HASH payload for each message MUST be checked by each recipient.
Each of messages 3 and 4 MUST NOT be repeated more than 10 times (not
counting retransmissions).
Sheffer, Krawczyk Internet Draft 11
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
4.5. Protocol Security
The first two messages in the PIC protocol only provide server
authentication. Client authentication is provided during the second
stage of the protocol via the legacy user authentication mechanism in
use. Thus the resultant client authentication is no stronger than the
legacy user authentication mechanism.
The encryption key derived from SKEYID_e in the first stage protects
the secrecy of the user authentication and the credential exchange.
This results in perfect forward secrecy of the authentication
information even in the presence of an active man-in-the-middle
provided that the client and/or user verify the authenticity of the
server's public key.
The authentication (under SKEYID_a) of messages (3) and (4) binds the
identified user to the keys exchanged in messages (1) and (2) and is
necessary for the security of the protocol both for authentication
and confidentiality.
Recent research shows that the best way to combine the authentication
(MAC) and encryption of the legacy-authentication and credential
material is by first encrypting the information and then applying the
MAC on the ciphertext. Indeed, using results from [14] one can show
that under this order of operations PIC can be proved secure.
Unfortunately, the existing ISAKMP specifications and payload
processing support the other ordering, namely, first MAC the
plaintext then encrypt (i.e. compute a HASH payload on the plaintext,
then, if encryption is required, compute it over the plaintext and
HASH).
This is particularly troubling given recent work-in-progress [15]
that shows, for some class of secure ciphers, explicit attacks
against password protocols that are protected under the MAC-then-
encrypt approach.
However, because of the preliminary character of the [15] results and
currently unknown weaknesses of the MAC-then-encrypt approach for
commonly used ciphers and modes of operation, we have chosen in this
specification to stick to the common ISAKMP processing in the
interest of facilitating PIC implementation with existing ISAKMP
code.
5. Discussion
5.1. Protocol Requirements
The PIC protocol was designed according to the IPSRA requirements and
constraints as defined in [16]. Among these are the following:
- Easy transition to certificate-based authentication.
- No change to IKE.
Sheffer, Krawczyk Internet Draft 12
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
- No secret key assumed at the client beyond user authentication
material (password).
- Client is assumed to have the public key of AS or a way to validate
it.
- No support for machine authentication.
5.2. Design Choices
Some of the design decisions that were made in developing this
protocol are:
- ISAKMP-based to reuse ISAKMP implementation.
- Transport of legacy authentication via an already standardized
protocol: EAP.
- Negotiation is kept to a minimum for simplicity.
- Reducing the number of messages via piggybacking.
- AS may or may not be decoupled from the gateway.
- Client is assumed to be pre-configured with the address of the AS,
as well as the security gateway.
- Full trust in AS.
- Short-term certificate avoids the need for human intervention if a
SA needs to be re-established ("single sign-on").
- 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.
5.3. Legacy Authentication
Legacy 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.
5.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.
Sheffer, Krawczyk Internet Draft 13
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
6. 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, legacy
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.
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.
7. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996.
2 Pereira and Beaulieu, "Extended Authentication within ISAKMP/Oakley
(XAUTH)", draft-ietf-ipsec-isakmp-xauth-06.txt (work in progress).
3 D Harkins, B Korver, D Piper, "IKE Challenge/Response for
Authenticated Cryptographic Keys", draft-harkins-ipsec-ike-crack-
00.txt (work in progress).
4 Blunk and Vollbrecht, "PPP Extensible Authentication Protocol
(EAP)", RFC 2284, March 1998.
5 Bellovin and Moskowitz, "Client Certificate and Key Retrieval for
IKE", draft-bellovin-ipsra-getcert-00.txt (work in progress).
6 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
7 Piper, "The Internet IP Security Domain of Interpretation for
ISAKMP", RFC 2407, Nov. 1998.
Sheffer, Krawczyk Internet Draft 14
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
8 Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5",
RFC 2314, March 1998.
9 B. Kaliski, "PKCS #10: Certification Request Syntax Version 1.5",
RFC 2314, March 1998.
10 B. Kaliski, "PKCS #7: Cryptographic Message Syntax, Version 1.5",
RFC 2315, March 1998.
11 RSA Security Inc., "PKCS #12: Personal Information Exchange Syntax
Standard", http://www.rsalabs.com/pkcs/pkcs-12/.
12 Harkins and Carrel, "The Internet Key Exchange (IKE)", RFC 2409,
Nov. 1998.
13 Maughhan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
14 S. Halevi and H. Krawczyk, "Public-Key Cryptography and Password
Protocols", ACM Transactions on Information and System Security,
Vol. 2, No. 3, August 1999, pp. 230-268.
15 H. Krawczyk, "Vulnerabilities of Authenticate-then-Encrypt Secure Channels",
In preparation.
16 Kelly and Ramamoorthi, "Requirements for IPsec Remote Access
Scenarios", draft-ietf-ipsra-reqmts-01.txt (work in progress).
8. Acknowledgements
We would like to thank Yael Dayan for her help in preparing this
document, and Udi Arie and Scott G. Kelly for reviewing an early
version.
9. IANA Considerations
The following values will need to be re-allocated as the protocol
progresses to a standard.
- ISAKMP Exchange
- ISAKMP Transform Identifier (Sec. 4.4.2 of DOI)
- Next Payload identifiers
Sheffer, Krawczyk Internet Draft 15
PIC, A Pre-IKE Credential Provisioning Protocol Sep. 2000
10. AuthorsÆ Addresses
Yaron Sheffer
RADGUARD Ltd.
Atidim Technology Park, Bdg #4
61581 Tel Aviv
Israel
Email: yaronf@radguard.com
Hugo Krawczyk
Dept. of Electrical Engineering
Technion
32000 Haifa
Israel
Email: hugo@ee.technion.ac.il
Sheffer, Krawczyk Internet Draft 16
| PAFTECH AB 2003-2026 | 2026-04-21 08:01:08 |