Internet Engineering Task Force R. Pereira
IP Security Working Group TimeStep Corporation
Internet Draft S. Anand
Expires in six months Microsoft Corporation
October 1, 1997
The ISAKMP Configuration Mode
<draft-ietf-ipsec-isakmp-mode-cfg-00.txt>
Status of this Memo
This document is a submission to the IETF Internet Protocol
Security (IPSECond) Working Group. Comments are solicited and
should be addressed to the working group mailing list
(ipsec@tis.com) or to the editor.
This document is an Internet-Draft. 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 draft documents are valid for a maximum of six
months and may be updated, replaced, or obsolete 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 learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
This document describes a new ISAKMP mode that allows configuration
items to be set by using both push/acknowledge and request/reply
paradigms.
R. Pereira, S. Anand [Page 1]
Internet Draft The ISAKMP Configuration Mode October, 97
Table of Contents
1. Introduction...................................................2
1.1. Specification of Requirements..............................2
2. Configuration Mode.............................................3
3. Configuration Transaction......................................3
3.1. Configuration Codes........................................4
4. Configuration Payload..........................................4
5. Configuration Attributes.......................................5
6. Security Considerations........................................6
7. References.....................................................6
8. Acknowledgments................................................7
9. Editors' Addresses.............................................7
1. Introduction
ISAKMP provides a framework to negotiate and derive Security
Associations. But since it is used within the IPSec framework, it
may also be used to configure secure hosts. This configuration may
take place between a gateway, an end-host client, or a
configuration manager. For example, this can be used to configure
multi-protocol IP tunnels securely.
It is assumed that the reader is familiar with the terms and
concepts described in the "Security Architecture for the Internet
Protocol" [Atkinson95] and "IP Security Document Roadmap"
[Thayer97] documents.
Readers are advised to be familiar with both [Harkins97] and
[ISAKMP] because of the terminology used within this document and
the fact that this document is an extension of both of those
documents.
1.1. Specification of Requirements
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
NOT", and "MAY" that appear in this document are to be interpreted
as described in [Bradner97].
R. Pereira, S. Anand [Page 2]
Internet Draft The ISAKMP Configuration Mode October, 97
2. Configuration Mode
Configuration Mode uses an XCHG type of 34 for the ISAKMP header.
This mode MUST NOT be used prior to establishment of an ISAKMP
Phase 1 Security Association.
Initiator Responder
----------- -----------
HDR*, HASH, CFG -->
<-- HDR*, HASH, CFG
where HASH is the prf output, using SKEYID_a as the key, and the
message-ID from the ISAKMP header concatenated with the entire CFG
payload, including attributes. In other words the hashes for the
above exchange are:
HASH = prf(SKEYID_a, M-ID | CFG)
Only one CFG payload MAY be present in one exchange of this mode.
3. Configuration Transaction
A "Configuration Transaction" is defined as two Configuration Mode
exchanges, the first being either a Set or a Request and the second
being either a Acknowledge or a Reply respectively. The Message ID
within the ISAKMP header identifies the configuration transaction
and MUST NOT be zero.
There are two paradigms to follow for this mode.
o "Set/Acknowledge" works on the push principle that allows a
configuration manager (a host that wishes to send information to
another) to start the configuration transaction. The
Acknowledge code MUST return zero length attributes that it
accepted. Those attributes that it did not accept will NOT be
sent back in the acknowledgement.
o "Request/Reply" allows a host to request information from an
informed host (a configuration manager). Attributes in the
Request exchange may have values filled in to request these
values once again. The Reply exchange MAY wish to choose those
values, or return new values. It MAY also add new attributes
and not include some requested attributes.
Transactions are completed once the Reply or Acknowledge code is
received. If one is not received, the implementation MAY wish to
retransmit the original exchange.
R. Pereira, S. Anand [Page 3]
Internet Draft The ISAKMP Configuration Mode October, 97
If a badly formatted exchange is received, the exchange SHOULD be
dropped and logged locally, as per local policy. Badly formatted
exchanges would also include those with unknown codes or unknown
attributes within the Configuration Mode.
3.1. Configuration Codes
Code Value
========================== ===========
ISKAMP_CFG_REQUEST 1
ISKAMP_CFG_REPLY 2
ISKAMP_CFG_SET 3
ISKAMP_CFG_ACK 4
Reserved for future use 5 - 127
Reserved for private use 128 - 255
4. Configuration Payload
The Configuration Payload is used to accomplish configuration
transactions between two secure hosts. Its "next payload" value is
13.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | RESERVED | Number of Attributes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Attributes ~
| |
+---------------------------------------------------------------+
The Configuration 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. For the
Configuration Mode, this field MUST be 0, since there is never a
next payload.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the entire
Configuration payload, including the Configuration payload
header and all of the attributes.
R. Pereira, S. Anand [Page 4]
Internet Draft The ISAKMP Configuration Mode October, 97
o Code (1 octet) - A code that represents a command to be
fulfilled or an action that has been completed. Please see
Section 4.1 for a description of each code.
o RESERVED (1 octet) - Unused, set to 0.
o Number of Attributes (2 octets) - States the number of
attributes to follow. Note that both the payload length and the
number of attributes field may be used to process the
attributes.
o Attributes (variable) - One or more data attributes as defined
in [ISAKMP], section 3.3. Please see a later section for more
information on the contents of these attributes.
5. Configuration Attributes
Attribute Value Type Length
========================== ======= ================ ============
INTERNAL_IP4_ADDRESS 1 Variable 4 octets
INTERNAL_IPX_ADDRESS 2 Variable 6 octets
INTERNAL_NB_ADDRESS 3 Variable 16 octets
INTERNAL_IP4_DNS 4 Variable 4 octets
INTERNAL_IP4_NBNS 5 Variable 4 octets
RENEW_SECONDS 6 Basic/Variable 2 or 4 octets
USE_IP4_DHCP 7 Variable 4 octets
Reserved for future use 8-63
Reserved for private use 64-127
o INTERNAL_IP4_ADDRESS - Specifies an IPv4 address within the
internal network. This address is sometimes called a red node
address. This address is sometimes an illegal address on the
Internet.
o INTERNAL_IPX_ADDRESS - Specifies an IPX address within the
internal network.
o INTERNAL_NB_ADDRESS - Specifies a NetBios address within the
internal network.
o INTERNAL_IP4_DNS - Specifies an IPv4 address of a DNS server
within the network.
o INTERNAL_IP4_NBNS - Specifies an IPv4 address of a NetBios Name
Server (WINS) within the network.
R. Pereira, S. Anand [Page 5]
Internet Draft The ISAKMP Configuration Mode October, 97
o RENEW_SECONDS - Specifies the number of seconds that the host
can use all of the information set within the configuration
transaction. The host MUST renew this information before this
expiry time and MUST not use any of the information obtained
through the configuration transaction after the expiry time.
o USE_IP4_DHCP - Instructs the host to request any subsequent
information through the DHCP protocol. This attribute holds the
IPv4 address of a DHCP server.
It is hoped that more attribute types will be defined in the
future. Some suggestions would be to distribute local policy, or
even authentication certificates. Also, note that no
recommendations are made to how an implementation actually figures
out what information to send. i.e. we do not recommend any
specific method of (a gateway) determining which DNS server should
be returned to a requesting host.
6. Security Considerations
This entire draft discusses a new ISAKMP mode to allow entities in
the network to acquire and share configuration information.
The draft mandates that this exchange always occur after the Phase
I Security Association has been set up and that the entire exchange
be protected by the Phase I SA. Thus the exchange is as secure as
any Phase II SA.
7. References
[Atkinson95] Atkinson, R., "Security Architecture for the Internet
Protocol", draft-ietf-ipsec-arch-sec-01
[Bradner97] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", RFC2119, March 1997
[ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner,
"Internet Security Association and Key Management Protocol",
draft-ietf-ipsec-isakmp-08
[Harkins97] D. Harkins, "The Resolution of ISAKMP and Oakley",
draft-ietf-ipsec-isakmp-oakley-04
[Thayer97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document
Roadmap", draft-ietf-ipsec-doc-roadmap-00
R. Pereira, S. Anand [Page 6]
Internet Draft The ISAKMP Configuration Mode October, 97
8. Acknowledgments
The editors would like to thank Peter Ford of Microsoft and Bob
Moskowitz of Chrysler.
9. Editors' Addresses
Roy Pereira
rpereira@timestep.com
TimeStep Corporation
+1 (613) 599-3610 x 4808
Sanjay Anand
sanjayan@microsoft.com
Microsoft Corporation
+1 (206) 936-6367
The IPSec working group can be contacted via the IPSec working
group's mailing list (ipsec@tis.com) or through its chairs:
Robert Moskowitz
rgm@chrysler.com
Chrysler Corporation
Theodore Y. Tso
tytso@MIT.EDU
Massachusetts Institute of Technology
R. Pereira, S. Anand [Page 7]
