Network Working Group P. Srisuresh
INTERNET-DRAFT Jasmine Networks
Expires by July 24, 2001 J. Vilhuber
Cisco Systems
January 2001
IKE extensions to support Dynamic Policies
<draft-srisuresh-ike-policy-extensions-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. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
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
As IPsec is widely deployed, there is increasing need to negotiate
security keys using IKE at application level granularity.
IKE, as currently proposed, has restrictions in negotiating keys
for applications with bundled sessions and complex policies.
The draft identifies the problem with IKE and suggests extensions
to make IKE application and policy friendly. The proposed solution
suggests extensions to the conceptual operation of IPsec as well as
IKE, but does not require changes to existing IKE payloads. The
document introduces a new policy payload that complements existing
IKE payloads and suggests replacing ID payload with the Policy
payload, in Quick mode.
Srisuresh & Vilhuber [Page 1]
Internet-Draft Policy extensions to IKE January 2001
1. Introduction and Overview
IP packets may be subject to IPsec security enforcement by peering
end nodes or enroute by intermediate systems. The enforcement is
policy based. As IPsec is widely deployed, there is increasing
desire to make these policies granular to a specific application
detail. The focus of the document is facilitating enforcement of
application driven dynamic policies across peering nodes, using
IKE.
IKE protocol uses part of Oakley and part of SKEME ([SKEME] in
conjunction with ISAKMP ([ISAKMP])to obtain authenticated keying
material for use with ISAKMP, and for IPsec DOI security
associations such as AH ([AH]) and ESP (ESP]. As such, any
changes and extension to IKE ([IKE]) could potentially mandate
changes to every one of the sub-components. This document
identifies extensions required of each of the sub-components to
bring about the appropriate policy extensions to IKE Phase-II
based security associations for IPsec DOI ([IPSEC-DOI).
2.0 Terms and Technical Definitions
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT"
and "MAY" that appear in this document are to be interpreted as
described in [STD-KEYWORDS]. Further, the security terms
defined in [IPSEC] and keywords used in [IKE] have been used
profusely throughout the document. As such, prior understanding
of [IPSEC] and [IKE] are a requirement for reviewing this
document.
2.1 Technical Definitions
2.1.1 Security Gateway
A security gateway refers to an intermediate system that
implements IPSec protocols. For example, a router or a
firewall implementing IPSec is a security gateway.
2.1.2 Security Domain
A set of communicating entities and resources that share a
common security policy enforced at one or more enforcement
agents or at an individual host. The definition of security
domain applies to networks protected by security gateways as
well as to single hosts, since a host may be the enforcer of
its own policies. Security domains could exist inside other
security domains.
Srisuresh & Vilhuber [Page 2]
Internet-Draft Policy extensions to IKE January 2001
2.1.3 Application Level Gateway (ALG)
Application Level Gateway (ALG) is a trusted entity that has
application specific knowledge it can use to determine dynamic
security policy requirements for the application. ALG on an
IPsec enforcement node may use the information to update the
SPD of IPsec and to interface with IKE (directly or
indirectly) to enforce the policy extensions with peering
Ipsec node.
2.1.4 Dynamic Policy Agent (DPA)
Dynamic Policy Agent (DPA) is an entity that interfaces with
ALGs, IKE and IPsec-SPD to keep the applications, Ipsec security
engine and policy enforcement with peers in sync. Specifically,
the Dynamic Policy Agent interfaces with the ALGs to gather
the dynamic policy requirements of applications, exchanges the
information with peering security node and updates the
IPsec-SPD to enforce security.
2.1.5 Policy Payload
Policy Payload is a new ISAKMP payload introduced to facilitate
flexible definition of policy description and dynamic updates to
the original description.
3. Problem with dynamic policy enforcement in IPsec and IKE
We will consider the following diagram to illustrate IPsec policy
enforcement, as packets traverse the enforcement devices. For the
purposes of this document, a security gateway is an intermediate
system implementing IPSec.
An application on Host-A that needed to communicate with Host-B,
in a different administrative domain would typically cross a
minimum of two policy enforcement devices - A security gateway
local to the administrative domain and another local to the peer
node's administrative domain. Figure 3.1 below is meant to be an
example and does not cover the various configurations in which
administrative domains may be connected to each other. In
practice, there may be multiple security gateways. However,
the diagram does provide the necessary base to address policy
specific issues. Further, even though we selected a security
Gateway to illustrate, the discussion is applicable to both
transport and tunnel odes of IPsec, equally well.
Srisuresh & Vilhuber [Page 3]
Internet-Draft Policy extensions to IKE January 2001
________________
( )
+--+ ( Administrative )
|__|------( Boundary - B )
/____\ ( )
Host-B (________________)
|
+--------------------+
| Security Gateway |
| - GW-B |
+--------------------+
__________ |
( ) |
+-----------------+ ( ) +-----------------+
| Border Router-A |--( Internet )--| Border Router-B |
+-----------------+ ( ) +-----------------+
| (__________)
|
+--------------------+
| Security Gateway |
| - GW-A |
+--------------------+
|
----------------
( )
+--+ ( Administrative )
|__|------( Boundary - A )
/____\ ( )
Host-A (________________)
Figure 3.1: Security Gateways connected across the Internet.
A security gateway operating in tunnel mode may encrypt and/or
authenticate a packet and forward it through a tunnel destined to
peer security gateway. The peer gateway in turn, de-tunnels the IP
packet from the tunnel and reverse-transforms it to extract the
original packet. It then forwards it to the destination, as
specified in the original packet [Ref 8]. There is however a
pitfall for certain type of applications.
An application comprised of a session bundle may work only
partially. For example, a security Gateway cannot create an SA
(one or more) that can secure all session of the FTP application
(i.e., FTP control and data sessions), unless your policy is to
preserve all of TCP. Here is why. You could have a policy that
preserves FTP control session by selecting src or Dest TCP port
Srisuresh & Vilhuber [Page 4]
Internet-Draft Policy extensions to IKE January 2001
to be 21. But, the data session parameters set by, say PASV
response, will decide the port number used by the ensuing data
session. Only the end-nodes know the data session port numbers.
Dynamically selected ports in a session cannot not be known to
IKE or IPsec, unless IKE and Ipsec have application specific
knowledge to examine the payload. Even as applications can
notify the security Gateway of the data sessions, IKE does not
know to add or delete sessions to reuse of the same key (as
used for FTP control session) for securing data sessions.
3. Suggested changes to Security policy enforcement in IPsec and IKE
The solution we are about to propose requires changes in the way
the IPsec SPD rules are defined and accessed. A Dynamic policy
Agent (DPA) is introduced to interface with IPsec-SPD to keep
the SPD in sync with the requirements of end-to-end applications.
Further, additional changes in IKE are proposed to communicate
dynamic policy updates securely across peering security nodes.
3.1 Dynamic Policy Agent (DPA)
A new entity, labeled Dynamic Policy Agent (DPA) is envisioned to
coordinate exchange of dynamic policy updates between peering IKE
nodes, followed by an update of the same in the local IPsec SPD.
DPA uses Policy-ID to co-ordinate these policy updates.
3.2 Suggested changes to IPsec SPD
Application specific IPsec policy rules in SPD must be allowed to
be associated with an application specific ALGs. Each policy rule
in the SPD will also have a 4-octet long Policy-ID to uniquely
identify the policy within the node. These Policy rules, along
with their policy ID are exchanged with peering IKE nodes.
Specification of an ALG for a policy rule is optional. When an
ALG is specified in the policy, the ALG will become a part of
the IPsec data path. The ALGs are trusted entities by the
application and will have application specific knowledge to
determine the dynamic policy requirements of an application.
These ALGs interface with dynamic policy agent (DPA) to notify
policy updates to the existing policy rules in IPsec SPD.
Changes to IPsec data path at the enforcement points may be
captured as follows in the following two diagrams.
Srisuresh & Vilhuber [Page 5]
Internet-Draft Policy extensions to IKE January 2001
+---------+ +---------+ +------------+
| | | | | |
Outgoing |Does the | Yes |Redirect | SA |Perform | Forward
-------->|pkt match|---->|pkt to |----->|Outbound |------->
Packet |Outbound | |ALG, if | Keys |Security | Packet
|Policy? | |specified| |(ex:encrypt)|
+---------+ +---------+ +------------+
Figure 3.2.1. Operation of IPsec on outgoing packets.
+------------+ +---------+ +---------+
Incoming |Perform | Clear |Does the | Yes |Redirect | Send to
-------->|Inbound |------>|pkt match|---->|pkt to |------->
Packet |Security | Pkt |Inbound | |ALG, if | Appl.
|(ex:Decrypt)| |Policy? | |specified|
+------------+ +---------+ +---------+
Figure 3.2.2. Operation of IPsec on Incoming packets
3.3. Suggested changes to IKE
A new type of Policy payload is added to the list of ISAKMP
payloads. This payload is to be used only in IKE phase II and is
designed to be flexible, so as not to be constrained to the form of
a single rule. Each new policy will have a policy-ID associated with
it. A policy may be defined using one or more policy payloads. The
payload allows for the specification of a range of addresses and
transport ports, while also permitting selective exclusion.
3.3.1. Provide Dynamic Policy Updates(Add/Delete) to Enforcement Points
For IPsec, the end nodes should be able to influence policies
associated with an IPsec SA dynamically. This is independent of
whether the SA was between the peers directly or between 2 gateway
nodes in between. An end node should be able to add/delete policies
dynamically from an SA. Without this, application specific policies
are hard to enforce on an SA.
For instance, take a policy that mandates security for FTP
application between 2 hosts. Once a SA is established for securing
the control session of the FTP application, the end nodes ought to
be able to (a) add/delete newer policies (describing the parameters
of ensuing FTP data sessions) to the existing FTP control session SA,
or (b) create newer SAs dynamically confirming to dynamically
Srisuresh & Vilhuber [Page 6]
Internet-Draft Policy extensions to IKE January 2001
generated policy parameters.
Exchange of Dynamic policy updates in IKE phase II is made possible
with the notion of DPA. The DPA interacts with IKE locally to either
notify IKE to initiate a policy update or to confirm the validity of
a proposed update coming in from a remote node. IKE peers exchange
new policies and the policy updates securely in quick mode. The
policy updates may involve addition or subtractions to the original
policy rule. Each policy rule is uniquely identified by a Policy-ID.
Once the policy updates are securely exchanged, the DPA updates the
local SPD to reflect the changes associated with the Policy-ID.
The following diagram summarizes the role of DPA in conjunction with
IKE in dynamic policy update process.
+------+ +--------+ +---------+
| | Dynamic | | Exchange Policy | |
+-| ALGn |<------->| Dynamic|<----------------->| IKE |
| +------+ Policy | Policy | Updates (based on | Process |
+-| ...| Updates | Agent | Policy-ID handle) | |
| +------+ +--------+ +---------+
| ALG1 | | ^ |
+------+ Reflect dynamic | | |
policy updates | Security | |Negotiated
exchanged with | Policies & | |parameters,
peering IKE node| SA proposals | |SA Keys
v | v
+---------+ +---------+
| |------------------>| |
| IPsec- | | IPsec |
| SPD | | Process |
| | | |
+---------+ +---------+
Figure 3.3.3. DPA coordinating between ALGs, IKE and IPsec-SPD.
4. New Policy Payload for use in IKE phase 2
IKE uses ID payload in phase I to authenticate the peers. The ID
payload is further extended in phase II to exchange the IPsec
policies. While this reduces the number of payload types to work
with, it became a stretch to extend the ID payload to describe
IPsec policies in IKE phase 2. Policy specification using ID
payload has been rather inflexible and prone to errors. So, a
new policy payload is introduced for a policy definition that
is more flexible and less error prone.
Srisuresh & Vilhuber [Page 7]
Internet-Draft Policy extensions to IKE January 2001
4.1 IPsec Policy Payload format
The Policy Payload contains DOI-specific data used to exchange
Policy information. This information is used for exchanging the
Policies of communicating peers for which keys need to be
generated. Figure 4.1 shows the format of the Policy Payload.
The Policy 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 Policy OpCode (1 octet) - Specifies the type of Operation
to be performed. This can be one of POLICY-OP-CREATE (0x00),
POLICY-OP-ADD (0x01) or POLICY-OP-DEL (0x02).
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
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 ! Policy Opcode ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy IDentifier !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! !
~ Policy Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4.1. Policy Payload Format
o DOI Specific Policy-ID (4 octets) - Contains DOI specific
Identification data.
o Policy Data (variable length) - Contains Policy information.
Specific details for the IETF IP Security DOI Policy Data
may be specified as follows.
The payload type for the Policy Payload may be assigned a value of
fourteen (14), so as not to conflict with the definitions for
recognized ISAKMP payload types, as defined in [ISAKMP] sections
4.3 through 4.14.
Srisuresh & Vilhuber [Page 8]
Internet-Draft Policy extensions to IKE January 2001
4.2 IPsec Policy Payload Content format
The Policy Payload, used in IKE phase II, is used to ensure that a
certain security association is applied only to those packets that
confirm to the policy exchanged in conjunction with the SA
negotiation. The policy payload of the initiator SHOULD be used
by the responder to determine the correct host system security policy
requirement for the association. For example, a host might choose to
require authentication and integrity without confidentiality (AH)
from a certain set of IP addresses and full authentication with
confidentiality (ESP) from another range of IP addresses. The
policy Payload provides information that can be used by the
responder to make this decision.
The following diagram illustrates the content of the Policy Payload.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!P!RSRVD! IPvx !SA-Type!DA-Type!SP-type|DP-type! Protocol ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Src-address-Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Src-Port-Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Dest-address-Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Dest-Port-Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional Policy Extensions in Tag-Length-Value format ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4.2. IPsec DOI Policy Data content Format
The Policy Payload fields are defined as follows:
o P (1 bit) - Polarity of the Policy. The policy must be
interpreted as outbound policy from the policy senders
view. When set to 0, the position of source and destination
fields for Address and port are interpreted as described
in the figure. When set to 1, the position of the source
and destination fields must be reversed.
o RSRVD (4 bits) - Must be set to 0.
o IPvx (4 bits) - Value describing the IP address Length.
A value of 4 refers to IPv4 and an IP address length of
4 octets. A value of 6 refers to IPv6 and an IP address
Srisuresh & Vilhuber [Page 9]
Internet-Draft Policy extensions to IKE January 2001
length of 16 octets.
o SA-Type (4 bits) - Value describing the format of
information found in the Src-Address-Data field.
o DA-Type (4 bits) - Value describing the format of
information found in the Dest-Address-Data field.
o SP-Type (4 bits) - Value describing the format of
information found in the Src-Port-Data field.
o DP-Type (4 bits) - Value describing the format of
information found in the Dest-Port-Data field.
o Protocol ID (1 octet) - Value specifying an associated IP
protocol ID (e.g. UDP/TCP). A value of zero means that the
Protocol ID field should be ignored.
o Src-address-Data, Src-Port-Data, Dest-address-Data,
Dest-Port-Data (variable length) - Value, as indicated by
the fields IPvx, SA-Type, SP-type, DA-Type and DP-type.
4.2.1 SA-Type and DA-Type Values
The following table lists the assigned values for the Address type
fields found in the Policy data.
Address Type Value
------------ -----
RESERVED 0
POLICY_ADDR_SINGLE 1
POLICY_ADDR_RANGE 2
POLICY_ADDR_SUBNET 3
POLICY_ADDR_LIST_SINGLE 9
POLICY_ADDR_LIST_RANGE 10
POLICY_ADDR_LIST_SUBNET 11
The POLICY_ADDR_SINGLE type specifies a single IP address in the
Address-Data field. This will be four (4) octets, when IPvx is
set to 4. This will be sixteen (16) octets, when IPvx is set to 6.
The POLICY_ADDR_RANGE type specifies a range of IP addresses,
represented by two four or sixteen octet values, based on whether
IPvx is set to 4 or 6. The first value is the beginning IP address
(inclusive) and the second value is the ending IP address
(inclusive). Note that all addresses falling between the two
specified addresses are considered to be within the list.
Srisuresh & Vilhuber [Page 10]
Internet-Draft Policy extensions to IKE January 2001
The POLICY_ADDR_SUBNET type specifies two IP addresses,
each represented by two four or sixteen octet values, based on
whether IPvx is set to 4 or 6. The first value is an IP address.
The second is an IP network mask. Note that ones (1s) in the
network mask indicate that the corresponding bit in the address
is fixed, while zeros (0s) indicate a "wildcard" bit.
The POLICY_ADDR_LIST_SINGLE type specifies a variable number of
individual IP addresses in the Address-Data field. The
Address-Data field will have the addresses listed as follows.
<Field size> <----List of individual IP Addresses------>
<- 2 bytes -> <- Multiples of 4(IPv4) or 16(IPv6) bytes->
The <Field size> is the sum total of octets required to specify
the address list and the 2 bytes required by the <Field Size>
field. The
The POLICY_ADDR_LIST_RANGE type specifies a variable number of
individual IP address ranges in the Address-Data field. The
Address-Data field will have the address ranges listed as
follows.
<Field size> <------List of IP Address ranges---------->
<- 2 bytes -> <- Multiples of 8(IPv4) or 32(IPv6) bytes->
The <Field size> is the sum total of octets required to specify
the address ranges and the 2 bytes required by the <Field Size>
field.
The POLICY_ADDR_LIST_SUBNET type specifies a variable number of
individual IP address subnets in the Address-Data field. The
Address-Data field will have the address subnets listed as
follows.
<Field size> <------List of IP Address subnets--------->
<- 2 bytes -> <- Multiples of 8(IPv4) or 32(IPv6) bytes->
The <Field size> is the sum total of octets required to specify
the address subnets and the 2 bytes required by the <Field Size>
field.
4.2.2 SP-Type and DP-Type Values
The following table lists the assigned values for the Port type
fields(SP-Type, DP-Type) found in the Policy data.
Srisuresh & Vilhuber [Page 11]
Internet-Draft Policy extensions to IKE January 2001
Type Value
------------ -----
POLICY_PORT_IGNORE 0
POLICY_PORT_SINGLE 1
POLICY_PORT_RANGE 2
POLICY_PORT_LIST_SINGLE 9
POLICY_PORT_LIST_RANGE 10
POLCY_PORT_IGNORE type indicates that the associated Port-Data
field should be ignored.
POLICY_PORT_SINGLE type would specify a 2 octet port-data field.
POLICY_PORT_RANGE type would specify a pair of 2-octet port
numbers in Port-Data field. The first value is the beginning port
number (inclusive) and the second value is the ending port
number (inclusive).
POLICY_PORT_LIST_SINGLE would specify a variable number of bytes
in the Port-Data field as follows. The Port-date filed will have
the variable count of port numbers listed as follows:
<Field size> <List of Protocol specific Ports>
<- 2 bytes -> <----- Multiples of 2 bytes ---->
The <Field size> is the sum total of octets required to specify
the individual ports and the 2 bytes required by the <Field Size>
field.
POLICY_PORT_LIST_RANGE would specify a variable number of bytes
in the Port-Data field as follows. The Port-date filed will have
the variable count of port ranges listed as follows:
<Field size> <List of Protocol specifc Port ranges>
<- 2 bytes -> <------ Multiples of 4 bytes -------->
The <Field size> is the sum total of octets required to specify
the individual ports and the 2 bytes required by the <Field Size>
field.
4.2.3. Optional policy extensions
Optionally, additional fields (over and above 5 tuples for address,
protocol and port numbers) may also be specified as part of the
Policy specification in Tag-Length-Value format. Existense of
additional fields in policy specification may be surmised when
the Policy payload length (refer section 4.2.1) exceeds the
five-tuple policy data.
Srisuresh & Vilhuber [Page 12]
Internet-Draft Policy extensions to IKE January 2001
For example, the Diffserv Field in IP header may be specified as
as an additional field as follows,
<Tag: 0x80 (DS-field-list)>
<Length: 6 bytes>
<Values: AF1, AF2, AF3, AF4>
The <Tag> will be specified in a single octet. <Length> field is the
sum total of bytes necessary to list the DS-fields allowed and the
two bytes necessary to specify the <Tag> and <Length> fields.
5. Modifications to IKE Phase 2 - Quick Mode
IKE Quick Mode is used to derive keying material for IPsec policies
commonly shared between the IKE peers. The information exchanged in
Quick Mode is protected by the ISAKMP SA (Phase 1).
The message ID in the ISAKMP header identifies the Quick Mode in
progress. Quick Mode is essentially a SA negotiation, IPsec policy
communication and an exchange of nonces that provides replay
protection.
The Policies for which SAs negotiated in Quick Mode are implicitly
assumed to be between the IP addresses of the ISAKMP peers, unless
policy operations are explicitly specified in Quick Mode.
With the new approach, Policy based payloads are exchanged in place
of IDci and IDcr. If the client policies are not acceptable to the
Quick Mode responder, a Notify payload with Notify Message Type
INVALID-POLICY-INFORMATION SHOULD be sent. A value of thirty one
(31) may be assigned to INVALID-POLICY-INFORMATION, so as not to
conflict with the error codes listed in 3.14.1 of [ISAKMP].
Srisuresh & Vilhuber [Page 13]
Internet-Draft Policy extensions to IKE January 2001
5.1. New Policy Exchange in Quick mode
Policy based Quick Mode may be described as follows for brand new
key generation.
Initiator Responder
----------- -----------
HDR*, HASH(1), SA, Ni
[, KE ] (, POLi)* -->
<-- HDR*, HASH(2), SA, Nr
[, KE ] (, POLr)*
HDR*, HASH(3) -->
Where:
HASH(1) is the prf over the message id (M-ID) from the ISAKMP header
concatenated with the entire message that follows the hash, including
all payload headers, but excluding any padding added for encryption.
HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni,
minus the payload header-- is added after M-ID but before the
complete message. The addition of the nonce to HASH(2) is for a
liveliness proof. HASH(3)-- for liveliness-- is the prf over the
value zero represented as a single octet, followed by a concatenation
of the message id and the two nonces-- the initiator's followed by
the responder's-- minus the payload header. In other words, the
hashes for the above exchange are:
HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] | POLi* )
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | POLr* )
HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)
HASH, SA, and Nonce payloads must be sent in that order.
A single SA negotiation results in two security associations-- one
inbound and one outbound. Different SPIs for each SA (one chosen by
the initiator, the other by the responder) guarantee a different key
for each direction. The SPI chosen by the destination of the SA is
used to derive KEYMAT for that SA.
Multiple SAs and keys can be negotiated with one exchange such that
you have two keys each way for both SAs. New policy payload must be
accompanied by a SA negotiation payload.
5.2. Dynamic Policy update in Quick Mode
For exchanges that do not involve Key generation, but simply policy
updates, Updates to Policies previously negotiated may be performed
as follows. These policy updates do not mandate SA negotiation
Srisuresh & Vilhuber [Page 14]
Internet-Draft Policy extensions to IKE January 2001
payload. However, a single SA negotiation payload is optional.
Initiator Responder
----------- -----------
HDR*, HASH(1), [SA, ] Ni
, POLi (, POLi)* -->
<-- HDR*, HASH(2), [SA, ] Nr
, POLr (, POLr)*
HDR*, HASH(3) -->
Hashes for the above exchange are:
HASH(1) = prf(SKEYID_a, M-ID | [ SA |] Ni | POLi* )
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | [SA |] Nr | POLr* )
HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)
When no SA is specified, the policy updates made in POLi/POLr simply
update the corresponding policy rule in SPD. Hence, the SA
associated with the POLICY-ID will be reused for the updated policy.
However, when SA payload is present, the new SA negotiation results
in two new security associations-- one inbound and one outbound for
the Policy Updates. These new SA keys will be used to secure the
policy updates exchanged.
6. Security Considerations
The document suggests a new Policy-ID payload and modifications
to IKE protocol. This however, does not jeopardize the security
provided by the base IKE protocol. Additions and deletions
pertaining to a Policy ID are communicated in a secure way
so as not to jeopardize the ability of the application to run.
7. IANA Considerations
This document proposes a new ISAKMP payload type and a new Notify
error code.
7.1. ISAKMP Policy Payload type
The ISAKMP payload types are discussed in sections 3.4 through 3.15
of [ISAKMP]. And, Section 4.6 of [IPSEC-DOI] lists the ISAKMP
payloads whose data representations are dependent on the applicable
DOI. The new ISAKMP payload type discussed in section 4.1 of this
document will be an addition to the payload types discussed in
[ISAKMP] as well as [IPSEC_DOI]. However, the ISAKMP payload types
are not listed as items to be managed by IANA in [ISAKMP]. Assuming
this to have been an omission, we propose that the new payload type
Srisuresh & Vilhuber [Page 15]
Internet-Draft Policy extensions to IKE January 2001
specified in this document be considered by IANA as an addition to
the ISAKMP payload types listed in sections 3.4 through 3.15 in
[ISAKMP].
Within the context of this new policy payload type, three sub-fields
are defined that may be assigned newer values in the future.
The following sub-section explains the criteria to be used by the
IANA to assign additional numbers as values to these sub-fields,
described in section 4.1, 4.2.1 and 4.2.2
7.1.1. Policy Opcode field
Values 0-2 of the Policy-Opcode field are defined in Section 4.1.
the remaining values [3-255] are available for assignment by the
IANA with IETF Consensus [IANA].
7.1.2. SA-Type and DA-Type fields
SA-Type and DA-type fields are 4-bits long. Values 0-3, 9-11 for
these fields are defined in Section 4.2.1. The remaining values
4-8, 12-15 are available for assignment by the IANA with
IETF Consensus [IANA]. It is recommended that values 4 through 7
be allowed to specify fixed length types and the values 8 and
12 through 15 be alowed to specify variable length types.
7.1.3. SP-Type and DP-Type fields
SP-Type and DP-Type fields are 4-bits long. Values 0-2, 9-10 for
these fields are defined in Section 4.2.2. The remaining values
3-8, 11-15 are available for assignment by the IANA with IETF
Consensus [IANA]. It is recommended that values 3 through 7
be allowed to specify fixed length types and the values 8 and
11 through 15 be alowed to specify variable length types.
7.2. ISAKMP Notify payload error message type
Section 3.14.1 of [ISAKMP] lists the Notification error codes in the
range of 1-30. Error codes 31-8191 are reserved for future use and
error codes 8192-16383 are set aside for private use. Of these,
error code 8192 is reserved by the IPSEC-DOI in section 4.6.3 of
[IPSEC-DOI]. We define a new INVALID-POLICY-INFORMATION error code
31 in section 5.0.
Once again, the error codes lised for use within the Notify
payload in [ISAKMP] are not listed as items to be managed by IANA
in [ISAKMP]. Assuming this to have been an omission, we propose
that the error code specified in this document be considered by
IANA as an addition to the Notify payload error codes listed in
Srisuresh & Vilhuber [Page 16]
Internet-Draft Policy extensions to IKE January 2001
3.14.1 of [ISAKMP].
REFERENCES
[STD-KEYWORDS] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", RFC2119, March 1997.
[IPSEC] S. Kent, R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401.
[AH] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402
[ESP] S. Kent, R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406.
[IPSEC-DOI] D. Piper, "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407.
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", from IEEE Proceedings of the 1996
Symposium on Network and Distributed Systems Security.
[ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[OAKLEY] Orman, H., "The Oakley Key Determination Protocol",
RFC 2412.
[CRYPTO] Schneier, B., "Applied Cryptography, Protocols,
Algorithms, and Source Code in C", 2nd edition.
[IKE] Harkins, D., Carrel, D.,"The Internet Key Exchange (IKE)",
RFC 2409.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
Authors' Address:
Pyda Srisuresh
Jasmine Networks, Inc.
3061 Zanker Road, Suite B
San Jose, CA 95134
U.S.A.
Srisuresh & Vilhuber [Page 17]
Internet-Draft Policy extensions to IKE January 2001
Voice: (408) 895-5032
EMail: srisuresh@yahoo.com
Jan Vilhuber
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
U.S.A.
E-mail: vilhuber@cisco.com
Srisuresh & Vilhuber [Page 18]
