SSE BOF R. Moskowitz Internet-Draft L. Xia Intended status: Standards Track Huawei Expires: December 29, 2017 I. Faynberg Stargazers Consulting, LLC S. Hares Hickory Hill Consulting P. Giacomin FreeLance June 27, 2017 Secure Session Layer Services KMP via HIP draft-moskowitz-ssls-hip-02 Abstract This memo specifies the details for establishing and maintaining a Secure Session Layer Services (SSLS) association between two applications using the Host Identity Protocol (HIP [RFC7401]). This is primarily achieved by adding SSLS specific HIP parameters for the HIP base exchange. The SSLS association state and security boundaries are also defined. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 29, 2017. Copyright Notice Copyright (c) 2017 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 Moskowitz, et al. Expires December 29, 2017 [Page 1] Internet-Draft SSLS kmp via HIP June 2017 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 3. Discovering an SSLS application peer . . . . . . . . . . . . 3 4. HIP parameters to negotiate and manage SSLS . . . . . . . . . 3 4.1. SSE_INFO . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. SSE_TRANSFORM . . . . . . . . . . . . . . . . . . . . . . 5 4.3. SSE_FORMAT . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. GPCOMP_INFO . . . . . . . . . . . . . . . . . . . . . . . 7 4.5. SSLS_INFO . . . . . . . . . . . . . . . . . . . . . . . . 7 4.6. NOTIFICATION Parameter . . . . . . . . . . . . . . . . . 8 5. Security Boundaries and APIs . . . . . . . . . . . . . . . . 8 5.1. Application to HIP API . . . . . . . . . . . . . . . . . 9 6. HIP mobility and SSLS . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Secure Session Layer Services (SSLS) [I-D.hares-i2nsf-ssls] provides a well defined session layer that can be implemented in any application to provide any or all of the following: o data compression o chunking of data o secure envelope o fragmentation and reassembly Moskowitz, et al. Expires December 29, 2017 [Page 2] Internet-Draft SSLS kmp via HIP June 2017 Applications implementing SSLS may need to negotiate the use of this service and its components. They must be able to negotiate the security association to support the use of the Session Security Envelope (SSE [I-D.moskowitz-sse]). HIP is an ideal protocol to support this association management. The SSE management requirement closely parallels HIP support of ESP [RFC7402] to the extent that Section 4 need only define the new parameter and point to [RFC7402] for the processing details. 2. Terms and Definitions 2.1. Requirements Terminology 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]. 2.2. Notations This section will contain notations 2.3. Definitions GPcomp: General Purpose Compression. SSE: Session Specific Envelope. 3. Discovering an SSLS application peer A HIP enabled SSLS application needs to discover its peer application. This could be manually configured, discovered via DNS, or some other services discovery mechanism. In the DNS example, the application recognizes the returned address as a HIT and the HI RR record. It next needs to discover the IP address for this HIT. If the HIT is Hierarchical [I-D.moskowitz-hierarchical-hip], it can use the HHIT DNS reverse lookup mechanism. In either case, the IP address may be that of the peer application's RVS [RFC8004]. Any other service discovery mechanism still has to provide the HIT, HI, and IP address as a minimal set of information. 4. HIP parameters to negotiate and manage SSLS Five HIP parameters are defined for setting up SSLS associations in HIP communication and for restarting existing ones. Also, the Moskowitz, et al. Expires December 29, 2017 [Page 3] Internet-Draft SSLS kmp via HIP June 2017 NOTIFICATION parameter, described in [RFC7401], has four new error parameters. Parameter Type Length Data SSE_INFO [TBD-IANA] 12 Remote's old SPI, new SPI SSE_TRANSFORM [TBD-IANA] variable SSE Encryption and Authentication Transform(s) SSE_FORMAT [TBD-IANA] variable SSE Format GPCOMP_INFO [TBD-IANA] 12 Compression Algorithm SSLS_INFO [TBD-IANA] 8 SSLS chunking and fragmenting 4.1. SSE_INFO 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | KEYMAT Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OLD SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEW SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [TBD-IANA] Length 12 KEYMAT Index index, in bytes, where to continue to draw SSE keys from KEYMAT. If the packet includes a new Diffie-Hellman key and the SSE_INFO is sent in an UPDATE packet, the field MUST be zero. If the SSE_INFO is included in base exchange messages, the KEYMAT Index must have the index value of the point from where the SSE SA keys are drawn. Note that the length of this field limits the amount of keying material that can be drawn from KEYMAT. If that amount is exceeded, the packet MUST contain a new Diffie-Hellman key. OLD SPI old SPI for data sent to address(es) associated with this SA. If this is an initial SA setup, the OLD SPI value is zero. NEW SPI new SPI for data sent to address(es) associated with this SA. Moskowitz, et al. Expires December 29, 2017 [Page 4] Internet-Draft SSLS kmp via HIP June 2017 The processing of SSE_INFO is similar to ESP_INFO, section 5.1.1 of RFC7402 [RFC7402], without the KEYMAT generation. 4.2. SSE_TRANSFORM The SSE_TRANSFORM parameter is used during SSE SA establishment. The first party sends a selection of transform families in the SSE_TRANSFORM parameter, and the peer must select one of the proposed values and include it in the response SSE_TRANSFORM parameter. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Suite ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suite ID #2 | Suite ID #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suite ID #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [TBD-IANA] Length length in octets, excluding Type, Length, and padding. Reserved zero when sent, ignored when received. Suite ID defines the SSE Suite to be used. The following Suite IDs can be used: Suite ID Value RESERVED 0 [this draft] RESERVED 1 - 9 [this draft] AES-CCM-8 10 [RFC4309] AES-CCM-16 11 [RFC4309] AES-GCM with an 8-octet ICV 12 [RFC4106] AES-GCM with a 16-octet ICV 13 [RFC4106] AES-CMAC-96 14 [RFC4493], [RFC4494] AES-GMAC 15 [RFC4543] SSE only supports the newer CCM and GCM modes of operation. The Suite ID assignments are as above to align with [RFC7402]. The sender of an SSE transform parameter MUST make sure that there are no more than six (6) Suite IDs in one SSE transform parameter. Conversely, a recipient MUST be prepared to handle received transform parameters that contain more than six Suite IDs. The limited number Moskowitz, et al. Expires December 29, 2017 [Page 5] Internet-Draft SSLS kmp via HIP June 2017 of Suite IDs sets the maximum size of the SSE_TRANSFORM parameter. As the default configuration, the SSE_TRANSFORM parameter MUST contain at least one of the mandatory Suite IDs. There MAY be a configuration option that allows the administrator to override this default. Mandatory implementations: AES-CCM-16. AES-CMAC-96 SHOULD also be supported. 4.3. SSE_FORMAT The SSE_FORMAT parameter is used during SSE SA establishment. The first party sends a selection of formats in the SSE_FORMAT parameter, and the peer must select one of the proposed values and include it in the response SSE_FORMAT parameter. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Format ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Format ID #2 | Format ID #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Format ID #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [TBD-IANA] Length length in octets, excluding Type, Length, and padding. Reserved zero when sent, ignored when received. Format ID defines the SSE Format to be used. The following Format IDs can be used: Format ID Value RESERVED 0 [this draft] Compact 1 [I-D.moskowitz-sse] Large 2 [I-D.moskowitz-sse] Extreme 3 [I-D.moskowitz-sse] The sender of an SSE format parameter MUST make sure that there are no more than six (6) Format IDs in one SSE format parameter. Conversely, a recipient MUST be prepared to handle received format parameters that contain more than six Format IDs. The limited number Moskowitz, et al. Expires December 29, 2017 [Page 6] Internet-Draft SSLS kmp via HIP June 2017 of Format IDs sets the maximum size of the SSE_FORMAT parameter. As the default configuration, the SSE_FORMAT parameter MUST contain at least one of the mandatory Format IDs. There MAY be a configuration option that allows the administrator to override this default. Mandatory implementations: Compact 4.4. GPCOMP_INFO 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CPI | Comp ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Comp ID #2 | Comp ID #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Comp ID #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [TBD-IANA] Length length in octets, excluding Type, Length, and padding. Suite ID defines the SSE Suite to be used. The following Comp IDs can be used: Comp ID Value RESERVED 0 [this draft] GPCOMP_OUI 1 (UNSPECIFIED) GPCOMP_DEFLATE 2 [RFC 2394] GPCOMP_LZS 3 [RFC 2395] GPCOMP_LZJH 4 [RFC 3051] The Comp ID has the same interpretation as IPcomp, section 2.22 of RFC7402 [RFC7296]. The processing of GPCOMP_INFO is similar to ESP_TRANSFORM, section 5.1.2 of RFC7402 [RFC7402]. 4.5. SSLS_INFO Moskowitz, et al. Expires December 29, 2017 [Page 7] Internet-Draft SSLS kmp via HIP June 2017 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk size | Fragment size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [TBD-IANA] Length 8 Chunk size Maximum data chunk supported. 0 if no chunking. Fragment size Maximum data fragment supported. 0 if no fragmenting. 4.6. NOTIFICATION Parameter The HIP base specification defines a set of NOTIFICATION error types. The following error types are required for describing errors in ESP Transform crypto suites during negotiation. NOTIFICATION PARAMETER - ERROR TYPES Value ------------------------------------ ----- NO_SSE_PROPOSAL_CHOSEN 20 None of the proposed SSE Transform crypto suites was acceptable. INVALID_SSE_TRANSFORM_CHOSEN 21 The SSE Transform crypto suite does not correspond to one offered by the Responder. NO_SSE_FORMAT_CHOSEN 22 None of the proposed SSE Format suites was acceptable. INVALID_SSE_FORMAT_CHOSEN 23 The SSE Format suite does not correspond to one offered by the Responder. 5. Security Boundaries and APIs When an application has direct control over the security of the communication, even when this is done via external modules, extreme care is needed in managing the environment. This is why HIP communicates some values directly to the SSE and GPcomp modules. Moskowitz, et al. Expires December 29, 2017 [Page 8] Internet-Draft SSLS kmp via HIP June 2017 This way the application cannot override their action. This does require the application to be able to accept calls from HIP itself whenever an event changes the SPIs for an association. 5.1. Application to HIP API It is assumed the application has learned the peer HIT and IP address before invoking HIP. Thus the calling parameters are: Source HIT, HI, and IP address Destination HIT, HI, and IP address SSE acceptable Transform and Format lists GPcomp acceptable Algorithms list [Null if no compression] Max chunk size [0 = no chunking] Max fragment size [0 = no fragmenting] HIP returns to the calling application: Source HIT, HI, and IP address Actual destination HIT, HI, and IP address SSE SPIs SSE agreed format GPcomp status [Yes/No] Agreed max chunk size [0 = no chunking] Agreed max fragment size [0 = no fragment] HIP sends to the SSE module: SSE SPIs SSE agreed transform SSE session keys [Note: SSE controls HIP rekeying based on transform and Sequence Number. In which case HIP will notify the application of a change to the SPIs] HIP sends to the GPcomp module: SSE SPIs GPcomp agreed algorithm Moskowitz, et al. Expires December 29, 2017 [Page 9] Internet-Draft SSLS kmp via HIP June 2017 6. HIP mobility and SSLS The HIP module SHOULD detect an IP address change for an interface and initiate a HIP Mobility operation [RFC8046]. It will then inform the SSLS application of the address change and any SPI changes to the application and other components. An example of this is a CPE gateway managed with RESTCONF on a PPPoE link that has restarted and had a new IP address assigned. The RESTCONF server would be able to apply any configuration changes to the gateway without needing to wait for the gateway to call back first. 7. IANA Considerations This document defines five Parameter Types and four NOTIFY Message Types for the Host Identity Protocol [RFC7401]. SSE_INFO: This document defines the new SSE_INFO parameter (see Section 4.1). The parameter value will be assigned by IANA. Its value should come from the 66-127 range. SSE_TRANSFORM: This document defines the new SSE_TRANSFORM parameter (see Section 4.2). The parameter value will be assigned by IANA. Its value should come from the 4096-4480 range. SSE_FORMAT: This document defines the new SSE_FORMAT parameter (see Section 4.3). The parameter value will be assigned by IANA. Its value should come from the 4096-4480 range. GPCOMP_INFO: This document defines the new GPCOMP_INFO parameter (see Section 4.4). The parameter value will be assigned by IANA. Its value should come from the 66-127 range. It should be greater than SSE_INFO. SSLS_INFO: This document defines the new SSLS_INFO parameter (see Section 4.5). The parameter value will be assigned by IANA. Its value should come from the 66-127 range. The new NOTIFY error types and their values are defined in Section 4.6, and they have been added to the Notify Message Type namespace created by [RFC7401]. 8. Security Considerations Security boundaries must be rigorously observed. Care is taken in terms of what information is known to which module. Still the Moskowitz, et al. Expires December 29, 2017 [Page 10] Internet-Draft SSLS kmp via HIP June 2017 application possesses both the clear and crypto text and can thus be an attack point against the session keys. 9. Acknowledgments TBD 10. References 10.1. Normative References [I-D.hares-i2nsf-ssls] Hares, S. and R. Moskowitz, "Secure Session Layer Services", draft-hares-i2nsf-ssls-00 (work in progress), March 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/RFC7402, April 2015, . 10.2. Informative References [I-D.ietf-hip-dex] Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", draft-ietf-hip-dex-05 (work in progress), February 2017. [I-D.moskowitz-hierarchical-hip] Moskowitz, R. and X. Xu, "Hierarchical HITs for HIPv2", draft-moskowitz-hierarchical-hip-03 (work in progress), June 2017. [I-D.moskowitz-sse] Moskowitz, R., Faynberg, I., Lu, H., Hares, S., and P. Giacomin, "Session Security Envelope", draft-moskowitz- sse-05 (work in progress), June 2017. Moskowitz, et al. Expires December 29, 2017 [Page 11] Internet-Draft SSLS kmp via HIP June 2017 [RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, DOI 10.17487/RFC2394, December 1998, . [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998, . [RFC3051] Heath, J. and J. Border, "IP Payload Compression Using ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051, January 2001, . [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, DOI 10.17487/RFC4106, June 2005, . [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, DOI 10.17487/RFC4309, December 2005, . [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2006, . [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 Algorithm and Its Use with IPsec", RFC 4494, DOI 10.17487/RFC4494, June 2006, . [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, DOI 10.17487/RFC4543, May 2006, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, October 2016, . Moskowitz, et al. Expires December 29, 2017 [Page 12] Internet-Draft SSLS kmp via HIP June 2017 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", RFC 8046, DOI 10.17487/RFC8046, February 2017, . Authors' Addresses Robert Moskowitz Huawei Oak Park, MI 48237 Email: rgm@labs.htt-consult.com Liang Xia Huawei No. 101, Software Avenue, Yuhuatai District Nanjing China Email: Frank.xialiang@huawei.com Igor Faynberg Stargazers Consulting, LLC East Brunswick, NJ 08816 USA Email: igorfaynberg@gmail.com Susan Hares Hickory Hill Consulting 7453 Hickory Hill Saline, MI 48176 USA Email: shares@ndzh.com Pierpaolo Giacomin FreeLance Email: yrz@anche.no Moskowitz, et al. Expires December 29, 2017 [Page 13]