Network Working Group M. Wong Internet Draft Huawei Technologies Intended status: Standards track September 11, 2009 Expires: March 2010 Integrity Data Exchanges in IKEv2 draft-wong-ipsecme-ikev2-integrity-data-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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". 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. This Internet-Draft will expire on March 11, 2010 Wong Expires March 11, 2010 [Page 1] Internet-Draft Integrity Data Exchange September 2009 Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract IKEv2 supports mutual authentication of the peers but does not support platform integrity validation of the peers nor does it support the exchange of data related to the platform integrity validation. This extension allows platform integrity validation data to be exchanged from one peer (initiator) to another (respondent), allowing the other peer to either use the data for statistical analysis, pass it along to a validation entity for validation or pass it along to a Fraud Information Gathering System for fraud detection or analysis. Table of Contents 1. Introduction................................................3 1.1. Motivation.............................................3 1.2. Usage Scenarios.........................................3 2. Conventions.................................................4 3. Solution....................................................4 3.1. Solution Overview.......................................4 3.2. Example of INTEGRITY_DATA notification payload exchange..5 3.3. Error Handling..........................................5 4. Payload Format..............................................5 4.1. INTEGRITY_DATA_SUPPORTED Notify Payload.................5 4.2. INTEGRITY_DATA Notify Payload...........................6 4.3. INTEGRITY_DATA_ACK Notify Payload.......................8 4.4. INTEGRITY_DATA_REJECT Notify Payload....................8 4.5. UNSUPPORTED_INTEGRITY_PAYLOAD Notify Payload.............8 5. IANA Considerations..........................................8 6. Security Considerations......................................8 7. References..................................................9 8. Acknowledgments.............................................9 9. Authors' Addresses...........................................9 Wong Expires March 11, 2010 [Page 2] Internet-Draft Integrity Data Exchange September 2009 1. Introduction 1.1. Motivation IKEv2 is used for performing mutual authentication, as well as establishing and maintaining IPsec Security Associations (SAs). There are an increasing number of peer nodes that are built based on trusted platform and/or modules, and thus requiring a successful platform integrity validation to be completed as a pre-condition for mutual authentication [3GPP]. One of the manners in which platform integrity is validated is via platform validation entity which is located beyond the endpoint. Another manner in which the platform integrity is validated is through self validation by the peer. Both of the validation methods require certain integrity related data to be sent to the other peer, whether this data is in the form the results of the self validation or in the form of state of the platform and/or modules. The scope of platform integrity validation is beyond the scope of this document. In the base IKEv2 protocol [IKEv2], it is not possible to carry and send this kind of data in any of the payloads defined. The main scenario for INTEGRITY_DATA Notify Payload is to enable integrity data to be transported between an initiator (client) and a respondent (server). The respondent may choose to retain the information for statistical analysis, send the information to an external Fraud Information Gathering System (FIGS), or send the information to an external validation entity for validation, all of which are out of the scope of this document. 1.2. Usage Scenarios Wong Expires March 11, 2010 [Page 3] Internet-Draft Integrity Data Exchange September 2009 Client *Network Access Provider* +---------+ +---------+ +------+ | | | NAP's | | | |Protected| IPsec SAs | Tunnel | IP Protocol | VAL | |Endpoint |<------------------>|Endpoint |<------------>|ENTITY| | | | | | | +---------+ +---------+ +------+ ^ \ IPsec \ or \ Leased Line \ \ v +------+ | 3rd | |Party | | FIGS | +------+ Figure 1: Architecture with Validation Entity or external Fraud Information Gathering System (FIGS). 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Solution 3.1. Solution Overview The responder of the IKEv2 announces support for this IKEv2 extension by including an INTEGRITY_DATA_SUPPORTED notification in the IKE_SA_INIT response. By including the notification payload, the responder is implicitly requesting that INTEGRITY_DATA be sent from the initiator. If the initiator supports this extension, it Wong Expires March 11, 2010 [Page 4] Internet-Draft Integrity Data Exchange September 2009 will include the INTEGRITY_DATA notification payload with the number of integrity values included in the NUMBER_OF_VALUES field of the notification data and each integrity data value in the Integrity Data field. The recipient may choose to store this information, or send it to external validation entity or external fraud information gathering system for further action, which is outside the scope of this document. It is assumed that both peers know what INTEGRITY_DATA are supported. 3.2. Example of INTEGRITY_DATA notification payload exchange Initiator Responder ----------- ----------- 1. HDR, SA, KE, Ni --> <-- 2. HDR, SA, KE, Nr, [CERTREQ], N(INTEGRITY_DATA_SUPPORTED) 3. HDR, SK { SA, TSi, TSr, IDi=NAI, IDr, CP(CFG_REQUEST), N(INTEGRITY_DATA),AUTH, [CERTREQ], CERT} --> <-- 4. HDR, SK { AUTH,CF[CFG_REPLY],SA, TSI, TSr, N(INTEGRITY_DATA_ACK) } Figure 2: INTEGRITY_DATA being sent in the Notify payload. 3.3. Error Handling If the initiator does not support the INTEGRITY_DATA_SUPPORTED notification in the IKE_SA_INIT response, the initiator can respond with UNSUPPORTED_INTEGRITY_PAYLOAD. The responder may choose to continue with the IKEv2 or terminate the IKEv2 process. 4. Payload Format 4.1. INTEGRITY_DATA_SUPPORTED Notify Payload The INTEGRITY_DATA_SUPPORTED notification payload is included in the IKE_AUTH exchange to indicate that the implementation supports this specification. The Notify Message Type is TBD-BY- Wong Expires March 11, 2010 [Page 5] Internet-Draft Integrity Data Exchange September 2009 IANA1(16406..40959). The Protocol_ID and SPI Size fields MUST be set to zero, and there is no data associated with this Notify type 4.2. INTEGRITY_DATA Notify Payload The INTEGRITY_DATA notification payload is included in an IKE_AUTH message containing an AUTH payload to let the peer know that integrity data is being sent in the notification payload. The Notify Message Type is TBD-BY-IANA2(16406..40959). The notification data is 4+N*24 octets long and is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! NUMBER_OF_INTEGRITY_DATA ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ! ! ! ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This Notify payload contains one or more Integrity_Data structures and the Integrity_Data structure is 24 octets long and is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Data_Object ! Attribute_ID ! RESERVED ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ! Data_Value ! ! ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Data_Object (2 octets) - Specifies the object of the data type. The defined values are: Wong Expires March 11, 2010 [Page 6] Internet-Draft Integrity Data Exchange September 2009 The defined values are: Data_Object Object_Value Object Type ---------------------------- ------------- ----------------------- Validation Result 0 Local Validation Results Base Band System 1 Integrity Measurement Radio Frequency System 2 Integrity Measurement Clock System 3 Integrity Measurement Board Support Packet (BSP) 4 Integrity Measurement Data Center 5 Integrity Measurement Operation & Maintenance (O&M) 6 Integrity Measurement Transport Protocol Component 7 Integrity Measurement Transmission Control Module 8 Integrity Measurement Switching/Forwarding Module 9 Integrity Measurement RESERVED 10 - 16383 PRIVATE 16384 - 32767 o Attribute Identifier(1 octet) - Specifies the attribute of the Object. The defined values are: Attribute Identifier Value ------------------------------ -------------- Configuration Information 0 Hardware module Information 1 Operational Status 2 RESERVED 3- 16383 o RESERVED (1 octet) - This attribute is reserved for future use. o Data_value (20 octets) - This attribute specifies the data value of the data objects. For local validation results objects, the data value is 4 octets followed by 16 octets set to zero. For integrity measurement data objects, this field contains the 160-bit hash value of the measurement. The Protocol_ID and SPI Size fields MUST be set to zero Wong Expires March 11, 2010 [Page 7] Internet-Draft Integrity Data Exchange September 2009 4.3. INTEGRITY_DATA_ACK Notify Payload The INTEGRITY_DATA_ACK notification payload is included in an IKE_AUTH message containing an AUTH payload to indicate that the integrity data is received. The Notify Message Type is TBD-BY- IANA3(16406..40959). The Protocol_ID and SPI Size fields MUST be set to zero, and there is no data associated with this Notify type. 4.4. INTEGRITY_DATA_REJECT Notify Payload The INTEGRITY_DATA_REJECT notification payload is included in an IKE_AUTH message containing an AUTH payload to indicate that the integrity data Notify payload is in error condition and is being rejected. The Notify Message Type is TBD-BY-IANA4(16406..40959). The Protocol_ID and SPI Size fields MUST be set to zero, and there is no data associated with this Notify type. 4.5. UNSUPPORTED_INTEGRITY_PAYLOAD Notify Payload The responder can include this notification to indicate that it does not support INTEGRITY_DATA_SUPPORTED payload. The Notify Message Type is TBD-BY-IANA5(43..8191). The Protocol_ID and SPI Size fields MUST be set to zero, and there is no data associated with this Notify type 5. IANA Considerations This document defines five new IKEv2 notifications, INTEGRITY_DATA_SUPPORTED, INTEGRITY_DATA, INTEGRITY_DATA_ACK, INTEGRITY_DATA_REJECT, and UNSUPPORTED_INTEGRITY_PAYLOAD whose values are to be allocated from the "IKEv2 Notify Message Types" namespace defined in [IKEv2]. This document does not define any new namespaces to be managed by IANA. 6. Security Considerations Security considerations for IKEv2 are discussed in [IKEv2]. However, the use of integrity data exchanges result in at least one new security consideration. Wong Expires March 11, 2010 [Page 8] Internet-Draft Integrity Data Exchange September 2009 Replay protection of the integrity data being exchanged needs to be considered as a compromised peer node may substitute integrity data from an old session. 7. References [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [3GPP] 3rd Generation Partnership Project, "3GPP Security Aspect of Home NodeB and Home eNodeB (Release 9)", TS 33.320, July 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8. Acknowledgments The author would like to thank Jing Chen and Ning Zhang for their valuable comments and contributions. 9. Authors' Addresses Marcus Wong Huawei Technologies Co., Ltd. 400 Somerset Corp Blvd, Suite 602 Bridgewater, NJ 08807 USA Phone: +1-908-541-3505 EMail: mwong@huawei.com Wong Expires March 11, 2010 [Page 9]