idnits 2.17.1 draft-ppsp-gabrijelcic-ecs-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 2, 2013) is 3982 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-ppsp-peer-protocol-06 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Gabrijelcic 3 Internet-Draft Jozef Stefan Institute 4 Intended status: Informational June 2, 2013 5 Expires: December 4, 2013 7 Enhanced Closed Swarm protocol 8 draft-ppsp-gabrijelcic-ecs-01 10 Abstract 12 The Enhanced Closed Swarm (ECS) protocol is a distributed access 13 control mechanism suitable for usage in Peer-to-Peer content delivery 14 systems. The protocol provides coarse or fine grained authorization 15 of peers participating in content distribution. As a result, only 16 authorized peers are allowed to communicate in a swarm. The protocol 17 also provides data confidentiality, integrity and origin 18 authentication for application data exchanged among peers. The 19 protocol is simple but flexible enough to enable a range of usage 20 scenarios. In addition to the ECS protocol, this document also 21 describes its application in the IETF PPSPP. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 4, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 59 2. Initial requirements . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Swarm requirements . . . . . . . . . . . . . . . . . . . . 5 61 3. Authorization credential - Proof-of-Access . . . . . . . . . . 6 62 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Enhanced Closed Swarm protocol . . . . . . . . . . . . . . . . 7 64 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1.1. Initial exchange . . . . . . . . . . . . . . . . . . . 7 66 4.1.2. Mutual authorization . . . . . . . . . . . . . . . . . 8 67 4.1.3. Authorization failure . . . . . . . . . . . . . . . . 9 68 4.1.4. Nonces . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.1.5. Requested service . . . . . . . . . . . . . . . . . . 10 70 4.1.6. Supported digital signature algorithms . . . . . . . . 10 71 4.1.7. PoA embedding and encoding . . . . . . . . . . . . . . 11 72 4.1.7.1. PoA encoding . . . . . . . . . . . . . . . . . . . 11 73 4.1.7.2. Digital signatures and public keys . . . . . . . . 12 74 4.2. Application data communication protection . . . . . . . . 14 75 4.2.1. Key establishment . . . . . . . . . . . . . . . . . . 14 76 4.2.1.1. Elliptic Curve Diffie-Hellman . . . . . . . . . . 14 77 4.2.1.2. Note on RSA based key establishment . . . . . . . 15 78 4.2.1.3. Keying material generation . . . . . . . . . . . . 15 79 4.2.2. Security services provisioning . . . . . . . . . . . . 17 80 4.2.2.1. AEAD-AES-GCM algorithms . . . . . . . . . . . . . 18 81 4.2.2.2. AEAD-AES-CBC-HMAC-SHA2 algorithms . . . . . . . . 18 82 4.2.2.3. Anti-replay service . . . . . . . . . . . . . . . 19 83 4.2.2.4. Nonce requirements and generation . . . . . . . . 19 84 4.2.2.5. Protected messages processing . . . . . . . . . . 21 85 4.2.2.6. Security services summary . . . . . . . . . . . . 22 86 4.3. Error messages . . . . . . . . . . . . . . . . . . . . . . 24 87 5. Access control . . . . . . . . . . . . . . . . . . . . . . . . 24 88 5.1. PoA validation . . . . . . . . . . . . . . . . . . . . . . 25 89 5.2. Rule based access control . . . . . . . . . . . . . . . . 25 90 6. Initializing an ECS enabled swarm . . . . . . . . . . . . . . 26 91 6.1. Swarm certificate . . . . . . . . . . . . . . . . . . . . 26 92 7. Using ECS with PPSPP . . . . . . . . . . . . . . . . . . . . . 28 93 7.1. ECS protocol UDP encapsulation . . . . . . . . . . . . . . 28 94 7.1.1. ECS protocol messages . . . . . . . . . . . . . . . . 28 95 7.1.2. Initial PPSPP handshake and ECS exchange . . . . . . . 29 96 7.1.3. ECS authorization . . . . . . . . . . . . . . . . . . 29 97 7.1.4. ECS encrypted message . . . . . . . . . . . . . . . . 30 98 7.1.5. Terminating the connection . . . . . . . . . . . . . . 31 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 100 9. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 103 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 104 11.2. Informative References . . . . . . . . . . . . . . . . . . 35 105 Appendix A. Revision history . . . . . . . . . . . . . . . . . . 37 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 108 1. Introduction 110 This document describes the Enhanced Closed Swarm protocol (ECS), a 111 distributed access control mechanism. The protocol was designed to 112 be used in Peer-to-Peer content delivery systems. It can be equally 113 used in streaming on-demand, live streaming as well as in 114 conventional downloading scenarios. 116 A peer participating in an ECS swarm needs an credential called a 117 proof-of-access (POA). The credential is used by the ECS protocol 118 when the peer joins the existing swarm of other peers. On joining 119 the protocol enables mutual authorization of both peers, the joining 120 one and the one already in the swarm. Each of the peers is 121 responsible to validate contacting peer credential and enforce 122 authorization decisions as a result of credential validation. After 123 mutual authorization the communication between peers is protected by 124 data confidentiality, integrity and origin authentication services 125 preventing potential malicious disruption or deceit of the 126 communication. 128 The credentials are expected to be issued to interested peers by 129 content owners, or distributors acting as credential issuers. This 130 document specifies basic issuing process requirements and the ECS 131 protocol compliant PoA specification. 133 This document specifies at first a general description of the 134 Enhanced Closed Swarm protocol and authorization credential and then 135 their usage in access control provisioning for PPSPP 136 [I-D.ietf-ppsp-peer-protocol] with UDP encapsulation. 138 1.1. Conventions Used in This Document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 2. Initial requirements 146 To use the ECS protocol, each peer must be able to generate a public- 147 private key pair according to the document specification and to keep 148 the private key secret. The peer must support specified core digital 149 signature and corresponding hash algorithms, and encryption and keyed 150 hash algorithms. The peer must be able to generate a secret key 151 according to the specification. 153 In the rest of the document the following notations are used: 155 Notation Meaning 156 ----------------------------------------- 157 SWid Swarm ID 158 Va, Vb Version, peer A, peer B 159 Na, Nb Nonce, peer A, peer B 160 PoAa, PoAb Proof-of-Access, peer A, peer B 161 RSa, RSb Requested Service, peer A, peer B 162 Ia,Ib Notification information, peer A, peer B 163 Sab Shared secret 164 Ks Issuer's public key (Swarm public key) 165 Kh Holder's public key 166 ET Expiry time 167 R Rules 168 {}Ks-1 Digital signature created with private key of the issuer 169 {}Ka-1 Digital signature created with private key of peer A 170 {}Kb-1 Digital signature created with private key of peer B 171 {}Ka Encryption using public key of peer A 172 [] Optional fields 173 || Concatenation symbol 174 PRF Pseudorandom function 175 K AEAD interface parameter, key 176 P AEAD interface parameter, plaintext 177 N AEAD interface parameter, nonce 178 A AEAD interface parameter, associated data 179 C AEAD interface parameter, ciphertext 180 T Data origin authentication and integrity service tag 181 EK Secret encryption key 182 MK Message authentication code key 183 NI AEAD nonce, implicit part 184 NE AEAD nonce, explicit part 185 SQ Anti-replay protection sequence number counter 187 2.1. Swarm requirements 189 A swarm using Enhanced Closed Swarm protocol must have at least one 190 public-private key pair. The private key is used for digitally 191 signing peers' authorization credentials. The public key is used by 192 the peers to verify the credentials. 194 For the protocol to be secure, trust must be managed between the 195 peers and the system entity owning the swarm key pair and issuing the 196 peer authorizations. Trust can be managed in different ways. For 197 example, swarm owner's digital certificate (and corresponding public 198 key) can be provided to peers as a trust anchor. Peers can use the 199 anchor to validate the swarm public key before trusting the key and 200 using it in the ECS protocol. Alternatively, peers can obtain the 201 swarm public key from a trusted source. 203 The most straightforward way to manage trust is to name the swarm 204 based on content and public key(s) of the swarm. In this way the 205 peers in the swarm are sure they are in the correct swarm since 206 changing of the keys will change the swarm. An example that should 207 be followed is given in Section 6, on initializing an ECS enabled 208 swarm. 210 3. Authorization credential - Proof-of-Access 212 Proof-of-access (PoA) is an authorization credential specified as 213 follows: 215 SWid, Ks, Kh, ET,[ R,] {SWid, Ks, Kh, ET[, R]}Ks-1 217 PoA contains the following information: SWid - the swarm identifier, 218 Ks - public key of the credential issuer, Kh - public key of the 219 credential holder, ET - PoA expiry time and R - rules to be evaluated 220 during authorization decision provisioning. The expression in curly 221 brackets denotes that the information presented in PoA is digitally 222 signed with the private key of the credential issuer. Credential 223 issuer uses PoA to authorize the key Kh to access the swarm 224 identified with SWid for specified time till ET under rules R. 226 The rules in the PoA are optional. In this simplest case the 227 authorization decision using such PoA is made based on SWid only, 228 without any granularity between authorized peers. The peer can join 229 the swarm with SWid if it possesses valid PoA with the same SWid, 230 otherwise it must be rejected by peers. 232 Rules bring additional flexibility into service provisioning and 233 enable fain grained peers authorizations. Rules specification is 234 discussed in the next section. 236 3.1. Rules 238 Rules specify access rights of a peer in a swarm. They are defined 239 by credential issuer, usually a content provider or distributor. 240 When a peer holding a credential contacts another peer in the swarm 241 for a service the contacted peer must evaluate the rules and enforce 242 the results of the evaluation. 244 The format of the Rules field, described with the ABNF notation 245 [RFC5234], is given below: 247 rules = [general] [per-chunk] 248 general = conditions 249 per-chunk = conditions 250 conditions = condition [log-operator conditions] / "(" conditions ")" 251 log-operator = "and" / "or" 252 condition = variable operator value / variable operator variable 253 operator = "=" / "!=" / "<" / "<=" / ">" / ">=" 254 variable = 1ALPHA *99(ALPHA / DIGIT) 255 value = 1*10DIGIT / 1*10DIGIT "." DIGIT /"'" 1*10ALPHA "'" 257 It contains two groups of conditions: a general group and per-chunk 258 group. The general conditions are evaluated every time the 259 credential holder connects to another peer or can require evaluation 260 during the entire session between peers. The per-chunk conditions 261 are evaluated on every chunk request from the credential holder. The 262 conditions compare a variable as defined in an environment of the 263 peer evaluating the rules with a predefined value in the rules or 264 another variable. The details are further explained in Section 5.2. 265 Each group of conditions is positively evaluated only if the compound 266 logical sentence produces as a result a positive truth value. 268 4. Enhanced Closed Swarm protocol 270 The Enhanced Closed Swarm protocol starts as soon as a peer tries to 271 join the swarm or when the peer contacts additional peer(s) to 272 participate in content distribution. If successful, the result of 273 the protocol is mutual authorization of both peers. If not, either 274 of peers can issue an error message specifying the reason for 275 failure. 277 The protocol consists of two parts. The first is a handshake aimed 278 at mutual authorization of two peers and the second, if the handshake 279 was successful, providing security services for application data 280 exchanged between the peers. 282 4.1. Handshake 284 The handshake is based on challenge-response identification by 285 public-key techniques as defined in [HAC], section 10.3.3 (ii). The 286 handshake is defined with six messages: two in initial exchange, two 287 in mutual authorization phase and two that are sent on failure. 289 4.1.1. Initial exchange 291 The ECS protocol always begins with exchange of swarm identifiers 292 (SWid), ECS versions (V) as used by peers and nonces (N). The 293 exchange is presented on the following diagram: 295 Peer A (initiator) Peer B (responder) 296 ------------------------------------------------------------------- 297 SWid, Va, Na --> (1) 298 <-- SWid, Vb, Nb (2) 300 The exchange assures that the peers are in the same swarm and use 301 compatible versions of the protocol. If peer B is not in the same 302 swarm as peer A, peer B must terminate the communication. Error 303 message must not be sent to the initiating peer. Nonces assure 304 freshness of the current protocol exchange, and are used with other 305 information to derive peers shared secrets as explained in 306 Section 4.2.1.3. Although peer B, as responder, could already start 307 authorization process at the initiator in the second message, the 308 burden of the first cryptographic operation is shifted from the 309 responder to initiator (peer A) to prevent DoS attack vector on B. 311 4.1.2. Mutual authorization 313 PoAa, [RSa,] {Na, Nb, PoAa 314 [, RSa]}Ka-1 --> (3) 316 In the third message peer A asks for authorization. The message 317 contains peer A's PoA (PoAa), optional information on requested 318 service (RSa) and digitally signed peers' nonces, initiator PoA and 319 the requested service, if any. Peer A signs this information with 320 its private key from the same key pair as the public key embedded in 321 the PoA (PoAa). The mesage is sent to peer B. At this point peer B 322 verifies the digital signature of the message with A's public key 323 embedded in PoAa (Kh), PoA's digital signature with credential 324 issuer's public key embedded in PoAa (Ks), and validates the PoA as 325 explained in Section 5.1. Before using the credential public key 326 embodied in the PoA, the peer must validate if the key is among 327 trusted swarm keys. 329 If the verifications and validations are successful, peer B responds 330 with the fourth message requesting authorization at peer A: 332 <-- PoAb, [RSb,] [{Sab}Ka, ] {Na, Nb, 333 PoAb [, RSb], {Kab}Ka}Kb-1 (4) 335 The fourth message is the same as the third message except that the 336 responder (peer B) may add a shared secret Sab, encrypted with the 337 public key of peer A (Ka), to the message. If present, the encrypted 338 shared secret is included in information to be signed and signed with 339 the private key from the same key pair as peer B's public key 340 embedded in the peer's PoA (PoAb). The rest of the process of 341 verification, validation and authorization at peer A is the same as 342 it is after message three at peer B. For message verification the 343 public key (Kh), embedded in peer B's PoAb, is used. 345 If both peers have been successfully authorized they can start 346 content related communication. The communication is protected by 347 data confidentiality, integrity and origin authentication services as 348 described in Section 4.2. 350 [Application data] 351 Peer A <--> Peer B 353 4.1.3. Authorization failure 355 If either of digital signature verifications and the PoA validations 356 fail, the validating peer denies access with one of the following 357 messages: 359 <-- PoAb, Ib, {Na, Nb, 360 PoAb, Ib}Kb-1 (5) 361 PoAa, Ia, {Na, Nb, PoAa, 362 Ia}Ka-1 --> (6) 364 The messages are structurally the same. If peer A's authorization 365 fails at peer B, peer B sends the fifth message to peer A containing 366 its PoAb, information about the failure and the digitally signed 367 nonces (Na, Nb), peer B's PoA (PoAb) and failure information (Ib). 368 The signature is calculated with the peer B's private key. The 369 failure information must contain the reason for error and may contain 370 a hint on how to correct the error. After sending the error message 371 peer B stops communicating with peer A, no further data must be 372 exchanged. Peer B should delete all ephemeral information obtained 373 or created during the protocol exchange. If peer B's authorization 374 fails at peer A after the message 4 the procedure is exactly the 375 same. 377 It has to be noted that messages 5 or 6 can be sent to the 378 corresponding peer even in the middle of successfully started 379 session. The reason for such behavior is related to rules (R) based 380 access control, see Section 5.2 for details. 382 If for any reason the peer leaves the swarm, gracefully or 383 ungracefully the remaining peer should remove all ephemeral 384 information obtained or created during the protocol exchange. If the 385 peer in question at some time later will join the swarm, the ECS 386 protocol must be repeated again for successful peers authorization. 388 4.1.4. Nonces 390 Nonces in the ECS initial key exchange must be randomly chosen. 391 Nonces are used to ensure freshness of the messages exchanged and to 392 ensure freshness to the key material generation needed for 393 application data protection as explained in Section 4.2.1.3. Nonces 394 must be at least half the key size of the pseudorandom function as 395 described in Section 4.2.1.3.1. If the same random number source is 396 used for both keys and nonces, care must be taken to ensure that the 397 latter use does not compromise the former [RFC5996]. 399 4.1.5. Requested service 401 Requested service field allows the requester (peer A or peer B in 402 this section) to request specific service from the responder. The 403 service can be related to service level, quality of service, 404 dedicated bandwidth, etc. The field is defined with specific service 405 variable name and its requested value. Requested service field is 406 described in ABNF [RFC5234] notation below: 408 ReqService = ["(" assignment ")"] ["," ReqService] 409 assignment = variable "," value 410 variable = 1ALPHA *99(ALPHA / DIGIT) 411 value = 1*10DIGIT / 1*10DIGIT "." DIGIT / "'" 1*10ALPHA "'" 413 4.1.6. Supported digital signature algorithms 415 Digital signature algorithms like RSA [RSA], DSA [FIPS186-3] and 416 ECDSA [SEC1] may be used to implement the ECS protocol. Selection of 417 the right algorithm doesn't depend only on its strength and strict 418 purpose. Important features to consider are the size of the keys and 419 digital signature, as well as the algorithm performance in the target 420 environment. 422 This document describes the ECS protocol as well as its usage with 423 the PPSPP protocol run over the UDP. The amount of data to 424 encapsulate is of crucial importance for the UDP encapsulation. 425 ECDSA key sizes are the smallest for comparable bits in security 426 regarding the other stated digital signature protocols. As minimal 427 common denominator the ECDSA therefore must be supported by the ECS 428 protocol implementations. 430 Digital signature encoding, and key requirements and encoding are 431 presented in Section 4.1.7.2. 433 4.1.7. PoA embedding and encoding 435 The PoA as defined in Section 3 can be quite large. When minimal, 436 without any rules (R) specified, and ignorig other smaller size 437 fields, it contains two public keys and a digital signature. The 438 maximum size of the rules field is in general not specified and could 439 be large as well. 441 The PoA can be embedded into the protocol exchange directly or 442 indirectly via an URL. The encapsulations of the ECS protocol must 443 specify the PoA field with a type and PoA information: either PoA 444 itself or URL from where the PoA can be obtained from. 446 Implementations must support URLs that employ the http scheme 447 [RFC2616]. URLs must be encoded according to specification 448 [RFC3986]. The ECS protocol processing is in case of the indirect 449 embedding extended with obtaining the PoA from a specified location. 450 All the other procedures after obtaining the PoA are exactly as 451 specified in Section 4.1.2. If the PoA cannot be obtained from the 452 specified location access must be denied as specified in 453 Section 4.1.3. 455 The default PoA embedding types, for use in encapsulation in 456 transport protocol, are: 458 0x00 Directly embedded PoA 459 0x01 PoA obtainable from URL 461 4.1.7.1. PoA encoding 463 Every PoA field have its unique type. Each field is encoded with its 464 type and value. 466 Swarm identifier (SWid) must be encoded as octet string. 468 Expiry time (ET) default encoding is standard ASN.1 universal time 469 type UTCTime. UTCTime conventions as specified in [RFC5280], Section 470 4.1.2.5.1, must be followed. 472 Rules (R) as specified in Section 3.1 must be encoded as octet 473 string. 475 The PoA field type identifiers for SWid, ET and R are defined as 476 follows, together with other PoA field types that are further defined 477 in the next section: 479 0x01 # Swarm identifier 480 0x02 # Swarm public key Ks 481 0x03 # Peer public key Kh 482 0x04 # Expiry time 483 0x05 # Rules 484 0x06 # Digital signature 486 4.1.7.2. Digital signatures and public keys 488 The public keys Kh and Ks, and corresponding digital signature must 489 be encoded within the PoA with its type and value. The encoding for 490 ECDSA is as follows. 492 4.1.7.2.1. ECC key and ECDSA signature, encoding and requirements 494 Peer's public keys contained in the PoA (Kh) are Eliptic Curve 495 Cryptography (ECC) public keys. ECC public keys are defined with 496 required values for a particular set of elliptic curve domain 497 parameters and a key. Well-known curves define a standard set of 498 domain parameters. For the purpose of this document well known 499 curves as are defined in [RFC5903] should be used. The keys have the 500 following format encoding: 502 type # uniquely identifies well-known curve 503 octet string # encoded elliptic curve point 505 Every ECS protocol implementation must support the following named 506 curves specified below, based on [RFC5903], [FIPS186-3] and [SEC] 507 naming is provided as well, and the ECS protocol type: 509 |------+--------------------------+-------+-----------| 510 | Type | RFC5903 | NIST | SEC | 511 |------+--------------------------+-------+-----------| 512 | 0x01 | 256-Bit Random ECP Group | P-256 | secp256r1 | 513 | 0x02 | 384-Bit Random ECP Group | P-384 | secp384r1 | 514 | 0x03 | 521-Bit Random ECP Group | P-521 | secp521r1 | 515 |------+--------------------------+-------+-----------| 517 Octet string, specified in format encoding, is the ECC public key 518 encoded from elliptic curve point into a octet string as is specified 519 in Section 2.3.3 of [SEC1]. Point compression may be used. The 520 default curve is 256-Bit Random ECP Group. 522 Other well-known curves could be used. The keys as specified are 523 used in the ECS protocol for digital signing and key establishment 524 (ECDH, Elliptic Curve Diffie-Hellman), see Section 4.2.1.1. Note 525 that [SP800-57-3] recommends P-256 and P-384 curves for key 526 establishment and digital signature. 528 The ECDSA digital signature algorithm is specified in [SEC1]. The 529 data hash algorithm must be from SHA2 family of hash functions 530 [FIPS180-3]. 532 The digital signature is encapsulated as follows: 534 type # Digital signature type 535 octet string # Signature 537 The PoA digital signature field types are defined as follows, taking 538 into account the [RFC4754] recommendations regarding hash algorithm: 540 |------+-----------+--------------------------+----------------| 541 | Type | ECDSA | Elliptic Curve Group | Hash Algorithm | 542 |------+-----------+--------------------------+----------------| 543 | 0x01 | ECDSA-256 | 256-Bit Random ECP Group | SHA-256 | 544 | 0x02 | ECDSA-384 | 384-Bit Random ECP Group | SHA-384 | 545 | 0x03 | ECDSA-521 | 521-Bit Random ECP Group | SHA-512 | 546 |------+-----------+--------------------------+----------------| 548 The specified digital signature and hash algorithms must be supported 549 by the implementation. Other ECDSA digital signature types and 550 corresponding hash algorithms could be used. The default algorithm 551 is the ECDSA-256. 553 A result of ECDSA signature algorithm are pair of integers r and s. 554 The encoding of the signature should follow the procedure specified 555 in [RFC6090], Section 6.2, for each integer. The decoding procedure 556 is defined in Section 6.1. The signature is a concatenation of the 557 octet strings. The integers octet string size depends on the ECDSA 558 algorithm and hash function, the table of integers bit lengths, 559 according to [RFC4754], is provided below: 561 |-----------+-------------+--------------| 562 | Digital | | | 563 | Signature | Bit Lengths | Bit Length | 564 | Algorithm | of r and s | of Signature | 565 |-----------+-------------+--------------| 566 | ECDSA-256 | 256 | 512 | 567 | ECDSA-384 | 384 | 768 | 568 | ECDSA-521 | 528 | 1056 | 569 |-----------+-------------+--------------| 571 ECC peer public keys are used in the ECS protocol for key 572 establishment as well. The peer public keys embedded in PoAs in the 573 same swarm must use the same well-known curve. The issuer's key (Ks, 574 swarm key), the digital signature of the PoAs, and the peer digital 575 signature either in message 3 or 4 of the protocol, must follow the 576 specification in this section. 578 4.2. Application data communication protection 580 Application data communication between peers needs to be protected. 581 In this section and its sub-sections the data exchanged between peers 582 is referred as a message. For an attacker it is easy to get access 583 to content exchanged in messages or maliciously disrupt or deceive 584 the communication. Data confidentiality, integrity and origin 585 authentication security services need to be provided. Encapsulation 586 in connectionless transport protocol like UDP requires anti-replay 587 protection as well. Encapsulations in other protocols require a 588 check if the target protocol anti-relay mechanisms are strong enough 589 for intended purpose and at right level of abstraction. 591 Data confidentiality service in open communication is provided by 592 encrypting the data in communication. Stream and block cipher 593 algorithms are used for encrypting the data. The ECS protocol may be 594 used with connectionless protocols so only block cipher algorithms 595 are considered. Data confidentiality service using encryption 596 require key establishment, described in Section 4.2.1. 598 Data integrity and origin authentication are dependent services. 599 Keyed hash algorithms are often used for the services provisioning. 600 Some newer algorithms, like those described in [RFC5116], combine all 601 three services. This document describes usage of both keyed hash and 602 combined mode algorithms in Section 4.2.2. 604 4.2.1. Key establishment 606 Key establishment is a procedure that results in keying material 607 being shared among two peers. Key establishment depends on selection 608 of digital signature algorithm. 610 4.2.1.1. Elliptic Curve Diffie-Hellman 612 The Eliptic Curve Diffie-Hellman (ECDH) key establishment algorithm 613 generates a shared secret from the other peer public key (lets say 614 peer A) and a private key of the peer generating the secret (peer B). 615 The other peer (peer A) generates the same secret from its private 616 key and the other peer (peer B) public key. 618 Using ECDH during the ECS protocol message exchange peer B can 619 calculate the secret key Sab after receiving and verifying the 620 message 3 from peer A, and peer A after receiving and verifying the 621 message 4, see Section 4.1.2. There is no need to exchange any other 622 additional information in the message 4; peer B must not send the 623 shared secret Sab to peer A while using the ECDH key establishment 624 algorithm. 626 The ECS protocol protects the ECDH algorithm against active attacks 627 since the public keys of both peers are authenticated via message 3 628 and 4 digital signature verification. The ECDH algorithm is further 629 described in [RFC6090], Section 4. For interoperability see the same 630 document, Section 7.1. The shared secret (Sab) is compact 631 representation of the result of the ECDH computation. 633 The ECDH as described algorithm must be supported by ECS protocol 634 implementations. 636 4.2.1.2. Note on RSA based key establishment 638 If the RSA algorithm is used for key establishment the key needs to 639 be exchanged directly among ECS protocol peers. Peer B generates the 640 shared secret after receiving and validating the message 3, see 641 Section 4.1.2, and sends the secret in the message 4, in the field 642 Sab, encrypted with the peer A public key. The RSA algorithm is not 643 mandatory in the current specification. The Sab ECS protocol field 644 is reserved for possible future use. 646 4.2.1.3. Keying material generation 648 For the security services provisioning a number of shared secrets 649 between peers in communication are needed. To jointly arrive to same 650 secrets a known pseudorandom function is needed, see 651 Section 4.2.1.3.1, and a procedure for shared secret generation, see 652 Section 4.2.1.3.3. The content of this section is based on TLS 653 [RFC5246] and is only summarized here. 655 4.2.1.3.1. Pseudorandom function 657 The pseudorandom function (PRF) is described in [RFC5246], Section 5. 658 The PRF is HMAC based [RFC2104] and uses hash algorithm SHA-256. The 659 PRF is defined as follows: 661 PRF(secret, label, seed) = P_(secret, label || seed) 663 The label is an ASCII string, the secret and seed are defined in 664 Section 4.2.1.3.2 and Section 4.2.1.3.3. 666 The P_(secret, data) function is a data expansion function that 667 expands the secret and data as follows: 669 P_hash(secret, seed) = HMAC_hash(secret, A(1) || seed) || 670 HMAC_hash(secret, A(2) || seed) || 671 HMAC_hash(secret, A(3) || seed) || ... 673 A() is defined as: 675 A(0) = seed 676 A(i) = HMAC_hash(secret, A(i-1)) 678 P_ based on SHA-256 generates 32 bytes of output data on each 679 iteration. A number of iterations may be needed to obtain required 680 output data size. A summary of the PRF required data sizes for 681 supported security services algorithms is presented in 682 Section 4.2.2.6, Table 1. 684 4.2.1.3.2. Master secret 686 The master secret generation is described in [RFC5246], Section 8.1. 687 The master secret is generated from secret key, result of key 688 establishment as described in Section 4.2.1, and nonces exchanged in 689 the ECS protocol initial exchange, see Section 4.1.1. 691 master_secret = PRF(Sab, "master secret", 692 Na || Nb) 693 [0..47]; 695 The notation on the end of the PRF function denotes that the master 696 secret is exactly 48 bytes in length. The PRF function secret 697 parameter value is Sab and the seed parameter value is concatenation 698 of the nonces. The label parameter value is "master secret". 700 4.2.1.3.3. Key generation 702 Key generation is described in [RFC5246], Section 6.3. The 703 algorithms that provide data confidentiality, and data integrity and 704 origin authentication separately, need 4 shared secrets: two for 705 keyed hash computation and two for data encryption. The peers in 706 communication (peer A and peer B) use separate shared secrets for 707 protecting sending and receiving data traffic. The algorithms that 708 provide all three services combined may need 4 secrets as well: two 709 for data encryption and two for initialization vector (IV) 710 generation. The last two secrets for IV generation are needed only 711 if implicit nonce techniques are used as explained in 712 Section 4.2.2.1. The shared secrets are generated as follows: 714 key_block = PRF(master secret, 715 "key expansion", 716 Na || Nb); 718 The PRF function secret parameter value is the master secret, 719 generated as explained in previous section, the label parameter value 720 is "key expansion" and the seed parameter value is a concatenation of 721 the nonces. A number of PRF computations depends on needed length of 722 output data. The key_block is then partitioned as follows: 724 peerA_write_EK[EK_length] 725 peerB_write_EK[EK_length] 726 peerA_write_NI[NI_length] 727 peerB_write_NI[NI_length] 728 peerA_write_MK[MK_length] 729 peerB_write_MK[MK_length] 731 Usage of the generated shared secrets and their lengths is explained 732 in section Section 4.2.2. Note that not all the values are needed 733 for all algorithms. The order of the partitioning is different as in 734 [RFC5246]. 736 4.2.2. Security services provisioning 738 Data confidentiality, origin authentication and integrity services in 739 the ECS protocol must be provided through the AEAD (Authenticated 740 Encryption with Associated Data) interface as defined in [RFC5116]. 741 The interface hides the cryptographic details of the services design 742 and implementation and it is suitable for wrapping both combined mode 743 and keyed hash algorithms. 745 The AEAD interface has two operations, authenticated encryption and 746 authenticated decryption. The authenticated encryption has four 747 input parameters: secret key K, nonce N, plaintext P and associated 748 data A. There is a single output: ciphertext C or an indication that 749 the requested operation could not be performed. A part of the 750 ciphertext C is a tag T, providing data origin authentication and 751 integrity services. 753 The secret key K is a result of key establishment as explained in 754 Section 4.2.1.3.3. The key must not be explicitly included in any 755 other interface input. The nonce N is random and non-repeating 756 value. It is of the same nature as the nonce as defined in 757 Section 4.1.4, but of different value, and it could be generated in 758 different way, see Section 4.2.2.4 for details on nonce requirements 759 and generation. The plaintext P is application data communication 760 message. The associated data A is data that must be authenticated 761 and integrity protected, but does not need to be encrypted. The 762 nonce must not be added to associated data A. It is checked 763 internally to the AEAD algorithm. On the wire the nonce, or its 764 explicit part, is always prepended to the ciphertext. 766 The authenticated decryption has four inputs: K, N, A and C as 767 defined above. It has a single output, ether a plaintext P or an 768 indication that the inputs are not authentic. 770 This document specifies six AEAD interface compliant algorithms for 771 the security services provisioning: two based on AES-GCM algorithm 772 and four based on AES-CBC-HMAC-SHA algorithms. The protocol 773 implementations must implement the first two and should implement the 774 other four. The other four may become mandatory for implementation 775 when their specification standardization is finalized. Other 776 algorithms may be used if they comply to AEAD interface and fulfill 777 the interface requirements as are specified in [RFC5116], section 4. 779 4.2.2.1. AEAD-AES-GCM algorithms 781 The AEAD-AES_GCM algorithms are specified in [RFC5116]. The 782 algorithms work as specified in [SP800-38D], using AES-128 or AES-256 783 block cipher. Corresponding algorithms are AEAD_AES_128_GCM, 784 specified in the [RFC5116] section 5.1, and AEAD_AES_256_GCM, 785 specified in the section 5.2 of the same document. 787 The algorithms are named and have the same numeric identifier as 788 specified in [RFC5116]. The default algorithm to be used in the ECS 789 protocol implementation is AEAD_AES_128_GCM. 791 The AEAD interface key K is key EK, derived as specified in 792 Section 4.2.1.3.3. The plaintext P is entire application data 793 communication message. The nonce N must be deterministic as 794 specified in Section 4.2.2.4.1. The nonce N length must be 12 795 octets. The associated data A is anti-replay field SQ, if the 796 service is used. 798 4.2.2.2. AEAD-AES-CBC-HMAC-SHA2 algorithms 800 The AEAD-AES-CBC-HMAC-SHA2 algorithms are specified in 801 [AEAD-AES-CBC]. The algorithms use encrypt-then-MAC method based on 802 AES in chaining block cipher (CBC) mode encryption with random 803 nonces, see Section 4.2.2.4.2,, and message authentication code as a 804 keyed authentication code uses HMAC [RFC2104] with SHA hash function, 805 truncated to 128 bits (16 octets) [RFC4868]. 807 The [AEAD-AES-CBC] specifies four algorithms: 808 AEAD_AES_128_CBC_HMAC_SHA_256, AEAD_AES_192_CBC_HMAC_SHA_384, 809 AEAD_AES_256_CBC_HMAC_SHA_512 and AEAD_AES_128_CBC_HMAC_SHA1. The 810 algorithms differ in the length of the AES key (128, 192 and 256) and 811 corresponding SHA hash function (SHA256, SHA384, SHA512 and SHA1). 813 The AEAD interface inputs P and A are the same as in the AEAD-AES-GCM 814 case. The AEAD interface encryption key K is concatenation of the 815 encryption key EK and HMAC key MK, derived as specified in 816 Section 4.2.1.3.3. The nonce N, as an input to the AEAD interface is 817 zero-length. The AES-CBC mode encryption requires padding of the 818 plaintext P up to the size of the AES encryption block. 820 4.2.2.3. Anti-replay service 822 Application data communication messages are anti-replay protected 823 with a sequence number. The sequence number must be 32 bits long and 824 is transmitted explicitly with the message. The sequence number 825 message counter of ECS protocol instance must be initialized to one 826 at the sender and to zero at the receiver. For each transmitted 827 message within the instance at the sender, the sequence number is 828 increased by one. If the message anti-replay service is validated 829 negatively the message must be discarded. 831 The messages are discarded based on sliding receive window. The 832 following sliding window procedure, based on [RFC4302] must be 833 followed. The receive window size of 32 must be supported, larger 834 window sizes may be required by target transport protocol 835 encapsulation or chosen by the receiver. The "right" edge of the 836 window is at the highest sequence number of the positively validated 837 message. The messages below "left" edge of the window are rejected. 838 The messages within the window are checked for duplicates. The 839 positively validated message is a message for which all provided 840 security services were validated to positive value. Only the 841 sequence numbers of positively validated messages update the sequence 842 numbers received and can slide the window. The pseudocode as 843 presented in appendix section B2.3 of [RFC4302], describes an 844 efficient sliding window algorithm implementation based on bits 845 shifting (the "pass integrity check" code condition needs to be 846 replaced with positive security services validation). 848 The anti-replay service is the first security service validated for 849 the received message matched to the ECS protocol instance, allowing 850 fast discards based on the sliding window procedure. 852 The sequence number transmitted with the message must be protected by 853 data origin authentication and integrity services. It must not be 854 confidential, therefore data confidentiality service is not provided 855 for the sequence number. If the sequence number security services 856 are not validated positively the entire message fails the validation 857 and it must be discarded. 859 4.2.2.4. Nonce requirements and generation 861 A basic nonce requirement is nonce value uniqueness for each AEAD 862 interface invocation, for any fixed value of the secret key 863 [RFC5116]. To avoid synchronization of used nonce values between two 864 peers in communication a separate secret key is used for each 865 direction, see Section 4.2.1.3.3. Nonce does not need to be 866 confidential. To prevent precomputation attacks at least part of the 867 nonce should be unpredictable prior the secret key establishment. 869 Nonces can be generated in a number of ways. Two nonce construction 870 frameworks to be used with this specification are deterministic and 871 random as are described in [SP800-38D]. 873 4.2.2.4.1. Deterministic nonces 875 In the deterministic construction, the nonce is a concatenation of a 876 fixed field and an invocation field. The fixed part identifies the 877 encrypting device. The invocation part provides the nonce's 878 uniqueness. The nonce must be 12 octets long. The fixed field NI is 879 8 octets long and is generated as explained in Section 4.2.1.3.3. 880 The invocation field is 4 octets long and is a counter. The counter 881 should start at 1. The counter value must not be reused. If the 882 counter space is exhausted, the ECS protocol connection must 883 terminate and a new one may be established, if needed. Since the 884 nonce construction is deterministic and known to both the encrypting 885 and decrypting device, only invocation part of the nonce needs to be 886 passed from the encrypting to decrypting device. 888 The deterministic nonce generation is compliant with AEAD 889 specification [RFC5116] recommended nonce creation, specified in 890 Section 3.2. Unlike the partly implicit nonces as described in 891 Section 3.2.1, it doesn't specify fixed-distinct field as explicit. 892 If multiple encryption devices with the same key are to be used with 893 this specification, a separate nonce implicit part NI should be 894 generated for each of them. Such usage is not specified in this 895 specification. 897 4.2.2.4.2. Random nonces 899 In the random construction the nonce is a concatenation of a random 900 field and the free field. The random field must be at least 12 901 octets long. The free field has the same role as fixed field in the 902 deterministic construction and may be empty. The nonce must be 903 unpredictable to an adversary. For generating the random field 904 values a pseudorandom generator may be used with the same level of 905 security as the block cipher in use. The initial inputs for 906 pseudorandom generator must not make use of encryption key or keyed 907 hash key as specified in Section 4.2.1.3.3. Suitable pseudorandom 908 generators are described in [SP800-90A]. 910 The AEAD interface allows zero-length nonces as input to AEAD 911 encryption function. In this case the AEAD implementation must 912 provide a suitable pseudorandom generator and input for its 913 initialization. Since the random field values are generated at 914 random their values must be passed along with the ciphertext C to the 915 decrypting device. If the free field is used the procedure for its 916 value generation may be know. In such case the field may not be 917 passed along with the ciphertext. 919 4.2.2.5. Protected messages processing 921 This section assumes that the initial ECS handshake as described in 922 Section 4.1.1 and Section 4.1.2 was successful and that the keying 923 material was generated at both peers in communication, A and B, as 924 described in Section 4.2.1.3. The anti-replay service, as described 925 in Section 4.2.2.3, is provided for the application data 926 communication. 928 Peer A assembles the application data message per the application 929 specification. The anti-replay service sequence number counter is 930 increased by one. Then the peer invokes the AEAD encryption 931 interface with the following parameters, depending on the algorithm 932 selection: 934 - secret key K, either key EK generated as explained in 935 Section 4.2.1.3.3 (peerA_write_EK), or concatenation of EK and MK 936 keys (peerA_write_EK || peerA_write_MK) 938 - nonce N, either concatenation of implicit part and explicit part 939 (peerA_write_NI || NE), or zero-length nonce 941 - plaintext P, application data message 943 - and associated data, the message sequence number counter field. 945 If the AEAD interface invocation returns ciphertext C, the message to 946 be send to the peer is formed as: 948 protected message = SQ || NE || C or SQ || C 950 The protected message is sent to peer B and the sequence number 951 counter value stored. If the AEAD interface returns an indication 952 that the requested encryption operation could not be performed the 953 application message is discarded. Such event should be logged at the 954 sender. 956 When peer B receives the message the message is disassembled. The 957 peer must check the received sequence number, according to the 958 procedure as described in Section 4.2.2.3. If the sequence number is 959 not in the sequence number window or newer, the message must be 960 discarded. If the sequence number checkes out, the peer invokes the 961 AEAD decryption interface with the following parameters: 963 - secret key K, either key EK generated as explained in 964 Section 4.2.1.3.3 (peerA_write_EK), or concatenation of EK and MK 965 keys (peerA_write_EK || peerA_write_MK) 967 - nonce N, either concatenation of implicit nonce part and explicit 968 nonce part received in the message (peerA_write_NI || NE), or, 969 zero-length nonce, 971 - associated data A assembled at the peer B, in this case the 972 sequence number received, 974 - and ciphertext C as received in the message. 976 If the AEAD decryption interface invocation returns plaintext P, the 977 peer accepts the message and updates the receiving sequence number 978 counter value. If the interface invocation returns the FAIL symbol 979 the message must be discarded. The sequence number counter value 980 must not be updated. Such event may be logged at the receiver. 982 The assembly and disassembly of the security services protected 983 message is ECS protocol encapsulation specific. Any encapsulation 984 must clearly specify how application message and security services 985 related information is assembled in the protected message so the 986 message can be unambiguously disassembled at the receiver. If the 987 length of the protected message is explicitly specified in the 988 message, it must be included in associated data A. 990 The procedure of sending the application message at peer B is exactly 991 the same as at peer A. The only difference is that peer B uses its 992 own keying material (peerB_write_EK, peerB_write_MK and 993 peerB_write_NI, see Section 4.2.1.3.3) when sending the message, and 994 peer A uses peer B keying material when receiving the message. 996 Errors on processing the received messages are not fatal to the 997 established ECS protocol between the peers. The application related 998 communication should continue. On excessive number of errors either 999 of the peers may terminate the connection. 1001 The ECS protocol connection, at application data communication 1002 protection level, must terminate if either of two conditions are met: 1003 the anti-replay service counter space is exhausted or, in the case of 1004 deterministic nonce generation, the nonce counter space is exhausted. 1005 The connection between peers may be reestablished, if desired. 1007 4.2.2.6. Security services summary 1009 The algorithms used for security services provisioning are summarized 1010 in the tables below. In Table 1 the encryption key Ke, message 1011 authentication code key MK and nonce implicit part NI length in 1012 octets for each algorithm is presented. These parameters' values are 1013 generated by a pseudorandom generator as defined in Section 4.2.1.3. 1014 In the fifth column the required PRF output length is specified. In 1015 the column six the total length of the PRF output is presented, 1016 according to the hash function specified in Section 4.2.1.3.3 and 1017 needed number of PRF iterations. 1019 |-------------------------------+----+----+----+----------+----------| 1020 | algorithm | EK | NI | MK | PRF req. | PRF gen. | 1021 |-------------------------------+----+----+----+----------+----------| 1022 | AEAD_AES_128_GCM | 16 | 8 | 0 | 48 | 64 | 1023 | AEAD_AES_256_GCM | 32 | 8 | 0 | 80 | 96 | 1024 | AEAD_AES_128_CBC_HMAC_SHA_256 | 16 | 0 | 32 | 96 | 96 | 1025 | AEAD_AES_192_CBC_HMAC_SHA_384 | 24 | 0 | 48 | 144 | 160 | 1026 | AEAD_AES_256_CBC_HMAC_SHA_512 | 32 | 0 | 64 | 192 | 192 | 1027 | AEAD_AES_128_CBC_HMAC_SHA1 | 16 | 0 | 20 | 72 | 96 | 1028 |-------------------------------+----+----+----+----------+----------| 1030 Table 1: Key material length and PRF data required 1032 In Table 2 the application data communication message expansion due 1033 to security services provisioning is presented. The message is 1034 expanded due to inclusion of the nonce explicit part Ne, data origin 1035 authentication and integrity tag T and anti-replay sequence field SQ 1036 in the message. The message may be expanded because of per-algorithm 1037 required padding (Pad.) of the plaintext before encryption. The 1038 padding is reported as a worst case, when the plaintext ends on 16 1039 octets boundary. In this case the entire block of padding needs to 1040 be added which adds 16 octets to the message. On average the padded 1041 length should be 8 octets. The last column reports the maximum 1042 number of octets that may be added to the message. 1044 |-------------------------------+----+------+----+----+------| 1045 | algorithm | NE | Pad. | T | SQ | Max. | 1046 |-------------------------------+----+------+----+----+------| 1047 | AEAD_AES_128_GCM | 4 | 0 | 16 | 4 | 24 | 1048 | AEAD_AES_256_GCM | 4 | 0 | 16 | 4 | 24 | 1049 | AEAD_AES_128_CBC_HMAC_SHA_256 | 16 | 16 | 16 | 4 | 52 | 1050 | AEAD_AES_192_CBC_HMAC_SHA_384 | 16 | 16 | 24 | 4 | 60 | 1051 | AEAD_AES_256_CBC_HMAC_SHA_512 | 16 | 16 | 32 | 4 | 68 | 1052 | AEAD_AES_128_CBC_HMAC_SHA1 | 16 | 16 | 12 | 4 | 48 | 1053 |-------------------------------+----+------+----+----+------| 1055 Table 2: Application data messages expansion 1057 4.3. Error messages 1059 The Enhanced Closed Swarm error messages are sent either due to fatal 1060 failures in the mutual authorization phase of the protocol, messages 1061 3 and 4, see Section 4.1.2, or because access control decisions 1062 during the application data communication as explained in 1063 Section 5.2. For either reasons the error messages should be sent 1064 and the communication between the peers must be aborted. 1066 The error messages and their codes are as follows: 1068 0x00 authorization failed 1069 0x01 issuer unknown 1070 0x02 PoA expired 1071 0x03 service request failed 1073 The "authorization failed" message is sent by either peer A or B if 1074 the peer access control request has failed. The message is sent as 1075 well for other verification failures of the messages 3, 4 and PoA not 1076 specified in this section. 1078 The "issuer unknown" message is sent by either peer A and B if the 1079 peer verifying the other peer credentials cannot find the credential 1080 issuer (Ks) key among trusted keys of the swarm. 1082 The "PoA expired" message is sent by the peer verifying the 1083 requesting peer PoA and the PoA expiry time has been reached. 1085 The "service request failed" is sent if the messages 3 and 4 of the 1086 protocol specify the service request (Rs) and the authorizing peer 1087 access control decision has denied access. In contrast to 1088 authorization failed message (0x00) this message indicates lack of 1089 resources at the peer doing authorization. For example, the 1090 authorizing peer has no slots available for requested service level 1091 at the moment. It is possible that the slot will be available later. 1092 The "service request failed" error message can be raised during 1093 application data communication as well, due to lack of resources. 1095 The error messages should include information (I) that could help the 1096 requesting peer resolving the issues causing the failure. The 1097 implementation may log the raised failures as well the application 1098 data communication protection failures that otherwise must not be 1099 communicated among the peers. 1101 5. Access control 1103 Initial access control decisions are made during the validation of 1104 the ECS protocol message 3 at the receiver and message 4 at the 1105 initiator. First, decisions are made during PoA validation and the 1106 next can be done based on the rules (R) embedded in PoA. 1108 5.1. PoA validation 1110 If the PoA's digital signature verification was successful, as 1111 explained in Section 4, PoA must be validated. At first the SWid of 1112 the swarm is compared to the SWid as exchanged in the first two ECS 1113 messages. If equal, the validation can continue, else, the peer 1114 owing PoA must be rejected. Next, the time validity is evaluated, if 1115 the PoA is expired, the the peer must be rejected. 1117 The ECS protocol doesn't provide any direct mechanisms for revoking 1118 PoAs. Expiry time (ET) in the PoA may be used for this purpose. But 1119 setting very short expiry time may be reasonable in the live 1120 streaming scenario only. In the streaming on demand and conventional 1121 download scenarios expiry time should be set long enough to enable 1122 the peers to upload to the swarm after the download (seeding). 1124 5.2. Rule based access control 1126 If the PoA contains the rule field (R) the next access control step 1127 is validation of the rules. Basic access control elements are a 1128 policy, the environment, and a decision and enforcement function 1129 (DEF) [X812]. Rules represent the policy. The environment is the 1130 environment at each peer, based on which access control decisions can 1131 be made. The DEF compares the environment values with the values in 1132 the rules. If any of the rules fails, the DEF must deny access to 1133 peer's resources in question. 1135 Not all rules can be based on the environment variables derived from 1136 the peer implementation. In such case the requested service field 1137 (RS) in the ECS protocol's third or fourth message can be used to 1138 transmit extra information. If the requested service is present in 1139 the request, the receiver must insert the variable and its value in 1140 its environment for evaluation . 1142 Some of the rules can require not only an evaluation during initial 1143 phase of the ECS protocol, i.e. messages 1-4, but during the entire 1144 session among the peers. Examples are rules related to geolocation, 1145 time of usage, network location, etc., and per-chunk rules as 1146 described in Section 3.1. Such rules should be constantly validated, 1147 based on dynamic peer environment updates. If any of such rules fail 1148 the connection between the peers must be terminated, as explained in 1149 Section 4. 1151 The environment, the rules and the DEF must be aligned for the rule 1152 based access control to succeed. It is meaningless for the 1153 credential issuer to specify a rule that has no counterpart in the 1154 environment and cannot be enforced in the peer implementation. If 1155 the DEF encounters a variable during the evaluation of the rules that 1156 has no counterpart in the environment, the function must return a 1157 negative response resulting in termination of the connection between 1158 the peers participating in the ECS protocol. 1160 6. Initializing an ECS enabled swarm 1162 The ECS enabled swarm should be initialized with the swarm 1163 certificate, specifying the security services parameters. If the 1164 swarm certificate is issued the swarm identifier should be a 1165 cryptographic hash of the swarm certificate. The SHA-256 hash 1166 function must be used. 1168 Peers joining the swarm should obtain the certificate from a trusted 1169 source. Based on parameters in the certificate they should generate 1170 a key pair suitable for the swarm or reuse an existing one. If the 1171 certificate does specify a handshake signature type a corresponding 1172 key pair type must be used. Otherwise the default type must be used, 1173 see Section 4.1.7.2.1. 1175 The swarm owner should generate PoAs for the peers. The PoA must 1176 contain a public key from the peer generated key pair. 1178 6.1. Swarm certificate 1180 The swarm certificate is a digital certificate specifying security 1181 parameters of an ECS-protocol enabled swarm. The following security 1182 parameters may be specified: 1184 - origin: origin of the swarm certificate as an URL, specified in 1185 the same way as the PoA URL in section Section 4.1.7, 1187 - creation date: the time of swarm certificate creation, in the same 1188 format as the expiry time specified in Section 4.1.7, 1190 - ECS protocol version: minimal protocol version needed to join the 1191 swarm, 1193 - swarm key type: the type of the swarm key, specified as in 1194 Section 4.1.7.2.1, 1196 - swarm keys: a comma separated list of swarm keys Ks, all must be 1197 of the type as specified in the swarm key type, 1199 - handshake signature type: the type of the signature in the 1200 handshake messages, the public keys of the users must mach the 1201 type, 1203 - PoA signature type: the type of PoA signature, 1205 - and application data communication protection algorithm: a 1206 selection of data origin authentication, integrity and 1207 confidentiality service algorithm. 1209 The security parameters specification in the ABNF [RFC5234] notation 1210 is as follows: 1212 SP = [ORIGIN] [CREATION_DATE] [ECS_VERSION] [SWARM_KEY_TYPE] 1213 SWARM_KEYS [HANDSHAKE_SIGNATURE_TYPE] [ADCP_ALGORITHM] 1214 ORIGIN = http_URL ; see [RFC2616] 1215 CREATION_DATE = UTCTime ; see [RFC5280] 1216 ECS_VERSION = OCTET 1217 SWARM_KEY_TYPE = OCTET 1218 SWARM_KEYS = key [SWARM_KEYS] 1219 HANDSHAKE_SIGNATURE_TYPE = OCTET 1220 PoA_SIGNATURE_TYPE = OCTET 1221 ADCP_ALGORITHM = OCTET 1222 key = *OCTET ; see Section 4.7.2.1 1224 The swarm certificate is then defined as follows: 1226 [SWid,] SP, {[SWid,] SP}Ks-1 1228 The swarm certificate contains a swarm identifier, security 1229 parameters specification (SP), and digital signature, created with 1230 the private key of the swarm key pair (Ks). If the certificate is 1231 used to name the swarm the swarm identifyer itself must not be 1232 included in the certificate. Instead a content identifier should be 1233 used. If there are multiple keys listed in the specification the 1234 swarm certificate must be verifiable with the first key. 1236 If the swarm certificate is issued it must contain at least one key 1237 in the swarm keys parameter. All the other parameters are optional. 1238 If not present, the defaults are used where applicable. 1240 An example specification of security parameters is shown below, with 1241 the defaults as specified in this document (a swarm key is left out): 1243 ECS_VERSION = 0x01 1244 SWARM_KEY_TYPE = 0x01 1245 SWARM_KEYS = key 1246 HANDSHAKE_SIGNATURE_TYPE = 0x01 1247 PoA_SIGNATURE_TYPE = 0x01 1248 ADCP_ALGORITHM = 0x01 1250 7. Using ECS with PPSPP 1252 The Peer-to-Peer Streaming Peer Protocol (PPSPP) 1253 [I-D.ietf-ppsp-peer-protocol] supports a number of transport 1254 protocols. Preferred transfer protocol is UDP. 1256 7.1. ECS protocol UDP encapsulation 1258 For encapsulation of the ECS protocol in UDP and its usage with PPSPP 1259 the following two general PPSPP message types are defined: 1261 ECS_PROTOCOL = 0x14 (Msg Type 20) 1262 ECS_ENCRYPTED = 0x15 (Msg Type 21) 1264 The first type enables transmission of the ECS protocol messages as 1265 described in Section 4 via PPSPP and the second is used for exchange 1266 of security services protected application communication. In general 1267 most of the ECS protocol messages and fields are of variable length 1268 so every message and field is defined by its type (1 byte) and its 1269 length (2 bytes, length in bytes). The ECS protocol values and 1270 messages as specified are serialized as is defined in PPSPP 1271 specification, Section 8.2. Further examples in the document are 1272 represented in the same hex-like two character-per-byte notation as 1273 in the PPSPP specification. 1275 7.1.1. ECS protocol messages 1277 ECS messages and fields as described in Section 4 are defined with 1278 the following types: 1280 ECS_SWARM_ID = 0x01 1281 ECS_VERSION = 0x02 1282 ECS_NONCE = 0x03 1283 ECS_POA = 0x04 1284 ECS_REQUESTED_SERVICE = 0x05 1285 ECS_SHARED_SECRET = 0x06 1286 ECS_ERROR_INFO = 0x07 1287 ECS_SIGNATURE = 0x08 1289 The following message is an example of initial exchange as discussed 1290 in Section 4.1.1: 1292 14 002C # ECS_PROTOCOL, length 1293 01 0012 # ECS_SWARM_ID, length 1294 123412341234123412341234123412341234 # Swid 1295 02 0001 0001 # ECS_VERSION, length, 1 1296 03 0010 # ECS_NONCE, length 1297 8c9c54b1cbd3de261df2d341a8b7164d # Nonce 1299 7.1.2. Initial PPSPP handshake and ECS exchange 1301 The ECS protocol initial exchange message follows the initial 1302 handshake defined in the PPSPP specification, Section 8.4: 1304 00000000 # CHANNEL, 0 1305 00 00000011 # HANDSHAKE, CHANNEL 1306 v=01 si=.... # HANDSHAKE options 1307 14 0018 # ECS_PROTOCOL, length 1308 02 0001 0001 # ECS_VERSION, length, 1 1309 03 0010 # ECS_NONCE, length 1310 8c9c54b1cbd3de261df2d341a8b7164d # Nonce 1312 The SWid must be present as an option in PPSPP handshake message and 1313 can be avoided in the first ECS protocol exchange message. For other 1314 handshake message options see the PPSPP specification, Section 7. 1316 Peer B's response, initial exchange message 2 as described in 1317 Section 4.1.1, following the initial PPSPP handshake messages can be: 1319 00000011 # CHANNEL, 17 1320 00 00000022 # HANDSHAKE, CHANNEL 1321 v=01 si=.... # HANDSHAKE options 1322 14 0018 # ECS_PROTOCOL, length 1323 02 0001 0001 # ECS_VERSION, length, 1 1324 03 0010 # ECS_NONCE, length 1325 08b3aa180c3f6b948213def673ddcded # Nonce 1327 The PPSPP specification allows additional messages to be sent already 1328 in first exchanged datagrams, see Section 3.1 and 8.4 of the protocol 1329 specification. However, if the ECS protocol is used no additional 1330 PPSPP messages are allowed till message 4 of the ECS protocol, see 1331 Section 7.1.4 for details. 1333 7.1.3. ECS authorization 1335 The message 3 sent by peer A, see Section 4.1.2, is encoded as 1336 follows, including the PoA and digital signature of the message, the 1337 PoA and signature are artificial: 1339 00000022 # CHANNEL, 34 1340 14 0010 # ECS_PROTOCOL, length 1341 04 0004 aef1aef1 # ECS_PoA, length, PoAa 1342 08 0006 # ECS_SIGNATURE, length 1343 0001 abcdabcd # signature type, signature 1345 The message 4 is similar to the message 3. It shows the information 1346 to be signed with peer B's private key: 1348 0s 1349 00000011 |--| 1350 14 000E 04 0002 1234 08 0006 0001 3454123a 1351 |_______________________| 1352 Digitally signed 1354 Digital signature in both messages 3 and 4 covers all the fields in 1355 the ECS message except the signature itself. The length of the 1356 signature is set to all 0's for the signing and then overwritten with 1357 the right length. Conversely, for verification of the signature the 1358 length of the signature has to be overwritten with 0's before 1359 verification. 1361 7.1.4. ECS encrypted message 1363 The ECS encrypted messages contain security services protected 1364 application data messages as defined in Section 4.2. The protected 1365 messages consists of: the ECS_ENCRYPTED field, message length, anti- 1366 replay protection sequence number counter field SQ, the explicit part 1367 of the nonce NE if present, and ciphertext C. The sequence number 1368 counter is always 4 octets long. The length of the explicit part of 1369 the nonce depends on the algorithm selected, see Section 4.2.2.6 for 1370 the security service summary. The rest of the message is ciphertext. 1372 An example of the ECS_ENCRYPTED message is given below, the algorithm 1373 used is the default, AEAD_AES_128_GCM, see Section 4.2.2.1: 1375 15 000C # ECS_ENCRYPTED, length 1376 00000001 # Sequence number SQ 1377 00000001 # Explicit part, nonce NE 1378 23abfe08 # chipertext C 1380 The associated data A of the packet, L denotes the length of the 1381 message, is formed as follows: 1383 A = L || SQ || C 1385 The protected message is created and processed according to 1386 procedures specified in Section 4.2.2.5. All the rest of the 1387 application communication messages are exactly as described in 1388 [I-D.ietf-ppsp-peer-protocol], but embedded in the protected message, 1389 except the channel information: 1391 00000011 # Channel 17 1392 15 000C # ECS_ENCRYPTED, length 1393 ....... # the protected message 1395 When the ECS_ENCRYPTED messages are created the implementations must 1396 take care that the messages fit into the target PPSPP datagram size, 1397 see [I-D.ietf-ppsp-peer-protocol], Section 8.1. The application data 1398 protected by security services may contain multiple PPSPP messages, 1399 as in PPSPP specification, till the specified condition is met. 1401 The ECS protocol message 4 as specified in Section 7.1.3 can be 1402 already followed by some initial light communication data, created as 1403 specified in Section 4.2.2.5 and assembled as ECS_ENCRYPTED message. 1404 If the peer B cannot be authorized by peer A based on content of the 1405 message 4, the peer should avoid decrypting the ECS_ENCRYPTED message 1406 and discard the data. Peer A must deny access and terminate the 1407 connection with error message as explained in Section 4.1.3. 1409 7.1.5. Terminating the connection 1411 The reasons for ECS protocol connection termination and procedures to 1412 follow in such case are described in Section 4.1.3 and 1413 Section 4.2.2.5. The connection can terminate as well for other 1414 reasons as described in PPSPP specification 1415 [I-D.ietf-ppsp-peer-protocol]. After termination the ECS protocol 1416 ephemeral data should be removed. The PPSPP keep alive message 1417 should be respected. The message in UDP case consists of channel id 1418 only and is therefore not encrypted and carries no ECS protocol 1419 related messages. 1421 8. Security Considerations 1423 This document describes the Enhanced Closed Swarm protocol, and 1424 provides guidance on its usage. Many of the security issues are 1425 discussed throughout this document. The protocol reuses a number of 1426 security mechanisms and algorithms specified in the referenced 1427 documents. These documents' security considerations are important 1428 for the ECS protocol security. Documents to be considered are the 1429 AEAD interface specification [RFC5116], partly the TLS appendix F.4 1430 on Security of Composite Cipher Modes [RFC5246] and the note on 1431 nonces and keys in IKEv2 specification [RFC4306]. For the usage of 1432 the ECS protocol with the PPSPP protocol the security considerations 1433 as described in [I-D.ietf-ppsp-peer-protocol], specifically in 1434 Section 13.1, must also be considered. 1436 In general the Enhanced Closed Swarm protocol protects both 1437 authorized peer resources and content in distribution. The content 1438 itself is not protected after being obtained by the peers and could 1439 be potentially distributed to unauthorized entities by other means. 1440 For content protection outside the distribution appropriate Digital 1441 Rights Management solutions should be used beside the ECS protocol, 1442 if needed. Authorized clients using maliciously modified 1443 implementation could leak the content to unauthorized peers already 1444 during the distribution. But such leak doesn't affect other 1445 authorized clients resources usage and could be potentially prevented 1446 by detecting the malicious clients or peers and preventing them to 1447 obtain the authorizations in the future. 1449 A basic ECS defense against denial-of-service attacks is related to 1450 the four message handshake as described in Section 4.1. The 1451 handshake shifts the first cryptographic calculation from responder, 1452 peer B, to initiator, peer A. The defense puts the peers on equal 1453 footing if the peer A really signs the third ECS protocol message and 1454 if the peer A's computational power is comparable to the peer B's. 1455 If the peer A can initiate many ECS connections to peer B and uses 1456 precomputed third response messages, peer B's computing resources 1457 could be jeopardized. To counter such and attack the peer B should 1458 keep a small state across multiple ECS instances to detect the attack 1459 and block the peer if needed. 1461 A possibility to include PoA information in the third and fourth ECS 1462 protocol message as a URL can present a security threat if the 1463 feature is misused in some potential scenarios. For example, a swarm 1464 initiator, responsible for generating PoAs for the interested peers 1465 can return a URL to the peer PoA instead of the PoA itself. If the 1466 URL points to a third party or it is maliciously crafted its usage 1467 can amplify in the swarm and can result in denial-of-service attack. 1468 The peers should validate the URLs, and obtain and validate PoAs 1469 before using URLs as references to them in the swarm. The URLs of 1470 the PoAs should be limited to the same origin as the PoAs were 1471 obtained from or from an origin the user can trust. The swarm 1472 initiators should avoid specifying large PoAs that might need to be 1473 specified as a URL and cannot be included in the protocol messages 1474 directly. 1476 9. Rationale 1478 The ECS protocol provides access control mechanisms in distributed 1479 peer-to-peer systems. The aim of the protocol is to protect peer 1480 resources and the communication channels between them against 1481 unauthorized usage. The main motivation for the protocol are lack of 1482 an open specification of the protocol functionality, and a number of 1483 use cases anticipated by service and content providers but which 1484 cannot be implement with current peer-to-peer systems. 1486 The ECS protocol provides a number of security services and 1487 mechanisms sufficient for a swarm initiator to initiate a closed 1488 swarm, provide interested peers authorization credentials (PoA) to 1489 access the swarm, enable mutual peer authentication and authorization 1490 and security protect an application communication. 1492 Unlike common Digital Rights Management systems the ECS protocol does 1493 not address the issues of protecting or limiting the access to 1494 content directly. The content itself is distributed as is, without 1495 any modifications or mechanisms that could restrict its usage after 1496 the content has been obtained. If needed, one could use additional 1497 security mechanisms and services to provide the DRM functionality 1498 along with the ECS protocol, but such mechanisms and services or 1499 interoperability with the protocol are beyond the scope of this 1500 document. 1502 The protocol is designed as simple as possible while offering enough 1503 flexibility to enable a number of usage scenarios. The protocol is 1504 swarm oriented and a swarm initiator can choose per swarm protocol 1505 security parameters and authorization rules according to its own 1506 needs. No prior relationship or common authorities are needed 1507 between interested peers and the initiator, except that every peer 1508 needs to provide the issuer a public key to join the swarm in name of 1509 which new PoA credentials can be issued. For every closed swarm the 1510 peer can use a different key pair. The protocol is designed to be 1511 used with connection and connectionless protocols like UDP and TCP 1512 and fulfilling requirements they impose. 1514 A number of security protocols related to the ECS protocol has been 1515 already specified in IETF, most notably IPsec, TLS and DTLS. For a 1516 number of reasons IPsec is not suitable for all applications 1517 [RFC5406]. The TLS protocol is suitable only for connection oriented 1518 protocols (TCP), while DTLS, as TLS modification, is suitable for 1519 datagram oriented transport (UDP). Both protocols secure data 1520 communication between applications, a client and a server. In 1521 contrast to peer-to-peer systems, in application domain TLS/DTLS are 1522 designed for, the server is a scarce resource and the clients obtain 1523 and manage the connection to the server accordingly. In peer-to-peer 1524 systems the distribution of 'client' and 'servers' is assumed to be 1525 more even. The ECS protocol simplifies obtaining, providing and 1526 managing the secure connection between peers. The protocol handshake 1527 assumes no connection or retransmission of the messages. The 1528 handshake either succeeds or not. All protocol messages must fit 1529 into a single encapsulating protocol datagram. The protocol doesn't 1530 support rekeying. If the conditions for rekeying are met the 1531 protocol instance must be restarted, if needed, and no previous 1532 instance state is kept. The choice of mandatory supported security 1533 algorithms is limited to small but reasonable set. The protocol 1534 supports only one way to provide application data communication 1535 protection via the AEAD interface. The protocol doesn't support any 1536 security parameters negotiation between peers in communication. A 1537 swarm certificate is a single interface to specify swarm security 1538 parameters, controlled solely by a swarm initiator. 1540 One of the major advantages of existing IETF security protocols is 1541 their maturity. The ECS protocol has reused existing and validated 1542 solutions from TLS/DTLS, IPsec and IKEv2 wherever possible. 1544 10. Acknowledgments 1546 The Closed Swarm protocol was initially designed by Njaal Borch et al 1547 [CS] in the P2P-Next project (http://www.p2p-next.org/), a research 1548 project supported by the European Community under its 7th Framework 1549 Programme (grant agreement no. 216217). The protocol was further 1550 extended by Vladimir Jovanovikj et al into the Enhanced Closed Swarm 1551 protocol [ECS]. Their work was partly supported by the P2P-Next 1552 project and Slovenian Research Agency. The views and conclusions 1553 contained herein are those of the author and should not be 1554 interpreted as necessarily representing the official policies or 1555 endorsements, either expressed or implied, of the P2P-Next project, 1556 the European Commission or Slovenian Research Agency. 1558 Many reviewers provided valuable comments on earlier drafts of this 1559 document. 1561 11. References 1563 11.1. Normative References 1565 [FIPS180-3] 1566 National Institute of Standards and Technology (NIST), 1567 "Secure Hash Standard", FIPS Publication 180-3, 1568 October 2008. 1570 [FIPS186-3] 1571 National Institute of Standards and Technology (NIST), 1572 "Digital Signature Standard", FIPS Publication 186-3, 1573 November 2008. 1575 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1576 Hashing for Message Authentication", RFC 2104, 1577 February 1997. 1579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1580 Requirement Levels", BCP 14, RFC 2119, March 1997. 1582 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1583 Encryption", RFC 5116, January 2008. 1585 11.2. Informative References 1587 [AEAD-AES-CBC] 1588 McGrew, D. and K. Patterson, "Authenticated Encryption 1589 with AES-CBC and HMAC-SHA", draft mcgrew-aead-aes-cbc- 1590 hmac-sha2-01, October 2012. 1592 [CS] Borch, N., Michell, K., Artzen, I., and D. Gabrijelcic, 1593 "Access control to BitTorrent swarms using closed swarms", 1594 Proceedings of the 2010 ACM workshop on Advanced video 1595 streaming techniques for peer-to-peer networks and social 1596 networking AVSTP2P '10, 2010. 1598 [ECS] Jovanoviky, V., Gabrijelcic, D., Klobucar, T., and D. 1599 Gabrijelcic, "Access control in BitTottent P2P networks 1600 using the enhanced Closed Swarms protocol", Proceedings of 1601 the Fifth International Conference on Emerging Security 1602 Information, Systems and Technologies SECURWARE 2011, 1603 2011. 1605 [HAC] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook 1606 of Applied Criptography", 1997. 1608 [I-D.ietf-ppsp-peer-protocol] 1609 Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to- 1610 Peer Streaming Peer Protocol (PPSPP)", 1611 draft-ietf-ppsp-peer-protocol-06 (work in progress), 1612 February 2013. 1614 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1615 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1616 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1618 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1619 Resource Identifier (URI): Generic Syntax", STD 66, 1620 RFC 3986, January 2005. 1622 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1623 December 2005. 1625 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1626 RFC 4306, December 2005. 1628 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 1629 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 1630 RFC 4754, January 2007. 1632 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1633 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 1635 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1636 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1638 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1639 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1641 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1642 Housley, R., and W. Polk, "Internet X.509 Public Key 1643 Infrastructure Certificate and Certificate Revocation List 1644 (CRL) Profile", RFC 5280, May 2008. 1646 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 1647 Version 2", BCP 146, RFC 5406, February 2009. 1649 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 1650 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 1651 June 2010. 1653 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1654 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1655 RFC 5996, September 2010. 1657 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1658 Curve Cryptography Algorithms", RFC 6090, February 2011. 1660 [RSA] Rivest, R., Shamir, A., and L. Adelman, "A Method for 1661 Obtaining Digital Signatures and Public-Key 1662 Cryptosystems", Communications of the ACM, v. 21, n. 2, 1663 pp. 120-126. , February 1978. 1665 [SEC] Standards for Efficient Cryptography Group, "Recommended 1666 Elliptic Curve Domain Parameters", SEC 2, September 2000. 1668 [SEC1] Standards for Efficient Cryptography Group, "Elliptic 1669 Curve Cryptography", SEC 1-v2, May 2009. 1671 [SP800-38D] 1672 National Institute of Standards and Technology (NIST), 1673 "Recommendation for Block Cipher Modes of Operation: 1674 Galois/Counter Mode (GCM) and GMAC", NIST Special 1675 Publication 800-38D, November 2007. 1677 [SP800-57-3] 1678 National Institute of Standards and Technology (NIST), 1679 "RECOMMENDATION FOR KEY MANAGEMENT, Part 3: Application- 1680 Specific Key Management Guidance", NIST Special 1681 Publication 800-57, December 2009. 1683 [SP800-90A] 1684 National Institute of Standards and Technology (NIST), 1685 "Recommendation for Random Number Generation Using 1686 Deterministic Random Bit Generators", NIST Special 1687 Publication 800-90A, January 2012. 1689 [X812] International Telecommunication Union - Telecommunication 1690 Standardization Sector (ITU-T), "Data networks, open 1691 system communications and security, Information technology 1692 - Open systems interconnection - Security frameworks for 1693 open systems: Access control framework", ITU-T 1694 Recomendation X.812, 1994. 1696 Appendix A. Revision history 1698 -00 Initial version 1700 -01 Minor revision 1702 + Updates the ECS protocol UDP encapusulation, Section 7.1, 1703 according to the PPSPP protocol draft version -06 1705 + Additional small clarifications in the same encapsulation 1706 section 1708 Author's Address 1710 Dusan Gabrijelcic 1711 Jozef Stefan Institute 1712 Jamova 39 1713 Ljubljana, 1000 1714 Slovenia 1716 Email: dusan@e5.ijs.si