One document matched: draft-harkins-ipsec-ike-crack-00.txt
Network Working Group D Harkins, B Korver, D Piper
INTERNET-DRAFT Network Alchemy
draft-harkins-ipsec-ike-crack-00.txt October 18, 1999
IKE Challenge/Response for Authenticated Cryptographic Keys
<draft-harkins-ipsec-ike-crack-00.txt>
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and 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.
Table of Contents
1. Abstract......................................................2
2. Terms and Definitions.........................................2
3. The Protocol..................................................5
3.1 IKE Challenge/Response Abstract Representation................6
3.2 IKE Challenge/Response Authentication Failures................6
4. Legacy Authentication Method (LAM) Identifiers................7
4.1 LAM Types.....................................................7
4.2 LAM Attributes................................................8
5. Legacy Authentication Method (LAM) Profiles...................8
5.1 LAM Profiles: Password........................................9
5.2 LAM Profiles: One-Time Password...............................10
5.3 LAM Profiles: Challenge/Response..............................11
5.4 LAM Profiles: SecurID.........................................14
5.5 LAM Profile Matrix............................................17
6. The IKE Challenge/Response Vendor ID Signature................17
7. Security Considerations.......................................18
Harkins, Korver, Piper Expires in 6 months [Page 1]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
Acknowledgments...................................................19
References........................................................19
Authors' Address..................................................20
1. Abstract
This memo describes a new exchange a la [HC98] which provides for
authentication when one side is using a unidirectional authentication
technique such as RADIUS, SecurID, or OTP (hereafter referred to, for
convenience, as "legacy authentication methods").
The protocol described here is to be used as a "phase 1" exchange
([HC98]). The result of this exchange is a mutually authenticated
IKE security association ([HC98]). The keys that result from this SA
are also mutually authenticated and thereby convey this status to any
SA's created from it for any other security service, such as IPSec
[Pip98].
2. Terms and Definitions
2.1 Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
"MAY" that appear in this document are to be interpreted as described
in [Bra96].
2.2 Exchange Definition
This exchange is motivated by the use of roaming IPSec-enabled
clients which use legacy authentication methods for authentication
instead of using a public key certificate. Therefore the parties to
this exchange are a "client" and a "gateway". The "client" is always
the initiator of this exchange and is assumed to be coming from an IP
address that cannot be known to the "gateway" a priori. This
assumption, though, is not a requirement.
The protocol described in this memo is a separate exchange and not
another authentication method for an existing exchange. Unlike the
other exchanges in [HC98] this exchange does not have negotiable
authentication methods. All other attributes and their status from
[HC98] are unaffected. Unless otherwise overridden by a requirement
in this memo all requirements in [HC98] exist in this memo.
The SKEYID state from [HC98] will be authenticated using digital
signatures so the authentication method negotiated in the [HC98]
protection suite MUST be one of the digital signature methods from
[HC98]. The digital signature method offered by the client in his
protection suite offer MUST be compatible with the public key he will
Harkins, Korver, Piper Expires in 6 months [Page 2]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
be generating and using in this exchange.
This exchange will use the value 240 (see Section 6).
2.3 New Payloads
This exchange requires two new payloads to carry new information
unique to this exchange. These are a "Raw Public Key Payload" used
to carry an unauthenticated public key; and a Challenge/Response
payload used to convey a challenge from the gateway to the client and
used by the client to respond to a challenge from the gateway. The
Challenge/Response payload contains attributes denoting specific
information conveyed from the client to the gateway and back. The
actual legacy authentication method will determine the specific
contents of this payload.
Each of these payloads consists of the ISAKMP generic header
([MSST98]) and a payload-specific body whose length is not fixed.
The "Payload Length" in the generic header includes the length of the
header itself. All fields labeled "RESERVED" MUST be filled with
zero prior to sending and each party to the exchange MUST verify that
value on all payloads it is sent.
2.3.1 The Raw Public Key Payload (PK)
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ raw public key ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The payload type for this payload is 128 (see Section 6). The body
of this payload will contain a public key of the type used by the
authentication method negotiated in the first exchange of messages
(in the SA payload).
The raw public key is in the form of SubjectPublicKeyInfo [RFC2459]
and MUST be DER encoded.
Harkins, Korver, Piper Expires in 6 months [Page 3]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
2.3.2 The Challenge/Response Payload (CHRE)
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LAM Type ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ generic challenge/response blob ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The payload type for this payload is 129 (see Section 6). The body
of this payload may also contain attributes used to convey
authentication information (see Section 4.2).
The LAM Type field denotes the legacy authentication method (see
Section 5) associated with the exchange. The LAM Type must be set in
all CHRE payloads in an exchange. The LAM Type is selected by the
initiator (client) and MUST be set to the same value throughout the
exchange.
2.3 Notation
The notation of this memo is similar to [HC98]. Like [HC98] it uses
payloads defined in [MSST98]. The notation for the new payloads is:
CHRE is the "challenge/response payload".
PK is the "raw public key payload".
To prevent confusion (e.g. g^g for the Diffie-Hellman public value of
the gateway) the client's payloads are denoted with "i", as it is the
initiator, and the gateway's payloads are denoted with "r", as it is
the responder.
The number of messages in this protocol is dictated by the type of
legacy authentication method employed. Depending on the method a
message could be one of two possible outcomes. This choice in
denoted by < opt1 | opt2>. For instance, if the gateway may respond
with either a Signature payload or a Challenge/Response payload this
is denoted < SIG | CHRE >.
Harkins, Korver, Piper Expires in 6 months [Page 4]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
3. The Protocol
This protocol uses digital signatures to bind each party to the
exchange as well as to the secret keying material that results from
the exchange. The signatures are verified because the peers trust
each other's public keys. This trust is acquired differently for the
client and the gateway. The client trusts the gateway's public key
either because it came from a certificate which is signed by a
trusted certification authority or because the client trusts it by
some out-of-band mechanism (for instance it is loaded into his policy
store prior to embarking on his voyage). The gateway trusts the
client's public key because the client has successfully authenticated
himself and his public key using a legacy authentication method and
can further prove possession of the corresponding private key.
The reader should note that the channel in which the client's public
key is transmitted is secure from a man-in-the-middle attack due to
the fact that the gateway's Diffie-Hellman public value is signed.
In the case of [RSA], the signature is a [PKCS1] private key
encryption (see [HC98]) of a hash, using the negotiated hash
algorithm from the SA payloads, of the Diffie-Hellman public value.
In the case of [DSS], the signature is a standard FIPS-186 signature
of the Diffie-Hellman value. In either case, the data to sign
includes any padding pre-pended to the body of the payload (for
alignment to the length of the prime modulus) but does not include
the ISAKMP header. The client MUST verify the signature on this
value. If the signature is not valid the exchange MUST be
terminated.
The "SKEYID*" secret state is generated according to the rules for
digital signature authentication of [HC98]. In other words.
SKEYID = prf(Ni_b | Nr_b, g^xy)
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
First, we describe the protocol abstractly using the aforementioned
notation and then separate profiles are given for each of the defined
LAM types.
Harkins, Korver, Piper Expires in 6 months [Page 5]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
3.1 IKE Challenge/Response Abstract Representation
The IKE Challenge/Response protocol is defined as follows:
Client (I) Gateway (R)
----------- -----------
HDR, SAi, KEi, Ni
[, CERTREQ] --->
<--- HDR, SAr, [CERT, ] KEr,
SIG1, Nr
HDR*, CHRE, PK --->
<--- HDR*, < SIG2 | CHRE >
HDR*, < SIG3 | CHRE > --->
Where SIG1 is a digital signature of KEr using the gateway's private
key (any ambiguity about which key was used can be dispelled by
optionally sending a certificate payload which indicates the public
key used to verify the signature). SIG2 and SIG3 are digital
signatures, using the gateway's private key and the client's private
key respectively, over an authenticating digest. This digest is the
prf output (see [HC98]) using SKEYID_a as a key and a hash (using the
negotiated hash function) of all packets sent in the protocol, not
including the current exchange, excluding retransmissions, and prior
to encryption (or after decryption), when applicable.
Note that the number of messages in the exchange is not fixed. The
gateway can respond with any number of challenges (CHRE payloads) to
which the client responds with responses (also CHRE payloads). When
the gateway has concluded authenticating the client (i.e., when it is
ready to accept the client's public key), it responds with SIG2.
When the gateway returns a SIG payload, the client MUST conclude the
protocol in his next response by return his corresponding SIG
payload.
Since this protocol is open-ended, a host implementation may wish to
limit the number of CHRE round-trips using locally defined policy.
3.2 IKE Challenge/Response Authentication Failures
If the contents of the (possibly multiple) CHRE payload(s) that the
client sends fail to satisfy the legacy authentication method the
gateway MUST respond with an ISAKMP Notify payload (AUTHENTICATION-
FAILED) [MSST98].
Harkins, Korver, Piper Expires in 6 months [Page 6]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
The Notification Payload MUST have the following format:
o Payload length - set to the value 36
o DOI - set to the value zero (0) (ISAKMP)
o Protocol ID - set to the value one (1) (PROTO_ISAKMP)
o SPI Size - set to the value 16
o Notify Message Type - set to the value 24
o SPI - set to the ISAKMP initiator and responder cookies
with the following "Notification Data":
o LAM Type (two octets) - set to the LAM Type the server requires
for the client; MAY be different than the LAM Type specified in
any CHRE payloads if the server required a different LAM Type
than what was offered
o RESERVED (two octets) - MUST be zero (0) (alignment)
o Status (four octets) - authentication failure status (private to
the implementation); SHOULD be omitted when unused
Due to the nature of this protocol, that notify payload can only
occur once the secure channel has been established and the client can
be assured of the authenticity of it. The client MUST terminate the
exchange upon receipt of such a notify payload.
4. Legacy Authentication Method (LAM) Identifiers
4.1 LAM Types
Different legacy authentication methods are denoted by a unique LAM
type identifier in the Challenge/Response payloads. The legacy
authentication methods supported by this protocol are as follows:
Legacy Authentication Method Value
----------------------------- -----------
CRACK_PASSWORD 1
CRACK_OTP 2
CRACK_CHALLENGE_RESPONSE 3
CRACK_SECURID 4
<reserved> 5-32767
<private use> 32768-65535
CRACK_PASSWORD specifies a simple username/password mechanism. It's
used for any simple host-based password check mechanism. It also
useful for proxy-based password authentication schemes, like TACACS
and RADIUS.
CRACK_OTP specifies that a one-time password mechanism. It's useful
for the S/KEY [Hal95] and OTP [HM96] schemes.
Harkins, Korver, Piper Expires in 6 months [Page 7]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
CRACK_CHALLENGE_RESPONSE specifies a token-based challenge/response
mechanism. It's useful for a wide variety of cryptographic tokens,
typically based on DES.
CRACK_SECURID specifies a SecurID mechanism. It's useful for the RSA
SecurID system. The CRACK_SECURID closely resembles
CRACK_CHALLENGE_RESPONSE.
4.2 LAM Attributes
The Challenge/Response payload contains attributes used to convey
information between the client and the gateway used to authenticate
the client. These are standard [MSST98] attribute payloads
associated with the Challenge/Response payload. The following LAM
attributes are valid, see section 6:
Attribute Value Type
---------- ------- ------
CRACK_USERNAME 16384 variable
CRACK_DOMAIN 16385 variable
CRACK_PIN 16386 variable
CRACK_MESSAGE 16387 variable
CRACK_USERNAME specifies the client user identity that's requesting
authentication. The syntax and format of CRACK_USERNAME is specific
to each LAM type.
CRACK_DOMAIN specifies the domain or realm the client is requesting
authentication credentials within. The syntax and format of
CRACK_DOMAIN is specific to each LAM type.
CRACK_PIN specifies the client's PIN. The syntax and format of
CRACK_PIN is specific to each LAM type.
CRACK_MESSAGE specifies an ASCII string to be displayed to the user
upon receipt of the corresponding CHRE payload. CRACK_MESSAGE is
valid for all LAM types. Upon receipt, the contents of
CRACK_MESSAGES SHOULD be displayed to the client user, typically
along with the CHRE challenge.
5. Legacy Authentication Method (LAM) Profiles
Each defined LAM type uses the CHRE payload and LAM attributes in a
different manner. This section profiles the acceptable use of each
for the defined LAM types and details the list of acceptable
attributes for each profile.
The Challenge/Response profile examples include the exchange of
Harkins, Korver, Piper Expires in 6 months [Page 8]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
CERTREQ and CERT payloads which may be used when the client does not
have access to the server's public-key or has access to multiple
server keys. In other examples, the CERTREQ and CERT payloads are
omitted for simplicity, but these MAY be used with any of the defined
profiles. When used, the corresponding SIG payloads MUST contain any
CERTREQ or CERT payloads that were exchanged.
5.1 LAM Profiles: Password
The Password profile supports legacy operating system (OS)
authentication along with proxy-based password authentication
protocols, like RADUIS.
It is assumed in this example that the client has the gateway's
public key, either through a certificate or a trusted raw public key,
prior to initiation of the exchange.
Client (I) Gateway (R)
----------- -----------
HDR1, SAi, KEi, Ni --->
<--- HDR2, SAr, KEr,
SIG1, Nr
HDR3*, CHRE1, PK --->
<--- HDR4*, SIG2
HDR5*, SIG3 --->
Where the digest that is signed (resulting in SIG2 and SIG3) is:
digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr |
KEr | SIG1 | Nr | HDR3 | CHRE1 | PK
[ | HDR4 | SIG2 ]))
For Password, the CHRE payload is used as follows:
Client (I) Gateway (R)
----------- -----------
HDR3*, CHRE1, PK --->
The CHRE1 payload contains the client's password. The format
of the client password is dictated by the corresponding host
OS or proxy authentication server and may be either plaintext
or binary.
The following attributes are defined for Password:
CRACK_USERNAME
CRACK_USERNAME is sent in the client's second message and MUST
Harkins, Korver, Piper Expires in 6 months [Page 9]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
contain the client's username which is used as an index key by
the host OS or proxy password authentication server.
CRACK_DOMAIN
CRACK_DOMAIN is sent in the client's second message and MAY be
used to specify the authentication domain that the client is
requesting authentication within.
5.2 LAM Profiles: One-Time Password
The OTP profile supports both the S/KEY and OTP one-time password
schemes.
It is assumed in this example that the client has the gateway's
public key, either through a certificate or a trusted raw public key,
prior to initiation of the exchange.
Client (I) Gateway (R)
----------- -----------
HDR1, SAi, KEi, Ni --->
<--- HDR2, SAr, KEr,
SIG1, Nr
HDR3*, CHRE1, PK --->
<--- HDR4*, CHRE2
HDR5*, CHRE3 --->
<--- HDR6*, SIG2
HDR7*, SIG3 --->
Where the digest that is signed (resulting in SIG2 and SIG3) is:
digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr |
KEr | SIG1 | Nr | HDR3 | CHRE1 | PK | HDR4 |
CHRE2 | HDR5 | CHRE3 [ | HDR6 | SIG2 ]))
Harkins, Korver, Piper Expires in 6 months [Page 10]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
For OTP, the CHRE payload is used as follows:
Client (I) Gateway (R)
----------- -----------
HDR3*, CHRE1, PK --->
The CHRE1 payload is always empty and contains only any
associated attributes.
<--- HDR4*, CHRE2
The CHRE2 payload contains the OTP server's challenge
text which MUST be displayed to the client user.
HDR5*, CHRE3 --->
The CHRE3 payload contains the client's one-time password
response.
The following attributes are defined for OTP:
CRACK_USERNAME
CRACK_USERNAME is sent in the client's second message and MUST
contain the client's username which is used as an index key by
the OTP server.
CRACK_MESSAGE
CRACK_MESSAGE is optionally sent in any server message and MAY
by used by the server to provide optional text to be displayed
to the user along with any associated challenge text.
5.3 LAM Profiles: Challenge/Response
The Challenge/Response profile supports various token cards that
follow a standard challenge/response exchange. The client's token
card information (the response) depends on the gateway's request (the
challenge).
It is assumed in this example that the client does not have the
gateway's public key and requires a certificate issued by a trusted
Certification Authority. Note that in this case, identity protection
of the gateway is lost. Whether a certificate is requested and sent
or not, the client's identity is never open to a passive attack (i.e.
the client retains identity protection regardless).
Harkins, Korver, Piper Expires in 6 months [Page 11]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
The following example shows an exchange where a full
challenge/response exchange is followed:
Client (I) Gateway (R)
----------- -----------
HDR1, SAi, KEi, Ni,
CERTREQ --->
<--- HDR2, SAr, CERT, KEr,
SIG1, Nr
HDR3*, CHRE1, PK --->
<--- HDR4*, CHRE2
HDR5*, CHRE3 --->
<--- HDR6*, SIG2
HDR7*, SIG3 --->
Where the digest that is signed (resulting in SIG2 and SIG3) is:
digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | CERTREQ | HDR2 |
SAr | CERT | KEr | SIG1 | Nr | HDR3 | CHRE1 | PK |
HDR4 | CHRE2 | HDR5 | CHRE3 [ | HDR6 | SIG2 ]))
If more challenges were required to authenticate this client, message
six would be another CHRE payload and not a SIG payload. This would
force message seven to be another CHRE payload. This can be repeated
until the gateway authenticates the client (or authentication fails,
see below). If this was the case, messages six and seven would be
different and the exchange would be more than seven messages. The
authenticating digest would therefore be correspondingly different.
Alternatively, some challenge-response tokens cache their last
computed result and do not require a challenge from the gateway
unless they get out of sync (perhaps due to intrusion detection). In
this case, the gateway may be able to authenticate the client in the
second message and would return, assuming success, SIG2 instead of
CHRE2. The authenticating digest would therefore be correspondingly
different.
Harkins, Korver, Piper Expires in 6 months [Page 12]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
The following example shows an exchange where the client can pre-
compute his expected response:
Client (I) Gateway (R)
----------- -----------
HDR1, SAi, KEi, Ni,
CERTREQ --->
<--- HDR2, SAr, CERT, KEr,
SIG1, Nr
HDR3*, CHRE1, PK --->
<--- HDR4*, SIG2
HDR5*, SIG3 --->
Where the digest that is signed (resulting in SIG2 and SIG3) is:
digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | CERTREQ | HDR2 |
SAr | CERT | KEr | SIG1 | Nr | HDR3 | CHRE1 | PK
[ | HDR4 | SIG2 ]))
For Challenge/Response, the CHRE payload is used as follows:
Client (I) Gateway (R)
----------- -----------
HDR3*, CHRE1, PK --->
When the client is using a token that can compute the
next expected response without requiring a challenge,
the CHRE1 payload contains the expected response and
any associated attributes. When the client does not
have an expected response, or has chosen not to use
the current one for whatever reason, the CHRE payload
is empty and contains only any associated attributes.
<--- HDR4*, CHRE2
The CHRE2 payload contains the gateway's challenge
text which MUST be displayed to the client user.
HDR5*, CHRE3 --->
The CHRE3 payload, when used, contains the client's
response to the gateway challenge.
The following attributes are defined for Challenge/Response:
CRACK_USERNAME
CRACK_USERNAME is sent in the client's second message and MUST
Harkins, Korver, Piper Expires in 6 months [Page 13]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
contain the client's username which is used as an index key for
authentication by the server.
CRACK_PIN
CRACK_PIN is optionally sent in any client message and MAY by
used if the authentication protocol also requires the client
to provide a PIN.
CRACK_MESSAGE
CRACK_MESSAGE is optionally sent in any server message and MAY
by used by the server to provide optional text to be displayed
to the user along with any associated challenge text.
5.4 LAM Profiles: SecurID
The SecurID profile supports the RSA SecurID protocol. With SecurID
the client will be passing the output of the SecurID card as the body
of the first CHRE payload (in the second message it sends), and its
identity in the body of the IDi payload. Assuming the client and
gateway are in sync (i.e. they are not in "Next Code" mode) there is
a single CHRE payload.
It is assumed in this example that the client has the gateway's
public key, either through a certificate or a trusted raw public key,
prior to initiation of the exchange.
Harkins, Korver, Piper Expires in 6 months [Page 14]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
The following example shows a typical SecurID authentication:
Client (I) Gateway (R)
----------- -----------
HDR1, SAi, KEi, Ni --->
<--- HDR2, SAr, KEr,
SIG1, Nr
HDR3*, CHRE1, PK --->
<--- HDR4*, SIG2
HDR5*, SIG3 --->
Where the digest that is signed (resulting in SIG2 and SIG3) is:
digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr |
KEr | SIG1 | Nr | HDR3 | CHRE1 | PK
[ | HDR4 | SIG2 ]))
If the client and gateway are slightly out of sync (i.e. "Next Code"
mode) the gateway will respond with an additional challenge to which
the client must respond with another CHRE payload. Because there are
multiple CHRE payloads in this example the first is denoted CHRE1,
the second CHRE2, etc. Because "Next Code" requires additional
messages to be sent, the authenticating hash will be different than
when the client and gateway are in sync (hopefully this is obvious).
The following example shows a SecurID authentication when "Next Code"
mode is required:
Client (I) Gateway (R)
----------- -----------
HDR1, SAi, KEi, Ni --->
<--- HDR2, SAr, KEr,
SIG1, Nr
HDR3*, CHRE1, PK --->
<--- HDR4*, CHRE2
HDR5*, CHRE3 --->
<--- HDR6*, SIG2
HDR7*, SIG3 --->
Where the digest that is signed (resulting in SIG2 and SIG3) is:
digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr |
KEr | SIG1 | Nr | HDR3 | CHRE1 | PK | HDR4 |
CHRE2 | HDR5 | CHRE3 [ | HDR6 | SIG2 ]))
Harkins, Korver, Piper Expires in 6 months [Page 15]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
For SecurID, the CHRE payload is used as follows:
Client (I) Gateway (R)
----------- -----------
HDR3*, CHRE1, PK --->
The CHRE1 payload contains the current Passcode displayed
by the client's SecurID token.
<--- HDR4*, CHRE2
The CHRE2 payload, when used, signifies the ACE server is
requesting a "Next Code" response. The CHRE2 payload is
always empty and contains only any associated attributes.
HDR5*, CHRE3 --->
The CHRE3 payload, when used, contains the client's next
Passcode displayed by the client's SecurID token.
The following attributes are defined for SecurID:
CRACK_USERNAME
CRACK_USERNAME is sent in the client's second message and MUST
contain the client's username which is used as an index key by
the ACE server.
CRACK_PIN
CRACK_PIN is sent in the client's second message and MAY be
used when the SecurID card is not a PINPAD card.
CRACK_MESSAGE
CRACK_MESSAGE is optionally sent in any server message and MAY
by used by the server to provide optional text to be displayed
to the user along with any associated challenge text.
Harkins, Korver, Piper Expires in 6 months [Page 16]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
5.5 LAM Profile Matrix
Each of the LAM's supported by IKE Challenge/Response fall into one
of the defined LAM profiles. This section details the classification
for those methods, including all of the types defined for the
experimental XAUTH protocol [PB99].
Password
DIAMETER
LDAP
NDS (Netware Directory Services)
NT Domain
RADIUS
TACACS
TACACS+
UNIX Login
OTP
OTP
S/KEY
Challenge/Response
AXENT Defender
CheckPoint ActivCard
CRYPTOCard CRYPTOCard
Digital Pathways SNK
LeeMah InfoCard
Secure Computing SafeWord (Enigma Logic DES Gold)
SecurID
RSA SecurID
6. The IKE Challenge/Response Vendor ID Signature
This memo describes a protocol that lives on top of [MSST98] and as a
companion to [HC98]. These standards-track protocols reserve some of
their "magic number" space for private use by mutually consenting
parties. It is from this number space that this memo obtains some of
the "magic numbers" it needs (payload types, exchange value,
attributes). As part of the "mutually consenting parties" part of
the requirement implementors of this protocol are encouraged to use a
Vendor ID payload to announce willingness to engage in this protocol.
The contents of the Vendor ID payload will be the following
hexadecimal string: 0x0d33611a5d521b5e3c9c03d2fc107e12, which is the
result of an MD5 hash of "IKE Challenge/Response for Authenticated
Cryptographic Keys" without the quotation marks. An [HC98]
implementation that implements this protocol that obtains a Vendor ID
payload with this string in the body of the payload can assume that
Harkins, Korver, Piper Expires in 6 months [Page 17]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
the sender of the Vendor ID payload has likewise implemented this
protocol and is therefore a "mutually consenting party".
If this protocol is advanced to standards-track status IANA will
assign new "magic numbers" out of the appropriate number spaces (the
"magic numbers" will no longer be from the private use ranges) and
the requirement to use a Vendor ID payload will go away.
7. Security Considerations
The channel that results from the exchange of the first two messages
is secured because the gateway signs his Diffie-Hellman public value
and it is the resulting SKEYID state (see [HC98]) that protects the
channel. The client, though, does not sign his Diffie-Hellman public
value as this would be a Chicken-and-Egg problem. The channel is
secured from the client's perspective because he knows that the
gateway was the actual source of the Diffie-Hellman public value.
The channel is secured from the gateway's perspective because the
client would not have sent his sensitive information if a man-in-the-
middle was detected.
While this seems to be a weak form of assurance, the exchange could
only be foiled by an intentionally malfunctioning client and if that
is the case then all bets are off regardless of the method of
authentication. (If Alice and Bob establish IPSec SA's in the
traditional fashion, using a [HC98] exchange nothing could stop Alice
from sending all the sensitive information Bob conveys to her to
Eve.) Also note that this technique is used in other popular on-line
certificate enrollment schemes ([MLSW99]).
This subtle authentication technique is only used to validate the
client's public key. The SKEYID state which will be used to
establish subsequent security associations for other security
services (such as those from [Pip98]) is authenticated in the same
fashion as the other digital signature methods from [HC98].
As noted, this whole scheme can fail if the client is intentionally
malicious. Also, if the token card and knowledge of how to generate
valid credentials is conveyed to a third party this scheme would fail
(but not due to any protocol failure).
The public key that the client authenticates using his legacy
authentication method and the corresponding private key used to
authenticate the SKEYID state SHOULD be freshly generated immediately
prior to use and SHOULD only be used once.
If the client does not have the gateway's public key prior to
initiation of the protocol the identity of the gateway can be
Harkins, Korver, Piper Expires in 6 months [Page 18]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
obtained with a passive attack.
Acknowledgments
The authors would like to thank the sales and marketing staff of all
companies who said, "Just give us something that uses token cards!"
We would like to recognize Roy Pereira and Stephane Beaulieu, authors
of [PB99], which was borrowed from liberally in creation of this
memo. Thanks also to Lambert. He's not like all the other sheep.
References
[Bra96] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[CR98] P. Calhoun, A. Rubens, "DIAMETER - Base Protocol",
draft-calhoun-diameter-02.txt, March 1998, a work in
progress.
[DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard",
FIPS 186, May 1994.
[Hal95] N. Haller, "The S/KEY One-Time Password System", RFC1760,
February 1995.
[HC98] D. Harkins, D. Carrel, "The Internet Key Exchange",
RFC2409, November 1998.
[HM96] N. Haller, C. Metz, "A One-Time Password System", RFC1938,
May 1996.
[MLSW99] M. Myers, X. Liu, J. Schaad, and J. Weinstein, "Certificate
Management Messages over CMS", draft-ietf-pkix-cmc-05.txt,
a work in progress.
[MSST98] D. Maughan, M. Schertler, M. Schneider, J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC2408, November 1998.
[PB99] R. Pereira, S. Beaulieu, "Extended Authentication within
ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-05.txt,
September, 1999, a work in progress.
[Pip98] Piper, D., "The Internet IP Security Domain Of
Interpretation for ISAKMP", RFC 2407, November 1998.
[PKCS1] B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
Harkins, Korver, Piper Expires in 6 months [Page 19]
INTERNET DRAFT IKE Challenge/Response October 18, 1999
Specifications Version 2", September 1998.
[RASW97] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC2138,
April 1997.
[RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems",
Communications of the ACM, v. 21, n. 2, February 1978.
Authors' Address
Dan Harkins <dharkins@network-alchemy.com>
Brian Korver <briank@network-alchemy.com>
Derrell Piper <ddp@network-alchemy.com>
Network Alchemy
1538 Pacific Ave
Santa Cruz, CA 95060-9311
United States of America
Harkins, Korver, Piper Expires in 6 months [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-22 06:13:34 |