| 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
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.
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 (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 (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.
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:
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.
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.
This section will contain notations
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.
Five HIP parameters are defined for setting up SSLS associations in HIP communication and for restarting existing ones. Also, the 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
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.
The processing of SSE_INFO is similar to ESP_INFO, section 5.1.1 of RFC7402, without the KEYMAT generation.
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 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.
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 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
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.
The processing of GPCOMP_INFO is similar to ESP_TRANSFORM, section 5.1.2 of RFC7402.
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.
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.
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. 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.
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]
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 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 returns to the calling application:
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 SSE module:
SSE SPIs GPcomp agreed algorithm
HIP sends to the GPcomp module:
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.
This document defines five Parameter Types and four NOTIFY Message Types for the Host Identity Protocol [RFC7401].
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].
Security boundaries must be rigorously observed. Care is taken in terms of what information is known to which module. Still the application possesses both the clear and crypto text and can thus be an attack point against the session keys.
TBD
| [I-D.hares-i2nsf-ssls] | Hares, S. and R. Moskowitz, "Secure Session Layer Services", Internet-Draft draft-hares-i2nsf-ssls-00, 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., 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. |
| [I-D.ietf-hip-dex] | Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", Internet-Draft draft-ietf-hip-dex-05, February 2017. |
| [I-D.moskowitz-hierarchical-hip] | Moskowitz, R. and X. Xu, "Hierarchical HITs for HIPv2", Internet-Draft draft-moskowitz-hierarchical-hip-03, June 2017. |
| [I-D.moskowitz-sse] | Moskowitz, R., Faynberg, I., Lu, H., Hares, S. and P. Giacomin, "Session Security Envelope", Internet-Draft draft-moskowitz-sse-05, 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. |
| [RFC8046] | Henderson, T., Vogt, C. and J. Arkko, "Host Mobility with the Host Identity Protocol", RFC 8046, DOI 10.17487/RFC8046, February 2017. |