Network Working Group R. Atkinson, Editor Internet Draft @Home Network draft-ietf-ospf-doi-00.txt 15 October 1997 OSPFv2 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. This draft is a work item of the Open Shortest Path First (OSPF) Routing Protocol Working Group in the IETF. Comments may be sent to the editor or to the OSPF WG as a whole at its mailing list. 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 Atkinson Expires in 6 months [Page 1]
Internet Draft OSPF DOI for ISAKMP 15 October 1997 the OSPFv2 DOI, which is defined to cover the use of ISAKMP to negotiate Security Associations for the OSPFv2 routing protocol. 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 OSPFv2 cryptographic authentication mechanism to provide data origin authentication for OSPFv2 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 OSPFv2 DOI is <TO BE ASSIGNED BY IANA>. Within the OSPFv2 DOI, all well-known identifiers MUST be registered with the IANA under the OSPFv2 DOI. Unless otherwise noted, all tables within this document refer to IANA Assigned Numbers for the OSPFv2 DOI. 4.0 Assigned Numbers The following sections list the Assigned Numbers for the OSPFv2 DOI Security Protocol Identifiers, Transform Identifiers, and Atkinson Expires in 6 months [Page 2]
Internet Draft OSPF DOI for ISAKMP 15 October 1997 Security Association Attribute Types. Note that all multi-octet binary values are stored in network byte order. 4.1 OSPFv2 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 OSPFv2 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.8.2 for a complete description of the various Identification types. All OSPFv2 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 security association setup that does not include an Identification Payload. 4.2 OSPFv2 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 size of this field is one octet. The values 3-255 are reserved to IANA. Protocol ID Value ----------- ----- RESERVED 0 PROTO_ISAKMP 1 PROTO_OSPFv2 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 OSPFv2 DOI is described in [IO]. All implementations within the OSPFv2 DOI MUST support PROTO_ISAKMP. Atkinson Expires in 6 months [Page 3]
Internet Draft OSPF DOI for ISAKMP 15 October 1997 NB: ISAKMP reserves the value one (1) across all DOI definitions. 4.3.1 PROTO_OSPFv2 The PROTO_OSPFv2 type specifies IP packet data origin authentication. The default OSPFv2 transform includes data origin authentication and replay prevention. 4.4 OSPFv2 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 OSPFv2 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 OSPFv2 DOI MUST support KEY_OAKLEY. It is anticipated that in future values will be assigned for Kerberos v5, GKMP, and/or other protocols to handle multicast SA creation more effectively. 4.5 OSPFv2 Cryptographic Authentication Transform Values The OSPFv2 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 OSPFv2 Cryptographic Transform Identifiers for the ISAKMP Proposal Payload for the OSPFv2 DOI. Transform ID Value ------------ ----- RESERVED 0 OSPFv2_MD5_KPDK 1 The size of this field is one octet. The values 4-255 are reserved to IANA. Atkinson Expires in 6 months [Page 4]
Internet Draft OSPF DOI for ISAKMP 15 October 1997 The AH_MD5_KPDK type specifies the AH transform (Key/Pad/Data/Key) described in RFC-2178. Implementations are required to support this mode. 4.6 OSPFv2 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 Enc Key Life Type 3 B Enc Key Life Duration 4 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 Encapsulation Mode 10 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 overall security association. When the SA expires, all keys negotiated under the association (AH or ESP) must be renegotiated regardless of the time-to-live remaining for the keys. RESERVED 0 seconds 1 kilobytes 2 Values 3-61439 are reserved to IANA. Values 61440-65535 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 Atkinson Expires in 6 months [Page 5]
Internet Draft OSPF DOI for ISAKMP 15 October 1997 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). 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 Atkinson Expires in 6 months [Page 6]
Internet Draft OSPF DOI for ISAKMP 15 October 1997 4.7.2 Attribute List Parsing Requirement To allow for flexible semantics, the OSPFv2 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 OSPFv2 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 OSPFv2 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 (OSPFv2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Situation (bitmap) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 OSPFv2 DOI, which has been assigned the value <To Be Assigned by IANA>. Atkinson Expires in 6 months [Page 7]
Internet Draft OSPF DOI for ISAKMP 15 October 1997 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, OSPF 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 the next payload in the message. If the current payload is the last in the message, this field will be zero (0). o Identification Type (1 octet) - Value describing the identity information found in the Identification Data field. o Payload Length (2 octets) - Length, in octets, of the identification data, including the generic header. 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 ------- ----- Atkinson Expires in 6 months [Page 8]
Internet Draft OSPF DOI for ISAKMP 15 October 1997 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 OSPFv2 Security Parameter Index (SPI) Encoding ISAKMP defines the SPI field as eight octets in length, however the OSPFv2 Cryptographic Authentication only uses a one octet Key Identifier. All implementations MUST use the following mapping for the ISAKMP SPI field in the OSPFv2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 OSPFv2 Authentication Key. o RESERVED (7 octets) - Reserved for future use, must be sent as zero (0) and ignored upon receipt. Atkinson Expires in 6 months [Page 9]
Internet Draft OSPF DOI for ISAKMP 15 October 1997 4.8 OSPFv2 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 OSPFv2 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 OSPFv2 Key Exchange Requirements The OSPFv2 DOI introduces no additional Key Exchange types. 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 OSPFv2 Authentication Keys and related data. Implementers should consult the OSPFv2 specification for more information on OSPFv2 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 Atkinson Expires in 6 months [Page 10]
Internet Draft OSPF DOI for ISAKMP 15 October 1997 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-2178] J. Moy, "OSPF Version 2", RFC-2178, July 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 425 Broadway Street Redwood City, CA, USA 94063 +1 (650) 569-5449 Atkinson Expires in 6 months [Page 11]
