Network Working Group R. Atkinson, Editor
Internet Draft @Home Network
draft-ietf-rip-doi-00.txt 14 October 1997
RIPv2 Domain Of Interpretation (DOI) for ISAKMP
STATUS OF THIS MEMO
This document is an Internet Draft. 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.''
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 (Australia), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. This draft will expire six
months from date of issue.
1. Abstract
The Internet Security Association and Key Management Protocol
(ISAKMP) defines a framework for security association management and
cryptographic key establishment for the Internet. This framework
consists of defined exchanges and processing guidelines that occur
within a given Domain of Interpretation (DOI). This document details
the RIPv2 DOI, which is defined to cover the use of ISAKMP to
negotiate Security Associations for the RIPv2 routing protocol.
Atkinson Expires in 6 months [Page 1]
Internet Draft RIPv2 DOI for ISAKMP 14 October 1997
2. Introduction
Within ISAKMP, a Domain of Interpretation is used to group related
protocols using ISAKMP to negotiate security associations. Security
protocols sharing a DOI choose security protocol and cryptographic
transforms from a common namespace and share key exchange protocol
identifiers. They also share a common interpretation of DOI-specific
payload data content, including the Security Association and
Identification payloads.
Overall, ISAKMP places the following requirements on a DOI
definition:
o define the naming scheme for DOI-specific protocol identifiers
o define the interpretation for the Situation field
o define the set of applicable security policies
o define the syntax for DOI-specific SA Attributes (phase II)
o define the syntax for DOI-specific payload contents
o define additional mappings or Key Exchange types, if needed
The remainder of this document details the instantiation of these
requirements for using the RIPv2 cryptographic authentication
mechanism to provide data origin authentication for RIPv2 routing
packets sent between cooperating routers.
3. Terms and Definitions
In this document, the words that are used to define the
significance of each particular requirement are usually capitalised.
These words are defined in RFC-xxxx, which is hereby incorporated
into this document by reference. [RFC-xxxx]
Within ISAKMP, all DOI's must be registered with the IANA in the
``Assigned Numbers'' RFC [STD-2]. The IANA Assigned Number for the
RIPv2 DOI is <TO BE ASSIGNED BY IANA>. Within the RIPv2 DOI, all
well-known identifiers MUST be registered with the IANA under the
RIPv2 DOI. Unless otherwise noted, all tables within this document
refer to IANA Assigned Numbers for the RIPv2 DOI.
4. Assigned Numbers
The following sections list the Assigned Numbers for the RIPv2 DOI
Security Protocol Identifiers, Transform Identifiers, and Security
Association Attribute Types. Note that all multi-octet binary values
Atkinson Expires in 6 months [Page 2]
Internet Draft RIPv2 DOI for ISAKMP 14 October 1997
are stored in network byte order.
4.1 RIPv2 Situation Definition
Within ISAKMP, the Situation provides information that can be used
by the responder to make a policy determination about how to process
the incoming Security Association request. For the RIPv2 DOI, the
Situation field is a four (4) octet bitmask with the following
values.
Situation Value
--------- -----
SIT_AUTHENTICATION 0x01
All other values are reserved to IANA.
The SIT_AUTHENTICATION type specifies that the security
association will be identified by source identity information present
in an associated Identification Payload. See Section 4.6.2 for a
complete description of the various Identification types. All RIPv2
DOI implementations MUST support SIT_AUTHENTICATION by including an
Identification Payload in at least one of the phase I Oakley
exchanges ([IO], Section 5) and MUST abort any association setup that
does not include an Identification Payload.
4.2 RIPv2 Security Protocol Identifiers
The ISAKMP proposal syntax was specifically designed to allow for
the simultaneous negotiation of multiple security protocol suites
within a single negotiation. As a result, a Protocol ID must be
indicated. The RIPv2 DOI only contains a single operational Protocol
ID. The size of this field is one octet. The values 2-255 are
reserved to IANA.
Protocol ID Value
----------- -----
RESERVED 0
PROTO_ISAKMP 1
PROTO_RIPv2 2
4.3 PROTO_ISAKMP
The PROTO_ISAKMP type specifies message protection required during
Phase I of the ISAKMP protocol. The specific protection mechanism
used for the RIPv2 DOI is described in [IO]. All implementations
within the RIPv2 DOI MUST support PROTO_ISAKMP.
Atkinson Expires in 6 months [Page 3]
Internet Draft RIPv2 DOI for ISAKMP 14 October 1997
NB: ISAKMP reserves the value one (1) across all DOI definitions.
4.3.1 PROTO_RIPv2
The PROTO_RIPv2 type specifies IP packet data origin
authentication. The default transform includes data origin
authentication and replay prevention. For export control
considerations, confidentiality MUST NOT be provided by any
PROTO_RIPv2_AH transform.
4.4 RIPv2 ISAKMP Transform Values
As part of an ISAKMP Phase I negotiation, the initiator's choice
of Key Exchange offerings is made using some host system policy
description. The actual selection of Key Exchange mechanism is made
using the standard ISAKMP Proposal Payload. The following table
lists the defined ISAKMP Phase I Transform Identifiers for the
Proposal Payload for the RIPv2 DOI.
Transform Value
--------- -----
RESERVED 0
KEY_OAKLEY 1
The size of this field is one octet. The values 4-255 are
reserved to IANA.
The KEY_OAKLEY type specifies the hybrid ISAKMP/Oakley Diffie-
Hellman key exchange as defined in the [IO] document. All
implementations within the RIPv2 DOI MUST support KEY_OAKLEY. It is
anticipated that in future values will be assigned for
KEY_KERBEROS_V5 and KEY_GKMP to handle multicast sessions more
effectively.
4.5 RIPv2 Cryptographic Authentication Transform Values
The RIPv2 Cryptographic Authentication mechanism is designed to be
algorithm-independent, even though only one algorithm transform was
been defined as of the time this document was written. The following
table lists the defined RIPv2 Cryptographic Transform Identifiers for
the ISAKMP Proposal Payload for the RIPv2 DOI.
Transform ID Value
------------ -----
RESERVED 0
RIPv2_MD5_KPDK 1
RIPv2_SHA_KPDK 2
Atkinson Expires in 6 months [Page 4]
Internet Draft RIPv2 DOI for ISAKMP 14 October 1997
The size of this field is one octet. The values 4-255 are
reserved to IANA.
The RIPv2_MD5_KPDK type specifies the MD5-based transform
(Key/Pad/Data/Key) described in RFC-2082. The RIPv2_SHA_KPDK type
specifies the SHA1-based transform described in [Son of RFC-2082].
All implementations of this specification MUST support the
RIPv2_MD5_KPDK type. Implementations of this specification SHOULD
also support the RIPv2_SHA_KPDK type.
4.6 RIPv2 Security Association Attributes
The following SA attribute definitions are used in phase II of an
ISAKMP/Oakley negotiation. Attribute types can be either Basic (B)
or Variable-Length (V). Encoding of these attributes is defined in
the base ISAKMP specification.
Attribute Classes
class value type
-------------------------------------------------
Auth Key Life Type 1 B
Auth Key Life Duration 2 B/V
SA Life Type 5 B
SA Life Duration 6 B/V
Replay Protection 7 B
Group Description 8 B
CA Distinguished Name 9 B
HMAC Algorithm 11 B
Class Values
Auth Key Life Type
Auth Key Duration
Specifies the time-to-live for the authentication key(s)
used in the corresponding AH HMAC transform.
SA Life Type
SA Duration
Specifies the time-to-live for the RIPv2 Security
Association. When the SA expires, a new RIPv2 SA
must be established to replace the first SA.
RESERVED 0
seconds 1
kilobytes 2
Values 3-61439 are reserved to IANA. Values 61440-65535
Atkinson Expires in 6 months [Page 5]
Internet Draft RIPv2 DOI for ISAKMP 14 October 1997
are for experimental use. For a given "Life Type," the
value of the "Life Duration" attribute defines the actual
length of the component lifetime -- either a number of
seconds, or a number of Kbytes that can be protected.
If unspecified, the default value shall be assumed to be
28800 seconds (8 hours) for Auth, Enc, and SA lifetime.
Replay Protection
RESERVED 0
required 1
disallowed 2
Values 3-61439 are reserved to IANA. Values 61440-65535
are for private use among mutually consenting parties.
There is no default value for Replay Protection, as it
must be specified to correctly identify the applicable
transform.
Group Description
RESERVED 0
default group 1
Values 2-61439 are reserved to IANA. Values 61440-65535
are for private use among mutually consenting parties.
If unspecified, the default value shall be assumed to be
the default Oakley group ([IO], Section 5.5.1).
CA Distinguished Name
RESERVED 0
DNS Security 1
Values 2-61439 are reserved to IANA. Values 61440-65535
are for private use among mutually consenting parties.
If unspecified, the default value shall be assumed to be
DNS Security (Section 4.8).
HMAC Algorithm
RESERVED 0
MD5 1
SHA-1 2
Values 3-61439 are reserved to IANA. Values 61440-65535
are for private use among mutually consenting parties.
Atkinson Expires in 6 months [Page 6]
Internet Draft RIPv2 DOI for ISAKMP 14 October 1997
There is no default value for HMAC Algorithm, as it
must be specified to correctly identify the applicable
transform.
4.7.1 Required Attribute Support
To ensure basic interoperability, all implementations MUST support
all of the following attributes:
Auth Key Life Type
Auth Key Duration
SA Life Type
SA Duration
Replay Protection
HMAC Algorithm (MD5 required, SHA-1 optional)
4.7.2 Attribute List Parsing Requirement
To allow for flexible semantics, the RIPv2 DOI requires that a
conforming ISAKMP implementation MUST correctly parse an attribute
list that contains multiple instances of the same attribute class, so
long as the different attribute entries do not conflict with one
another.
If conflicting attributes are detected, an ATTRIBUTES-NOT-
SUPPORTED Notification Payload SHOULD be returned and the security
association setup MUST be aborted.
4.8 RIPv2 Payload Content
The following sections describe those ISAKMP payloads whose data
representations are dependent on the applicable DOI.
4.8.1 Security Association Payload
The following diagram illustrates the content of the Security
Association Payload for the RIPv2 DOI. See above for a description
of the Situation bitmap.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain of Interpretation (RIPv2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Situation (bitmap) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Atkinson Expires in 6 months [Page 7]
Internet Draft RIPv2 DOI for ISAKMP 14 October 1997
Figure 1: Security Association Payload Format
The Security Association Payload is defined as follows:
o Next Payload (2 octets) - Identifier for the payload type of
the next payload in the message. If the current payload is
the last in the message, this field will be zero (0).
o RESERVED (1 octet) - Unused, must be zero (0).
o Payload Length (2 octets) - Length, in octets, of the current
payload, including the generic header.
o Domain of Interpretation (4 octets) - Specifies the RIPv2 DOI,
which has been assigned the value <To be assigned by IANA>.
o Situation (4 octets) - Bitmask used to interpret the
remainder of the Security Association Payload. See Section
4.2 for a complete list of values.
4.8.2 Identification Payload Content
The Identification Payload is used to identify the initiator of
the Security Association. The identity of the initiator SHOULD be
used by the responder to determine the correct host system security
policy requirement for the association. Typically, RIPv2 sessions
use an identity that is either an IP Address or a Fully Qualified
Domain Name (FQDN).
The Identification Payload provides information that can be used by
the responder to make this decision.
The following diagram illustrates the content of the Identification
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | ID Type | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Identification Payload Format
The Identification Payload field is defined as follows:
o Next Payload (2 octets) - Identifier for the payload type of
Atkinson Expires in 6 months [Page 8]
Internet Draft RIPv2 DOI for ISAKMP 14 October 1997
the next payload in the message. If the current payload is
the last in the message, this field will be zero (0).
o RESERVED (1 octet) - Unused, must be zero (0).
o Payload Length (2 octets) - Length, in octets, of the
identification data, including the generic header.
o Identification Type (1 octet) - Value describing the
identity information found in the Identification Data field.
o RESERVED (1 octet) - Unused, must be zero (0).
4.8.2.1 Identification Type Values
The following table lists the assigned values for the
Identification Type field found in the Identification Payload.
ID Type Value
------- -----
RESERVED 0
ID_IPV4_ADDR 1
ID_IPV6_ADDR 2
ID_FQDN 3
ID_USER_FQDN 4
The size of this field is one octet. The values 5-255 are reserved
to IANA.
The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
The ID_IPV4_ADDR type specifies a single sixteen (16) octet IPv6
address.
The ID_FQDN type specifies a fully-qualified domain name string. An
example of a ID_FQDN is, "foo.bar.com".
The ID_USER_FQDN type specifies a fully-qualified username string, An
example of a ID_USER_FQDN is, "john-doe@foo.bar.com".
4.9 RIPv2 Security Parameter Index (SPI) Encoding
ISAKMP defines the SPI field as eight octets in length, however
the RIPv2 Cryptographic Authentication only uses a one octet Key
Identifier. All implementations MUST use the following mapping for
the ISAKMP SPI field in the RIPv2 DOI.
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
Atkinson Expires in 6 months [Page 9]
Internet Draft RIPv2 DOI for ISAKMP 14 October 1997
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEY ID | RESERVED MUST BE ZERO |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED MUST BE ZERO |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ISAKMP SPI Encoding
The ISAKMP SPI field is defined as follows:
o KEY ID - Key Identifier (1 octet) - contains the
KEY ID value which identifies the RIPv2 Authentication Key.
o RESERVED (7 octets) - Reserved for future use,
must be sent as zero (0) and
ignored upon receipt.
4.8 RIPv2 Certificate Authorities
The ISAKMP Certificate Request Payload allows either side of
an ISAKMP negotiation to request its peer to provide a certificate
chain needed to authenticate itself. The Certificate Request Payload
includes a list of acceptable Certificate Types and Certificate
Authorities. Appropriate certificate chains are then returned in a
Certificate Payload response.
The RIPv2 DOI defines the following Certificate Authorities
for the processing of Certificate Request Payloads. See Section 4.5
for details on the specific data attribute type values for these CAs.
Certificate Authority
---------------------
DNS Security
4.8.1 DNS Security
This CA type represents the combination of KEY and SIG records, as
defined in [RFC-2065], that can be used for authentication. The
particular encoding required to formulate the Certificate Payload
(response) is TBD.
4.9 RIPv2 Key Exchange Requirements
The RIPv2 DOI introduces no additional Key Exchange types.
Atkinson Expires in 6 months [Page 10]
Internet Draft RIPv2 DOI for ISAKMP 14 October 1997
5. Security Considerations
This entire note pertains to a hybrid protocol, combining
Oakley ([OAKLEY]) with ISAKMP ([ISAKMP]), to negotiate and derive
keying material for security associations in a secure and
authenticated manner. Specific discussion of the various security
protocols and transforms identified in this document can be found in
the associated base documents.
This document describes the additional data needed to apply
the ISAKMP protocol for use in managing RIPv2 Authentication Keys and
related data. Implementers should consult the RIPv2 specification
for more information on RIPv2 Cryptographic Authentication.
ACKNOWLEDGEMENTS:
This document is directly derived from the "IP Security DOI for
ISAKMP" by Derrell Piper. That document is in turn derived, in part,
from previous works by Douglas Maughan, Mark Schertler, Mark
Schneider, Jeff Turner, Dan Harkins, and Dave Carrel.
REFERENCES:
[RFC-2065] D. Eastlake 3rd & C. Kaufman, "Domain Name System Security
Extensions (DNSSEC)", RFC-2065, January 1997.
[RFC-2082] F. Baker & R. Atkinson, "RIPv2 MD5 Authentication",
RFC-2082, January 1997.
[IO] D. Carrel & D. Harkins, "The Resolution of ISAKMP with Oakley,"
draft-ietf-ipsec-isakmp-oakley-03.txt.
[ISAKMP] D. Maughan, M. Schertler, M. Schneider, & J. Turner,
"Internet Security Association and Key Management Protocol (ISAKMP),"
draft-ietf-ipsec-isakmp-07.{ps,txt}.
[OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol,"
draft-ietf-ipsec-oakley-01.txt.
[PFKEY] D.L. McDonald, C.W. Metz, B.G. Phan, "PF_KEY Key Management API,
Version 2", draft-mcdonald-pf-key-v2-01.txt, work in progress.
Editor's Address:
Randall Atkinson <rja@home.net>
@Home Network
Atkinson Expires in 6 months [Page 11]
Internet Draft RIPv2 DOI for ISAKMP 14 October 1997
425 Broadway Street
Redwood City, CA,
USA 94063
+1 (650) 569-5449
Atkinson Expires in 6 months [Page 12]