IPsec End-Point Channel Bindings and API

With connection latching IPsec now has a notion of "secure channel" that can be used in conjunction with channel binding . This document defines the channel bindings for IPsec channels where each peers use public keys to authenticate to the other. It also provides an abstract API for accessing the channel bindings of an IPsec channel. And it provides a BSD sockets C language binding of that abstract API. We assume reader familiarity with channel binding , IPsec and connection latching . These channel binding types also work with Better Than Nothing Security (BTNS) , and make its use safe.

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 .

We define several end-point channel bindings suitable for any IPsec channel where one or both peers are authenticated by a public key. These channel binding types use a hash function whereas they could use the raw un-hashed inputs. We use a hash function so as to produce manageably sized channel binding data (consider that this data often has to be held in kernel memory).

Given a channel C, initiator public key PKi, and responder public key PKr:

ipsec-end-point-sha256(C) := SHA256(PKi) XOR SHA256(PKr) The reason for the XOR is that in IPsec there's no deterministic rule for which peer will be an IKE initiator or responder. It is possible for both peers to have been initiators of Security Associtiations (SAs) used in the connection latching process, thus we need an operation that binds both peers' public keys without any kind of order (we don't want to do any sorting). PKi and PKr MUST be the bytes that appear as the value of the subjectPublicKeyInfo field (including the DER/BER TLV ) of the corresponding certificates as sent in CERT payloads, or, in the case of Raw RSA keys, the bytes that appear in the peer's CERT payload (see section 3.6 of ).

Given a channel C where only one peer authenticated via a public key PKp (and the other, presumably, via EAP):

ipsec-single-end-point-sha256(C) := SHA256(PKp) PKp is encoded as described in the previous section.

Hash agility is obtained by negotiating channel binding types. Variants of ipsec-end-point-sha256 based on other hash functions can be added as needed. Note that there's no in-band channel binding type negotiation in IKEv2 . It's possible and preferable that the peer's available channel binding types be determined from IKEv2 context. The algorithm or protocol for deciding the availability of any given variant of ipsec-end-point-sha256 MUST be specified by any such variant. For example, a putative ipsec-end-point-sha3 could be available if a putative SHA-3 function were used in any part of the IKEv2 exchanges that setup an SA linked to a connection latch. Or NOTIFY payloads might be added to IKEv2 for negotiating the use of a putative ipsec-end-point-sha3. ipsec-end-point-sha256 MUST always be available (at least until SHA-256 is deprecated).

To use channel binding to IPsec channels applications MUST first indicate their intention to do so and MAY provide a set of channel binding types that the application prefers. This should be done as part of the procedure to actively connect to peers or passively accept connections from peers. Once an IPsec channel is established the application may then request the channel's channel binding data for a specific channel binding type.

We define three socket options for the IPPROTO_IP socket level: IP_SEC_CBINDING, a socket option to be used prior to calling connect() and listen() or accept(). Applications MUST use this socket option to indicate their intention to used channel binding. This option does not take an argument; the actual socket option argument passed by the caller MUST be NULL. IP_SEC_CBINDING_TYPES, a socket option that applications can use after a connection is established to determine what channel binding types are available. This option takes as argument a pointer to a memory buffer into which an ordered list of channel binding type names will be written, separated by ASCII colons (':') and terminated by a NUL. If the provided buffer is too small then an error must be returned (EOVERFLOW?). IP_SEC_CBINDING_DATA, a socket option that applications can use after a connection is established to obtain the channel binding data for the given socket and the given channel binding type. This option takes as argument a pointer to a memory buffer containing the name of the requested channel binding type followed by an ASCII colon (':') and enough space for the system to place the channel binding data in return. If the provided buffer is too small then an error must be returned (EOVERFLOW?).

#define IP_SEC_CBINDING_TYPES #define IP_SEC_CBINDING_DATA #define IP_SEC_CBINDING_TYPES_BUFSIZE #define IP_SEC_CBINDING_DATA_BUFSIZE #define IP_SEC_CBINDING_ENDPOINT_SHA256_NAME \ "ipsec-end-point-sha256" #define IP_SEC_CBINDING_ENDPOINT_SHA256_NAME \ "ipsec-single-end-point-sha256" ]]> IP_SEC_CBINDING_TYPES_BUFSIZE and IP_SEC_CBINDING_DATA_BUFSIZE are advisory. Applications may need to resize their buffers. A pair of "sysconf" system variables providing actual maximum buffer sizes SHOULD be provided, and MUST be named _SC_IP_SEC_CBINDING_TYPES_BUFSIZE and _SC_IP_SEC_CBINDING_DATA_BUFSIZE.

, sizeof(cbinding_data)); (void) strlcat(cbinding_data, ":", sizeof(cbinding_data)); rc = getsockopt(sock_fd, IPPROTO_IP, IP_SEC_CBINDING_DATA, cbinding_data, sizeof (cbinding_data)); if (rc != 0) ... /* * Use the channel bindings (by passing them to GSS-API or SASL * functions). */ ... ]]>

[Add text about the two IPsec channel binding type registrations for the IANA channel binding type registry.]

All the security considerations of apply. This specification makes used of cryptographic hash functions. As such hash agility concerns arise. We do not provide a method for negotiation of future new channel binding types -- we leave it to their authors to do so. We do describe a couple of methods that they might use to do this. [NOTE: Perhaps we should specify new NOTIFYs now. Comments? -Nico]

...