Tải bản đầy đủ
2 ISAKMP Configuration Method 134

2 ISAKMP Configuration Method 134

Tải bản đầy đủ

The Fifth Puzzle Piece: IKE and the Road Warrior


Table 6.1
Authentication Negotiation Schemes


(gateway only)

(gateway only)





Phase 1


Phase 1

(gateway and (gateway)
client host)

and user)

(gateway and
client host)

and user)

Phase 1







Phase 1-1/2

Phase 1-1/2

Phase 1

Post–phase 2

Pre–phase 1


Configuration XAUTH





by the ISAKMP configuration method, which defines the requisite exchange
mechanism and payloads.
To IKE’s arsenal of payload types, the configuration method adds a
new one: the attribute payload. The data carried by that payload are interpreted differently, based on the payload’s message type. The configuration
method defines four message types:
• Request. One of the peers requests information from the other.
• Reply. The recipient of the request message responds with the

requested information.
• Set. One of the peers informs the other of the value of some data.
• Acknowledge. The recipient of the set message signals receipt of that
message and acceptance or refusal of the data values.

Each of the messages contains a single attribute payload, which consists
of zero or more IKE-type attributes. In a request message, those attributes for
which the sender is requesting information have either an empty value or a


Demystifying the IPsec Puzzle

suggested value. In the resulting reply message, the peer fills in the values of
some or all of the requested attributes; if that is either not possible or not
desirable, the peer sends an empty attribute payload. In a set message, the
sender suggests values for the specified attributes. In the resulting acknowledge message, the peer returns those attributes whose values it has accepted
but does not return the values themselves; those attributes whose suggested
values were rejected are not returned by the peer.
What types of information can be exchanged using the configuration
method? The authentication-related attributes [9], some or all of which
might be used by a specific authentication mechanism, are the following:
• Authentication type. The authentication protocol or mechanism

to be used. Currently, the only ones specifically identified are
RADIUS-CHAP, OTP, and S/KEY. They demand a specific
sequence of messages and attributes. To use one of these methods,
the server must specifically propose one or more authentication
types, and the client must agree to the method or methods to be
used. Numerous other authentication methods, including Unix and
NT Domain Logins, SecurID, and DIAMETER, are included in
an umbrella generic authentication type. If no authentication type is
proposed, it is assumed to be one of the generic types.

• User name. The unique identifier used by the user to sign on to the

authentication server. It can be a user name log-on string, an email
address, an X.500 distinguished name, or any other unique identifier that is acceptable to the server.

• User password. The user’s password that serves to verify the user’s

identity to the server.

• Passcode. The single-use password generated by an authentication

token (i.e., a SmartCard) or software program.

• Textual message. An informative message, prompt, or diagnostic

message sent to the human user by the authentication server.

• Challenge string. An unpredictable value sent by the server to the

user’s authentication device or software, to be used in its calculations. Different authentication protocols use a challenge string in
diverse ways. For example, RADIUS-CHAP uses it to hide the
secret password by generating a cryptographic hash of the challenge
string and the password.

The Fifth Puzzle Piece: IKE and the Road Warrior


• Domain. The authentication domain. This value is specific to the

authentication type.

• Status. Indicates whether the authentication succeeded or failed. The

server can send either value, but the client can indicate only failure.

The following configuration-related attributes [10] can be used by a server to
assign values to a client.
• IP address (IPv4 or IPv6). An internal or private network address

that the server assigns to the client.

• Network mask (IPv4 or IPv6). The network mask of the internal


• Subnet (IPv4 only). The subnet addresses of one or more internal

subnets protected by the gateway.

• Domain name system (DNS) server (IPv4 or IPv6). The addresses of

one or more DNS servers for the internal network.

• Windows Internet Naming Service (WINS) server (IPv4 or IPv6). The

addresses of one or more WINS servers for the internal network.

• Dynamic Host Configuration Protocol (DHCP) server (IPv4 or IPv6).

The addresses of one or more DHCP servers for the internal

• Address expiration. Number of seconds that the internal IP address

