Session Security EnvelopeHTT ConsultingOak ParkMI48237rgm@labs.htt-consult.comAlcatel-LucentRoom 2D-144, 600 Mountain Avenue Murray HillNJ07974USA igor.faynberg@alcatel-lucent.comNokiaRoom 2D-144, 600 Mountain Avenue Murray HillNJ07974USAhuilan.lu@nokia.comHickory Hill Consulting7453 Hickory HillSalineMI48176USAshares@ndzh.comFreeLanceyrz@anche.no
Security Area
SSE BOFRFCRequest for CommentsI-DInternet-DraftSSE
This memo specifies the details of the Session Security Envelope
(SSE). SSE is a session protocol aiming to guarantee
confidentiality, integrity and authentication completely
independently by the underlying context, namely network and
transport layers. A single session using the SEE protocol can
include a single transport session or multiple transport sessions.
This mean that SSE can survive the break-down in network and
transport layers or to attacks carried against them. SSE is also
applicable in networks lacking in classic inter-networking and
transport protocols SSE relies on modern AEAD block cipher modes of
operations, a class of block cipher modes which allows, at the same
time, to authenticate the message while encrypting a part of it.
This memo specifies the details of the Session Security Envelope
(SSE). SSE is a session protocol aiming to guarantee
confidentiality, integrity and authentication completely
independently by the underlying context, namely network and
transport layers. A single SSE session can span a single transport
session or multiple transport sessions. These transport sessions
can use the same transport layer protocol (E.g. TCP) or use
different transport protocols. SSE can survive the break-down in
network and transport layers or to attacks carried against them.
Moreover SSE will relies on modern AEAD block cipher modes of
operations, a class of block cipher modes which allows, at the same
time, to authenticate the message while encrypting a part of
it.
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 AEAD Block Cypher: (definition needed) SSE: Session Specific Envelope
The security boundary comes at layer above the IP transport layers
(TCP, SCTP, UDP). This security allows the data to be secure prior
to entering into a specific transport layer. A single SSE session
can span 1 or N transport protocol connections. The multiple
transport connections running under an SSE session may all use one
protocol (e.g. TCP) or multiple protocols (e.g. TCP, SCTP, UDP).
The higher layer security boundary provides a common security
layer.
The initial API is part of a shim with socket call over a TCP socket.
s = int socket(int domain, int type, int protocol) where: domain: AF_INET and AF_INET6 supported type: SOCK_SECURE protocol: Transport protocol (TCP (6), UDP (6), SCTP (132)) Note: The prototype for this SECURE_SOCKET is on a FREEBSD OS.
An SSE PDU is a Session Layer PDU (SPDU). In order to accommodate
various use cases three formats are available for the PDU. The
only difference between those formats is the size of length and
sequence number fields. Following these fields is the encrypted
payload and Integrity Check Value (ICV). Encrypted payload and ICV
has a substructure depending on the choice of encryption algorithm
and mode.
SSE compact format aims to provide a Session Security Layer to
applications leveraging on constrained network media with packet
size limitations or high cost per bit transport.
In the SSE compact format: SPI is 24 bits. FLAGS is 8 bits. Length is 12 bits Sequence Number is 20 bits
12 bits of Length allows (2^12) 4096 bytes in the Encrypted Payload
(does not include the ICV). 20 bits in the Sequence Number allows
to send (2^20) 1048576 packets before renegotiating the key. (The
ICV length is set by the KMP parameters, so the length is known and
therefore is not included in the length calculation)
The SPI internally is 32 bits to maintain SPI length consistancy.
The high order 8 bits are always ZERO, allowing for only sending
the lower 24 bits in the header.
SSE large format aims provide a Session Security Layer to
applications which have common sizes of transport packets.
In the SSE compact format: SPI is 32 bits. FLAGS is 8 bits. Length is 32 bits Sequence Number is 32 bits
32 bits of Length allows (2^32)or ~4Gbytes in the Encrypted Payload
(does not include the ICV). 32 bits in the Sequence Number allows
to send (2^32) ~40 billion packets packets before renegotiating the
key.
The 32 bits of length allows an IPv6 jumbogram to be included as in
the SSE Large Format Payload
SSE large format aims provide a Session Security Layer to high
performance networks.
In the SSE compact format: SPI is 32 bits. FLAGS is 8 bits. Length is 32 bits Sequence Number is 64 bits
32 bits of Length allows (2^32) 4294967296 bytes (4Gbytes) in the
Encrypted Payload (excluding the ICV). 32 bits in the Sequence
Number allows to send (2^64) 18446744073709551616 (around 18 *
10^18) packets before renegotiating the key.
SPI is the Security Parameter Index, a 32 bit number received from
the external KMP. It is the index into the Security Association and
is typically unidirectional. That is each direction in has its own
SPI. A KMP for a unicast communication would provide the two SPIs.
Multicast is different. Depending on the requirements, there can be
one SPI for all transmitters or one per transmitter.
The compact format only transmits 24 bits of the 32 bit SPI. The
SPI is internally kept as both the 32 bits SPI from the KMP and a
24 bit truncated SPI (with the 8 high order bits of zero). If this
truncation results in a duplicate SPI, the negotiation is rejected
and the KMP is called again.
Length is the length in bytes of the encrypted payload. This does
not include the ICV. The length of the ICV depends on the block
cipher settings.
FLAGS is a set of 8 options flags. Bit 7 is the GPComp (
) bit compression option bit.
Sequence Number is a, strictly increasing by 1, counter. When the
field cannot be increased without wrapping a key renegotiation MUST
be performed. Please note that this Sequence Number has not the
same meaning and implications of a Transport Layer sequence number,
hence increasing by 1 is a good idea.
Note: It is common practice to rekey some time BEFORE the number
space is exhausted.
SSE MUST use AEAD block cipher modes. AEAD block cypher modes will
ensure confidentiality on the payload and integrity of both the
payload and the headers (SPI, length and sequence number).
SSE will spawn across several ports and protocols, hence each
listened port and protocol can be a different SSE instance. See
Architecture Draft.
An application can establish a session via the SSE API, which in
turn will interact with a KMP daemon. SSE instance will get all
parameters related to the session from the KMP daemon.
Editorial note: Is this a local vulnerability?
After having established an SSE session, an application can send
application- level data using the normal socket calls. The SSE
layer will encapsulate the packet, and send it on the appropriate
transport session. The application doesn't need to know SPI,
sequence number or key. The local SSE knows these facts, and keeps
it within the SSE data associated with a set of transport
connections.
After having established an SSE session, the packets will be sent
to the transport layer for de-encapsulation. After header removal,
the socket processing will hand it to the SEE processing for
security check. If the packet is deemed secure, the socket will
remove the SSE envelope. The application see the byte stream as
data from a transport connection.
The application doesn't need to know SPI, sequence number or key,
relying on a fake connection. (but its local SSE instance knows it,
hence the application own memory where those are stored).
The use of SSE and its options (e.g. AES mode of operation) should
be part of the communication start up process. Although SSE can be
manually set up, this may result in a lack of crypto agility .
That is, only one algorithm is used and cannot easily be changed.
Thus manual set up for SSE should be limited to testing needs.
At set up, and application may call IKEv2 .
Currently there are no defined options for SSE in IKEv2 and it have
to be amended. It should be able to follow ESP in Transport Mode
.
At set up, and application may call HIPv2
or HIP-DEX .
HIP does not currently include a negotiation for SSE. SSE can be
added by assigning a HIP parameter value for an SSE Transform that
is higher than ESP. A value of 4101 can be used for this purpose.
The negotiation will mirror the ESP transform negotiation and be carried in the R1 and I2 payloads as is
ESP transform. This parameter and negotiation may be explicitly
expanded here at in a later revision.
IANA is requested to assign a HIP parameter value for the SSE
Transform. This parameter value should be higher than ESP. A value
of 4101 is recommended.
As SSE uses an AEAD block cipher, it is vulnerable to attack if a
sequence number is reused for a given key. Thus implementations of
SSE MUST provide for rekeying prior to Sequence Number rollover. An
implementation should never assume that for a given context, the
sequence number space will never be exhausted. Key Management
Protocols like IKEv2 or HIP could be used to provide for rekeying
management. The KMP SHOULD not create a network layer fate-sharing
limitation.
As any security protocol can be used for a resource exhaustion
attack, implementations should consider methods to mitigate
flooding attacks of messages with valid SPIs but invalid content.
Even with the ICV check, resources are still consumed to validate
the ICV.
SSE makes no attempt to recommend the ICV length. For constrained
network implementations, other sources should guide the
implementation as to ICV length selection. The ICV length
selection SHOULD be the the responsibility of the KMP.
As with any layered security protocol, SSE makes no claims of
protecting lower or higher processes in the communication stack.
Each layer's risks and liabilities need be addressed at that level.
GPCOMPThis document describes a protocol intended to provide lossless
compression for use within any datagram. It is particularly intended
for use in encrypted datagrams where lower-level compression is
ineffective.