idnits 2.17.1 draft-moskowitz-sse-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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 [RFC7296] or HIP [RFC7401] could be used to provide for rekeying management. The KMP SHOULD not create a network layer fate-sharing limitation. -- The document date (October 27, 2016) is 2710 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 161 -- Looks like a reference, but probably isn't: '2' on line 162 -- Looks like a reference, but probably isn't: '3' on line 163 == Outdated reference: A later version (-24) exists of draft-ietf-hip-dex-04 == Outdated reference: A later version (-02) exists of draft-moskowitz-gpcomp-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SSE BOF R. Moskowitz 3 Internet-Draft HTT Consulting 4 Intended status: Standards Track I. Faynberg 5 Expires: April 30, 2017 Stargazers Consulting, LLC 6 H. Lu 7 Retired 8 S. Hares 9 Hickory Hill Consulting 10 P. Giacomin 11 FreeLance 12 October 27, 2016 14 Session Security Envelope 15 draft-moskowitz-sse-04 17 Abstract 19 This memo specifies the details of the Session Security Envelope 20 (SSE). SSE is a session protocol aiming to guarantee 21 confidentiality, integrity and authentication completely 22 independently by the underlying context, namely network and transport 23 layers. A single session using the SEE protocol can include a single 24 transport session or multiple transport sessions. This mean that SSE 25 can survive the break-down in network and transport layers or to 26 attacks carried against them. SSE is also applicable in networks 27 lacking in classic inter-networking and transport protocols SSE 28 relies on modern AEAD block cipher modes of operations, a class of 29 block cipher modes which allows, at the same time, to authenticate 30 the message while encrypting a part of it. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 30, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 69 2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. SSE Security Boundary . . . . . . . . . . . . . . . . . . . . 3 72 4. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 5. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 5 74 5.1. SSE compact format . . . . . . . . . . . . . . . . . . . 5 75 5.2. SSE Large Format . . . . . . . . . . . . . . . . . . . . 6 76 5.3. SSE Extreme Format . . . . . . . . . . . . . . . . . . . 7 77 5.4. Header Fields . . . . . . . . . . . . . . . . . . . . . . 8 78 5.5. AEAD integration . . . . . . . . . . . . . . . . . . . . 9 79 6. Packet processing and State Machine . . . . . . . . . . . . . 9 80 6.1. Establishing a session . . . . . . . . . . . . . . . . . 9 81 6.2. Processing Outgoing Application Data . . . . . . . . . . 9 82 6.3. Processing Incoming Application Data . . . . . . . . . . 9 83 7. Negotiating SSE . . . . . . . . . . . . . . . . . . . . . . . 10 84 7.1. Using IKEv2 . . . . . . . . . . . . . . . . . . . . . . . 10 85 7.2. Using HIP . . . . . . . . . . . . . . . . . . . . . . . . 10 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 90 10.2. Informative References . . . . . . . . . . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 93 1. Introduction 95 This memo specifies the details of the Session Security Envelope 96 (SSE). SSE is a session protocol aiming to guarantee 97 confidentiality, integrity and authentication completely 98 independently by the underlying context, namely network and transport 99 layers. A single SSE session can span a single transport session or 100 multiple transport sessions. These transport sessions can use the 101 same transport layer protocol (E.g. TCP) or use different transport 102 protocols. SSE can survive the break-down in network and transport 103 layers or to attacks carried against them. Moreover SSE will relies 104 on modern AEAD block cipher modes of operations, a class of block 105 cipher modes which allows, at the same time, to authenticate the 106 message while encrypting a part of it. 108 2. Terms and Definitions 110 2.1. Requirements Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. . 116 2.2. Notations 118 This section will contain notations 120 2.3. Definitions 122 AEAD Block Cypher: (definition needed) 124 SSE: Session Specific Envelope 126 3. SSE Security Boundary 128 The security boundary comes at layer above the IP transport layers 129 (TCP, SCTP, UDP). This security allows the data to be secure prior 130 to entering into a specific transport layer. A single SSE session 131 can span 1 or N transport protocol connections. The multiple 132 transport connections running under an SSE session may all use one 133 protocol (e.g. TCP) or multiple protocols (e.g. TCP, SCTP, UDP). 134 The higher layer security boundary provides a common security layer. 136 4. API 138 The initial API is part of a shim with socket call over a TCP socket. 140 s = int socket(int domain, int type, int protocol) 141 where: 143 domain: AF_INET and AF_INET6 supported 145 type: SOCK_SECURE 147 protocol: Transport protocol (TCP (6), UDP (6), SCTP (132)) 149 int setsockopt(int sockfd, int level, int optname, 150 const void *optval, socklen_t optlen); 152 int getsocketopt(int sockfd, int level, int optname 153 const void *optval, socket 154 where: 155 sockfd: # socket file descriptor 156 optname: # option name (see below) 157 optval; # points to *sse_transport structure; 158 optlen; # length of option 160 optval values: 161 ADD_SSE_Transport[1]; # add transport to SSE 162 DELETE_SSE_Transport[2]; # delete transport to SSE 163 Query_SSE_Transport [3]; # Query transport 165 optval *sse_transport[MAX_SSE_TRANSPORTS]; - for add/deletes 167 struct *sse_add_transport 168 int nt_sockfd; # new transport socket 169 int protocol; # new protocol 170 ); 172 int getsockopt(int sockfd, int level, int optname, 173 void *optval, socklen_t *optlen); 175 int setsockopt(int sockfd, int level, int optname, 176 const void *optval, socklen_t optlen); 178 Figure 1 - Example SSE Socket API 180 Note: The prototype for this SECURE_SOCKET is on a FREEBSD OS. 182 5. Packet format 184 An SSE PDU is a Session Layer PDU (SPDU). In order to accommodate 185 various use cases three formats are available for the PDU. The only 186 difference between those formats is the size of length and sequence 187 number fields. Following these fields is the encrypted payload and 188 Integrity Check Value (ICV). Encrypted payload and ICV has a 189 substructure depending on the choice of encryption algorithm and 190 mode. 192 5.1. SSE compact format 194 SSE compact format aims to provide a Session Security Layer to 195 applications leveraging on constrained network media with packet size 196 limitations or high cost per bit transport. 198 In the SSE compact format: 200 SPI is 24 bits. 202 FLAGS is 8 bits. 204 Length is 12 bits 206 Sequence Number is 20 bits 208 12 bits of Length allows (2^12) 4096 bytes in the Encrypted Payload 209 (does not include the ICV). 20 bits in the Sequence Number allows to 210 send (2^20) 1048576 packets before renegotiating the key. (The ICV 211 length is set by the KMP parameters, so the length is known and 212 therefore is not included in the length calculation) 214 The SPI internally is 32 bits to maintain SPI length consistancy. 215 The high order 8 bits are always ZERO, allowing for only sending the 216 lower 24 bits in the header. 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | SPI | FLAGS | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Length | Sequence Number | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Encrypted Payload and ICV (Variable) | 226 ~ ~ 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 2 - Compact format 232 5.2. SSE Large Format 234 SSE large format aims provide a Session Security Layer to 235 applications which have common sizes of transport packets. 237 In the SSE compact format: 239 SPI is 32 bits. 241 FLAGS is 8 bits. 243 Length is 32 bits 245 Sequence Number is 32 bits 247 32 bits of Length allows (2^32)or ~4Gbytes in the Encrypted Payload 248 (does not include the ICV). 32 bits in the Sequence Number allows to 249 send (2^32) ~40 billion packets packets before renegotiating the key. 251 The 32 bits of length allows an IPv6 jumbogram to be included as in 252 the SSE Large Format Payload 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | SPI | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | RESERVED | FLAGS | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Sequence Number | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Encrypted Payload and ICV (Variable) | 265 ~ ~ 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 3 - Large Format 271 5.3. SSE Extreme Format 273 SSE large format aims provide a Session Security Layer to high 274 performance networks. 276 In the SSE compact format: 278 SPI is 32 bits. 280 FLAGS is 8 bits. 282 Length is 32 bits 284 Sequence Number is 64 bits 286 32 bits of Length allows (2^32) 4294967296 bytes (4Gbytes) in the 287 Encrypted Payload (excluding the ICV). 32 bits in the Sequence Number 288 allows to send (2^64) 18446744073709551616 (around 18 * 10^18) 289 packets before renegotiating the key. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | SPI | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | RESERVED | FLAGS | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Sequence Number | 301 + + 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Encrypted Payload and ICV (Variable) | 305 ~ ~ 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 4 - Extreme Format 311 5.4. Header Fields 313 SPI is the Security Parameter Index, a 32 bit number received from 314 the external KMP. It is the index into the Security Association and 315 is typically unidirectional. That is each direction in has its own 316 SPI. A KMP for a unicast communication would provide the two SPIs. 317 Multicast is different. Depending on the requirements, there can be 318 one SPI for all transmitters or one per transmitter. 320 The compact format only transmits 24 bits of the 32 bit SPI. The SPI 321 is internally kept as both the 32 bits SPI from the KMP and a 24 bit 322 truncated SPI (with the 8 high order bits of zero). If this 323 truncation results in a duplicate SPI, the negotiation is rejected 324 and the KMP is called again. 326 Length is the length in bytes of the encrypted payload. This does 327 not include the ICV. The length of the ICV depends on the block 328 cipher settings. 330 FLAGS is a set of 8 options flags. Bit 7 is the GPComp 331 [I-D.moskowitz-gpcomp] bit compression option bit. 333 0 1 2 3 4 5 6 7 334 +-+-+-+-+-+-+-+-+ 335 | C| 336 +-+-+-+-+-+-+-+-+ 338 Figure 5 - FLAGS field 340 Sequence Number is a, strictly increasing by 1, counter. When the 341 field cannot be increased without wrapping a key renegotiation MUST 342 be performed. Please note that this Sequence Number has not the same 343 meaning and implications of a Transport Layer sequence number, hence 344 increasing by 1 is a good idea. 346 Note: It is common practice to rekey some time BEFORE the number 347 space is exhausted. 349 5.5. AEAD integration 351 SSE MUST use AEAD block cipher modes. AEAD block cypher modes will 352 ensure confidentiality on the payload and integrity of both the 353 payload and the headers (SPI, length and sequence number). 355 6. Packet processing and State Machine 357 SSE will spawn across several ports and protocols, hence each 358 listened port and protocol can be a different SSE instance. See 359 Architecture Draft. 361 6.1. Establishing a session 363 An application can establish a session via the SSE API, which in turn 364 will interact with a KMP daemon. SSE instance will get all 365 parameters related to the session from the KMP daemon. 367 Editorial note: Is this a local vulnerability? 369 6.2. Processing Outgoing Application Data 371 After having established an SSE session, an application can send 372 application- level data using the normal socket calls. The SSE layer 373 will encapsulate the packet, and send it on the appropriate transport 374 session. The application doesn't need to know SPI, sequence number 375 or key. The local SSE knows these facts, and keeps it within the SSE 376 data associated with a set of transport connections. 378 6.3. Processing Incoming Application Data 380 After having established an SSE session, the packets will be sent to 381 the transport layer for de-encapsulation. After header removal, the 382 socket processing will hand it to the SEE processing for security 383 check. If the packet is deemed secure, the socket will remove the 384 SSE envelope. The application see the byte stream as data from a 385 transport connection. 387 The application doesn't need to know SPI, sequence number or key, 388 relying on a fake connection. (but its local SSE instance knows it, 389 hence the application own memory where those are stored). 391 7. Negotiating SSE 393 The use of SSE and its options (e.g. AES mode of operation) should 394 be part of the communication start up process. Although SSE can be 395 manually set up, this may result in a lack of crypto agility . That 396 is, only one algorithm is used and cannot easily be changed. Thus 397 manual set up for SSE should be limited to testing needs. 399 7.1. Using IKEv2 401 At set up, and application may call IKEv2 [RFC7296]. Currently there 402 are no defined options for SSE in IKEv2 and it have to be amended. 403 It should be able to follow ESP in Transport Mode [RFC4303]. 405 7.2. Using HIP 407 At set up, and application may call HIPv2 [RFC7401] or HIP-DEX 408 [I-D.ietf-hip-dex]. 410 HIP does not currently include a negotiation for SSE. SSE can be 411 added by assigning a HIP parameter value for an SSE Transform that is 412 higher than ESP. A value of 4101 can be used for this purpose. The 413 negotiation will mirror the ESP transform negotiation [RFC7402] and 414 be carried in the R1 and I2 payloads as is ESP transform. This 415 parameter and negotiation may be explicitly expanded here at in a 416 later revision. 418 8. IANA Considerations 420 IANA is requested to assign a HIP parameter value for the SSE 421 Transform. This parameter value should be higher than ESP. A value 422 of 4101 is recommended. 424 9. Security Considerations 426 As SSE uses an AEAD block cipher, it is vulnerable to attack if a 427 sequence number is reused for a given key. Thus implementations of 428 SSE MUST provide for rekeying prior to Sequence Number rollover. An 429 implementation should never assume that for a given context, the 430 sequence number space will never be exhausted. Key Management 431 Protocols like IKEv2 [RFC7296] or HIP [RFC7401] could be used to 432 provide for rekeying management. The KMP SHOULD not create a network 433 layer fate-sharing limitation. 435 As any security protocol can be used for a resource exhaustion 436 attack, implementations should consider methods to mitigate flooding 437 attacks of messages with valid SPIs but invalid content. Even with 438 the ICV check, resources are still consumed to validate the ICV. 440 SSE makes no attempt to recommend the ICV length. For constrained 441 network implementations, other sources should guide the 442 implementation as to ICV length selection. The ICV length selection 443 SHOULD be the the responsibility of the KMP. 445 As with any layered security protocol, SSE makes no claims of 446 protecting lower or higher processes in the communication stack. 447 Each layer's risks and liabilities need be addressed at that level. 449 10. References 451 10.1. Normative References 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, 455 DOI 10.17487/RFC2119, March 1997, 456 . 458 10.2. Informative References 460 [I-D.ietf-hip-dex] 461 Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", 462 draft-ietf-hip-dex-04 (work in progress), October 2016. 464 [I-D.moskowitz-gpcomp] 465 Moskowitz, R., Hares, S., Faynberg, I., Lu, H., and P. 466 Giacomin, "GPCOMP", draft-moskowitz-gpcomp-00 (work in 467 progress), March 2016. 469 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 470 RFC 4303, DOI 10.17487/RFC4303, December 2005, 471 . 473 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 474 Kivinen, "Internet Key Exchange Protocol Version 2 475 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 476 2014, . 478 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 479 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 480 RFC 7401, DOI 10.17487/RFC7401, April 2015, 481 . 483 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 484 Encapsulating Security Payload (ESP) Transport Format with 485 the Host Identity Protocol (HIP)", RFC 7402, 486 DOI 10.17487/RFC7402, April 2015, 487 . 489 Authors' Addresses 491 Robert Moskowitz 492 HTT Consulting 493 Oak Park, MI 48237 495 Email: rgm@labs.htt-consult.com 497 Igor Faynberg 498 Stargazers Consulting, LLC 499 East Brunswick, NJ 08816 500 USA 502 Email: igorfaynberg@gmail.com 504 Huilan Lu 505 Retired 507 Email: huilanlu2@gmail.com 509 Susan Hares 510 Hickory Hill Consulting 511 7453 Hickory Hill 512 Saline, MI 48176 513 USA 515 Email: shares@ndzh.com 517 Pierpaolo Giacomin 518 FreeLance 520 Email: yrz@anche.no