that was assigned via the configuration method remains valid. The
address actually expires when one of several events occurs: when
the address expiration limit is reached, when the phase 1 SA used
to protect the exchange expires, (optionally) when the phase 2 SA
nego- tiated following the configuration method expires, or (if none
of those applies) at an implementation-dependent time mandated
by the client.

Several useful housekeeping-type attributes also have been defined [10].
• Version. Used by consenting implementations to communicate

which software version or applications are supported.

• Attributes supported. Used if, prior to an exchange, one of the peers

wants to query which attributes are supported by the other peer.


Demystifying the IPsec Puzzle

The paradigm of repeated request messages and interspersed reply
messages is well suited for the types of authentication methods currently
used in IKE. The set and acknowledge pair of messages is appropriate to end
the exchange and ensure that the peers agree on the success or failure of the
When the configuration method is used for road warrior authentication, it needs to follow a phase 1 exchange; the configuration method
messages are then encrypted and authenticated by the ISAKMP SA. That is
why this type of exchange is called phase 1-1/2. It is not a phase 2 exchange,
because it does not result in the negotiation of an IPsec SA, but it is dependent on the phase 1 SA. In such a case, each message consists of the ISAKMP
header, a hash payload, and the characteristic attributes payload. The configuration method exchange is connected to the phase 1 exchange through
the use of the identifying cookies but is distinguished from the phase 1
exchange through the use of a unique message ID. The phase 1 encryption
key, SKEYID_e, is used to encrypt each message, and the phase 1 authentication key, SKEYID_a, is used to generate a keyed hash of the message ID
and the attributes payload. The encryption IV for the first message of the
exchange is computed using the same formula used to compute the initial IV
in a phase 2 exchange; subsequent IVs are taken from the last block of the
previous message.
The configuration method can be used to exchange other information
as well. Prior to an authentication-related configuration method exchange,
the server might want to ensure that a client can handle the requisite
attributes or that the client’s authentication application’s version can communicate with the server. If that exchange takes place before the ISAKMP SA
has been established, and if the information is not sensitive, those messages
can be sent in the clear. Following a successful authentication-related
exchange, the server can use the configuration method messages to assign
configuration-related information to the client. For the road warrior to have
full access to the network, it can be useful to assign it an internal network
address. The address generally should be accompanied by other networkrelated information, such as server addresses and a network mask. Additional
network parameters that may also be required (but which are not discussed
in the context of the configuration method) are [3] PMTU, router-related
information, static routes, additional servers (SMTP, POP, WWW), and
other server-related options. The policy-related ramifications of those configuration choices are explored in Chapter 9.
The configuration method is not a stand-alone protocol. Rather, it is
an enabler for exchanges that are more fully defined in other protocols, such

The Fifth Puzzle Piece: IKE and the Road Warrior


as hybrid authentication and XAUTH. The original phase 1 negotiations
consist of mutual, symmetric peer authentication; IKE negotiations based
on the configuration method result in mutual authentication, but in an
asymmetric manner.

6.3 Extended Authentication
Picture a scenario in which a gateway needs to authenticate both a communicating host and its user. When does that happen? Perhaps a company has
a number of laptops preconfigured with a common road warrior preshared
secret key or with certificates that can be used to authenticate the particular
host. That does not ensure that the laptop’s user has the proper credentials to
access the company’s network protected by the gateway. That is a job for
Extended Authentication (XAUTH).
XAUTH begins with a mostly normal phase 1 exchange, with just two
modifications: the peers exchange a vendor ID payload whose data consist of
a keyed hash of the XAUTH document’s Internet Draft name and version
number, to ensure that both are operating under the same rules and assumptions. XAUTH also has its own special authentication method IDs, which
distinguish this type of phase 1 SA from others, guaranteeing that the phase 1
SA will not be used to negotiate an IPsec SA without the intervening
XAUTH exchange. The XAUTH authentication method ID conveys three
pieces of information.
• The ISAKMP authentication method (preshared secret key, RSA

digital signature, DSS digital signature, encryption, or revised
encryption) to be used in phase 1.
• The role assumed by the road warrior (initiator or responder), that is,
the entity that needs to be authenticated via XAUTH. The majority of
these negotiations most likely will be initiated by the road warrior; however, if the gateway is the initiator, it must somehow know beforehand
that the peer is a road warrior and that XAUTH is required.
• An XAUTH authentication will follow the phase 1 negotiation.
Once the phase 1 exchange is completed, the gateway has fully authenticated itself to the road warrior, and an ISAKMP SA has been established
between the gateway and the road warrior’s host. That is followed by a unidirectional authentication, which constitutes the XAUTH exchange, in which
the road warrior assumes the role of a client and proves his or her identity to


