Secure Session Layer Services KMP via HIP

The Secure Session Layer Services (SSLS) provides a well defined session layer that can be implemented in any application to provide any or all of the following: data compression chunking of data secure envelope fragmentation and reassembly 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 ). HIP is an ideal protocol to support this association management. The SSE management requirement closely parallels HIP support of ESP to the extent that need only define the new parameter and point to 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

General Purpose Compression. Session Specific Envelope.

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 , it can use the HHIT DNS reverse lookup mechanism. In either case, the IP address may be that of the peer application's RVS . 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 , 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 . 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

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.

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

The HIP module SHOULD detect an IP address change for an interface and initiate a HIP Mobility operation . 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 . This document defines the new SSE_INFO parameter (see ). The parameter value will be assigned by IANA. Its value should come from the 66-127 range. This document defines the new SSE_TRANSFORM parameter (see ). The parameter value will be assigned by IANA. Its value should come from the 4096-4480 range. This document defines the new SSE_FORMAT parameter (see ). The parameter value will be assigned by IANA. Its value should come from the 4096-4480 range. This document defines the new GPCOMP_INFO parameter (see ). The parameter value will be assigned by IANA. Its value should come from the 66-127 range. It should be greater than SSE_INFO. This document defines the new SSLS_INFO parameter (see ). 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 , and they have been added to the Notify Message Type namespace created by .

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