Demystifying the IPsec Puzzle

the gateway. That generally is accomplished through the use of an existing
authentication server that lies behind the gateway. The gateway acts as a conduit between the authentication server and the client, but all communications between client and gateway are protected by the ISAKMP SA.
The XAUTH exchange takes the form of one or more request messages
sent from the server (via the gateway) to the client and the same number of
reply messages from client to server. If the authentication method is known
in advance, or once the authentication method has been agreed on, the
attributes payload contains those authentication-related attributes dictated
by the particular authentication mechanism. A successful negotiation is followed by a set message from server to client that consists of a status attribute
whose value is OK, followed by an acknowledge message with an empty
status attribute from client to server. If the server is not satisfied with the
negotiation, the status attribute’s value will be FAIL. If at any point the client
is unable to complete the negotiation, it sends a reply message with a status
attribute set to FAIL. If the XAUTH exchange fails, the ISAKMP SA must
be deleted, because a phase 2 negotiation cannot now follow.
For a paranoid (or prudent) gateway, the user can be periodically
reauthenticated, without necessitating a new phase 1 negotiation, as long as
the ISAKMP SA has not expired.
A number of criticisms have been leveled at XAUTH. It is a new, relatively untested but complex protocol that is layered on top of IKE, another
complex protocol. The fact that it is an open-ended protocol, rather than one
with a fixed number of messages, leaves it open to denial-of-service attacks.
The use of preshared keys with XAUTH presents a choice of major drawbacks: XAUTH in Main Mode with preshared keys is vulnerable to a
man-in-the-middle attack by another host that possesses the preshared key;
Aggressive Mode eliminates that problem but does not provide identity protection. The XAUTH messages that enable a gateway to send a prompt string
to a user contain a considerable amount of known plaintext. In addition, the
use of XAUTH gives rise to an infrastructure that encourages continued support of legacy authentication mechanisms, rather than supporting a phased
conversion to client certificates. Figure 6.2 illustrates a sample XAUTH
RADIUS-CHAP negotiation.

6.4 Hybrid Authentication
Classical XAUTH cannot be used in some road warrior cases. If the host
has no means of authenticating itself to the gateway, the phase 1 XAUTH



Username = “joe”,
Password = 987654321987654321


Username = “”, Password = “”,
Challenge = 13579246801357924680)




The Fifth Puzzle Piece: IKE and the Road Warrior

SET (Status = OK)

ACK (Status = “”)

Figure 6.2 Sample XAUTH negotiation: RADIUS-CHAP.

exchange cannot take place. This can happen in a case where a road warrior is
using someone else’s host, for example, an Internet kiosk in an airport, shopping mall, or library, or where the road warrior’s own host is not equipped
with the appropriate host-based authentication credentials. Another configuration method variant, called Hybrid Authentication [11], can be used in
such a case. It involves a special phase 1 negotiation, which is followed by an
XAUTH authentication negotiation.
The phase 1 negotiation, which can be either Main Mode or Aggressive
Mode, is based on a one-way peer authentication, in which the gateway
authenticates itself to the remote user. Either of the digital signature authentication methods can be used to authenticate the gateway; in place of the
signed hash that normally would be used to authenticate the road warrior, an
unsigned keyed hash is sent. Because the client’s identity cannot be proved
through any phase 1 mechanism, it does not have any place in this phase 1
negotiation. The client ID payload generally contains an empty client ID;
thus, ID protection for the road warrior is preserved in Aggressive Mode as
well as in Main Mode. If the gateway sends a CR payload, the road warrior
generally responds with an empty CERT payload.
Hybrid authentication also has its own special authentication method
IDs, which convey three pieces of information.
• The ISAKMP authentication method (RSA digital signature or DSS

digital signature) to be used in phase 1.

• The role assumed by the road warrior (initiator or responder), that

is, the entity that needs to be authenticated via XAUTH. The


Demystifying the IPsec Puzzle

majority of these negotiations most likely will be initiated by the
road warrior; however, if the gateway is the initiator, it somehow
must know beforehand that the peer is a road warrior and that
XAUTH is required.
• This is a phase 1 hybrid authentication exchange, which will be fol-

lowed by an XAUTH authentication.

The phase 1 negotiation is followed by an XAUTH exchange, which
authenticates the road warrior using one of the challenge-response authentication methods appropriate for XAUTH. This negotiation is initiated by the
gateway and protected by the ISAKMP SA. The ISAKMP SA cannot be used
to protect any other type of exchange until the XAUTH exchange successfully terminates; if XAUTH fails, the ISAKMP SA must be deleted.
Hybrid authentication is layered on top of XAUTH, so it shares most
of XAUTH’s drawbacks while adding an additional layer of complexity.
Because the gateway is authenticated through digital signatures and not
through preshared secret keys, it is not vulnerable to a man-in-the-middle

6.5 Challenge-Response for Authenticated Cryptographic Keys
Challenge-Response for Authenticated Cryptographic Keys (CRACK) [12]
is a new phase 1 negotiation that includes the legacy authentication negotiation as part of phase 1. That ties the authentication more directly to phase 1.
It most closely resembles the phase 1 digital signature negotiations and uses a
digital signature to authenticate the gateway, so the authentication method
must be one of the digital signature variants. A CRACK exchange is always
initiated by the client. The first two messages of the exchange include all
the payloads that normally are distributed over the first four IKE phase 1
messages. Because CRACK is not yet a standard, it is suggested that the peers
exchange a vendor ID payload whose data consist of a keyed hash of the
CRACK document’s Internet Draft name and version number, to ensure
that both are operating under the same rules and assumptions. Because the
Diffie-Hellman exchange occurs in the first two messages, the cookie
exchange does not fulfill one of its normal roles, the prevention of a denialof-service attack. If the client does not already possess the gateway’s public
key, it can request it via a CR payload in message 1; the gateway then sends
the certificate in a CERT payload in message 2. To ensure that the gateway’s

The Fifth Puzzle Piece: IKE and the Road Warrior


Diffie-Hellman value originates from the gateway and to protect it from
tampering, the gateway includes a signed hash of its Diffie-Hellman value in
message 2. If the gateway has multiple public keys used for digital signatures,
it can include a CERT payload containing the appropriate key, even if the
client has not requested the certificate. Once the first two messages have been
exchanged, the shared symmetric keys SKEYID and its derivatives
SKEYID_a, SKEYID_e, and SKEYID_d are calculated, using the same calculations that are used for a standard IKE phase 1 digital signature exchange.
The client trusts this secure channel because the gateway has signed its
Diffie-Hellman value, and the gateway trusts it because the client is willing
to entrust its authentication information to the channel. In addition, the
gateway will not allow the client to access any part of the protected network
until the authentication has succeeded, thus verifying the client’s identity.
The first two messages are followed by the legacy authentication negotiation, which is protected by the secure channel established once the DiffieHellman exchange has taken place. This negotiation consists of one or more
messages, depending on the demands of the particular legacy authentication
method. It necessitates two additional IKE payload types:
• Public key payload. The client uses the public key payload to send

its public key, which will be used for a signed hash following the
authentication negotiation. Once the client has proved its identity
via the authentication negotiation, the gateway can trust its publicprivate key pair.

• Challenge-response payload. This payload is used by both the client

and the gateway to conduct the authentication negotiation. It contains the legacy authentication method’s ID along with the relevant
challenge-response information.

The first challenge-response payload is always sent by the client, along
with the public key payload. If the authentication consists only of information supplied by the client and verified by the gateway (e.g., either a longterm password or a one-time password coupled with a user ID), then only
one message with a challenge-response payload is required. For challengeresponse or other more complex methods, multiple challenge-response payloads are exchanged. The gateway terminates the authentication in one of
two ways: If the client has been successfully authenticated, the gateway sends
a signature payload containing a digital signature of the cryptographic hash
of all of the payloads, including headers, that preceded the message. The