idnits 2.17.1 draft-seitz-core-security-modes-00.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3832 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) == Unused Reference: 'TLS-Certificate-Types-Registry' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lwig-terminology' is defined on line 566, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-tls-oob-pubkey-10 -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS-Certificate-Types-Registry' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-07) exists of draft-ietf-lwig-terminology-05 -- Obsolete informational reference (is this intentional?): RFC 4305 (ref. 'RFC2402') (Obsoleted by RFC 4835) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group L. Seitz 3 Internet-Draft SICS Swedish ICT 4 Intended Status: Standards Track G. Selander 5 Expires: April 24, 2014 Ericsson 7 October 21, 2013 9 Additional Security Modes for CoAP 10 draft-seitz-core-security-modes-00 12 Abstract 14 The CoAP draft defines how to use DTLS as security mechanism. In 15 order to establish which nodes are trusted to initiate a DTLS session 16 with a device, the following security modes are defined: NoSec, 17 PreSharedKey, RawPublicKey, and Certificate. These modes require 18 either to provision a list of keys of trusted clients, or to handle 19 heavyweight certificates. This memo proposes two intermediate 20 security modes involving a trusted third party that are very similar 21 to PreSharedKey and RawPublicKey respectively, but which do not 22 require out-of-band provisioning of client keys to the device. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress". 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. DerivedKey Mode . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1 Generating The Nonce . . . . . . . . . . . . . . . . . . . . 5 65 2.2 Calculating The Derived Key . . . . . . . . . . . . . . . . 5 66 2.3 Generating PSK_IDENTITY . . . . . . . . . . . . . . . . . . 6 67 2.4 Key Expiration, Anti-replay, And Revocation . . . . . . . . 6 68 3. AuthorizedPublicKey Mode . . . . . . . . . . . . . . . . . . . 8 69 3.1 Structure of the Authorization Certificate Extension . . . . 9 70 3.2 Client and Server Handshake Behavior . . . . . . . . . . . . 10 71 3.3 Payload Verification Procedure . . . . . . . . . . . . . . . 10 72 3.4 Key Expiration, Anti-replay, And Revocation . . . . . . . . 11 73 4. Access Control Lists . . . . . . . . . . . . . . . . . . . . . 11 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 8.1 Normative References . . . . . . . . . . . . . . . . . . . 13 79 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a 85 light-weight web transfer protocol suitable for applications in 86 embedded devices used in services such as smart energy, smart home, 87 building automation, remote patient monitoring etc. Due to the 88 nature of the these use cases including critical, unattended 89 infrastructure and the personal sphere, security and privacy are 90 critical components. 92 CoAP message exchanges can be protected with different security 93 protocols. The CoAP specification defines a DTLS [RFC6347] binding 94 for CoAP, which provides communication security including 95 authentication, encryption, integrity, and replay protection. In 96 order to bootstrap trust relations, the CoAP specification defines 97 four security modes that are the result of different provisioning 98 procedures (see section 9 of [I-D.ietf-core-coap]): 100 o NoSec 101 o PreSharedKey (PSK) 102 o RawPublicKey (RPK) 103 o Certificate 105 The NoSec alternative assumes security measures at another protocol 106 layer and provides no security at all. PSK and RPK modes rely on a 107 pre-provisioned list of keys that the device can initiate a DTLS 108 session with. Certificate mode requires provisioning of certain root 109 trust anchor public keys (equivalent to CA certificates) that can be 110 used to validate previously unknown X.509 certificates, before using 111 them to establish a DTLS session. 113 Given a setting where security is required, and where at least some 114 devices are too resource constrained to handle X.509 certificates, 115 devices would have to use either the PSK or the RPK mode. If the set 116 of nodes that a device would communicate with varies dynamically 117 (e.g. a pay-per-use scenario) this would in turn require constant re- 118 provisioning of lists of trusted clients to the individual devices. 120 Such an approach will obviously not scale well and make consistent 121 management of security policies over a set of devices very difficult. 122 Therefore we propose two additional security modes that take 123 advantage of the low resource consumption of the PSK and the RPK 124 modes, but also allow to manage dynamic trust relations without 125 having to re-provision the individual nodes. The basic idea is to 126 provision a symmetric key of a trust anchor to the devices. A node 127 wishing to connect to the device can obtain either a derived secret 128 key, or a Message Authentication Code (MAC) of its public key from 129 one of the trust anchors, and the device can verify that this derived 130 secret key, or MAC is generated by a trust anchor. The derived key or 131 public key is then used by the device as in PSK or RPK mode, 132 respectively. 134 1.1 Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in RFC 139 2119 [RFC2119]. 141 Certain security-related terms are to be understood in the sense 142 defined in [RFC4949]. These terms include, but are not limited to, 143 "authentication", "authorization", "confidentiality", "encryption", 144 "data integrity", "message authentication code", and "verify". 146 Terminology for constrained environments is defined in [I-D.ietf- 147 lwig-terminology] e.g. "constrained device". 149 Furthermore this memo refers to the following entities: 151 o The constrained device providing resources is called the 152 Resource Server (RS) 153 o The node connecting to the Resource Server in order to request 154 some resource is called Client (C) 155 o The entity having an a-priori trust relation with RS is called 156 the Trust Anchor (TA) 158 2. DerivedKey Mode 160 This mode addresses similar use cases as the PSK mode, but without 161 the requirement for out-of-band provisioning of shared keys between C 162 and RS. Instead each resource server is configured with secret, 163 symmetric keys shared with its trust anchors. For simplicity of 164 explanation we assume here, that each RS only has a single TA, and 165 that they share the key K_RS-TA. A client wishing to establish a 166 connection to a RS needs to obtain a symmetric key K_RS-C and a nonce 167 from the TA, where K_RS-C is derived from K_RS-TA and that nonce. C 168 transmits the nonce in the psk_identity field of the 169 ClientKeyExchange message of the DTLS protocol. The RS then derives 170 K_RS-C from the nonce and K_RS-TA, and then both proceed using K_RS-C 171 as a pre-shared key [RFC4279]. Figure 1 illustrates this procedure. 173 Client Trust Anchor Resource Server 174 | 1. Request key | | 175 |--------------------->| | 176 | | 2. Process | 177 | | authorization | 178 | 3. K_RS-C + nonce | | 179 |<---------------------| | 180 | + | 181 | | 182 | 4. DTLS handshake using PSK = K_RS-C | 183 |<---------------------------------------->| 184 | and psk_identity = nonce | 186 Figure 1: The message flow for DerivedKey mode 188 How C authenticates with the TA, and how the TA authorizes the 189 request for a key K_RS-C is out of scope for this memo. 191 2.1 Generating The Nonce 193 Upon request, the trust anchor verifies if C is authorized to connect 194 to the resource server. How this is done is out of scope for this 195 memo. If the verification succeeds, the TA generates the nonce as 196 follows: 198 nonce = 'DK.' + TA_id + '.' C_id + '.' + sequence_number 200 where '+' indicates concatenation, 201 'TA_id' is an identifier that the RS can use to select the 202 correct K_RS-TA, 203 'C_id' is an identifier of C, and 204 'sequence_number' is a sequence number maintained by the RS and 205 the TA. 207 The TA then generates the shared key K_RS-C as described in section 208 2.2 and transfers the nonce and K_RS-C to C via a secure channel. 210 2.2 Calculating The Derived Key 212 K_RS-C is derived from K_RS-TA by the trust anchor and the resource 213 server through a data expansion step, as defined in [RFC5246]: 215 P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + 216 HMAC_hash(secret, A(2) + seed) + 217 HMAC_hash(secret, A(3) + seed) + ... 219 where '+' indicates concatenation and A() is defined as: 221 A(0) = seed 222 A(i) = HMAC_hash(secret, A(i-1)) 224 In the present case: 226 o hash is SHA-256, 227 o 'secret' is the shared key K_RS-TA, and 228 o 'seed' is the nonce. 230 The nonce, associated to the connection request, is generated by the 231 trust anchor (see 2.1). A nonce SHALL NOT be reused with the same 232 shared key K_RS-TA. 234 With one iteration of the P_SHA256, the output data D of 256 bits can 235 be used to define K_RS-C either as one 256 bit key, or as one 128 bit 236 key using the first 128 bits of D and discarding the rest. 238 2.3 Generating PSK_IDENTITY 240 The nonce is used as the psk_identity field of the DTLS 241 ClientKeyExchange message. Upon receiving a psk_identity in the 242 ClientKeyExchange message, an RS can determine by the 'DK' prefix 243 that C wants to use the DerivedKey security mode, and select the 244 corresponding key K_RS-TA by using the nonce in order to calculate 245 the key K_RS-C as specified in 2.2. 247 2.4 Key Expiration, Anti-replay, And Revocation 249 The key K_RS-C enables the client to open a DTLS connection to the 250 resource server, but in many cases one does not want this key to be 251 valid forever. Furthermore an attacker can reuse a stolen key to gain 252 access to the RS. Therefore the sequence_number part of the nonce 253 can be used to expire the key K_RS-C (i.e. make it invalid for 254 setting up new DTLS sessions) and protect against reuse of a {key, 255 nonce} pair in a DTLS handshake. 257 The sequence number is a 32-bit number that is specific to a TA and 258 an RS. 260 The TA keeps a list of sequence numbers per RS it is responsible for. 261 A RS's sequence number is incremented by 1 for each new shared key 262 K_RS-C generated for this RS. 264 For each TA an RS has (typically only one), it keeps a window of most 265 recently verified sequence numbers. Sequence number verification 266 SHOULD be performed using the following sliding window procedure, 267 borrowed from Section 3.4.3 of [RFC2402] (see also [RFC6347] section 268 4.1.2.6). 270 The sequence number MUST be initialized to zero when an association 271 between a TA and an RS is established. For each received DTLS 272 handshake using the DerivedKey Mode, the RS MUST verify that the 273 nonce contains a fresh sequence number. This SHOULD be the first 274 check applied to a nonce after it has been received in the 275 ClientKeyExchange message, to speed rejection of duplicate or old 276 records. 278 Freshness is checked through the use of a sliding receive window. 279 (How the window is implemented is a local matter, but the following 280 text describes the functionality that the implementation must 281 exhibit.) A minimum window size of 32 MUST be supported, but a 282 window size of 64 is preferred and SHOULD be employed as the default. 283 Another window size (larger than the minimum) MAY be chosen by the 284 RS. 286 The "right" edge of the window represents the highest validated 287 Sequence Number value received on this RS. DTLS handshakes, using 288 this security mode, that contain Sequence Numbers lower than the 289 "left" edge of the window are rejected. Handshakes falling within 290 the window are checked against a list of received handshakes with 291 sequence numbers within the window. An efficient means for 292 performing this check, based on the use of a bit mask, is described 293 in Appendix C of [RFC2401]. 295 If the sequence number falls within the window and is new, or if the 296 sequence number is to the right of the window the RS proceeds to 297 generate the shared key K_RS-C. If the handshake succeeds the RS 298 updates the window. 300 On some occasions one may want to explicitly revoke a key K_RS-C 301 before its expiration. In these cases the trust anchor has to send a 302 message to the RS specifying the sequence number of the key K_RS-C it 303 wants to revoke. The RS can then update the receive window to mark 304 this key as used. 306 If a server is in use for a long period of time and able to process 307 DTLS handshakes rapidly, the sequence number range may get exhausted 308 within the lifetime of the server. In that case a new shared key 309 K_RS-TA must be provisioned to the server and the TA, and the 310 sequence number counters must be reset. 312 Note: If we make the very optimistic assumption that a DTLS handshake 313 takes very roughly 1 second for a constrained device, a 32-bit 314 sequence number can last roughly 136 years, before it needs to be 315 reset (60*60*24*365 = max 31,536,000 handshakes per year, 316 2^32/31,536,000 > 136). 318 3. AuthorizedPublicKey Mode 320 This security mode addresses similar use cases as the RPK mode, but 321 without the need for out-of-band validation of public keys. As in 322 the DerivedKey mode, we assume that the resource servers are 323 configured with a symmetric key K_RS-TA for each of their trust 324 anchors. In order to run this mode, the client needs to get its 325 public key authorized for DTLS with the RS by one of the TA. The TA 326 does this by creating an authorization certificate protected by a 327 message authentication code (MAC) using the key K_RS-TA. The TA also 328 provides C with the public key of RS for use in DTLS. The client 329 then performs the DTLS handshake in RPK mode, but replaces the 330 RawPublicKey ClientCertificate with the authorization certificate. 331 The RS verifies the certificate, and if it is valid, proceeds with 332 the DTLS handshake as if the client public key had been provisioned 333 out of band. Furthermore the RS sends an empty certificate_list in 334 the ServerCertificate message, since the key has already been 335 provided to C by the TA. 337 The authorization certificate is essentially the RawPublicKey 338 certificate of [I-D.ietf-tls-oob-pubkey] with an additional MAC. As 339 with the RPK mode, this security mode benefits from a significantly 340 smaller size of the client's Certificate message in the DTLS 341 handshake. The verification of a MAC is also less resource consuming 342 than verifying a digital signature. A considerable reduction in 343 message size compared with the RPK mode, is that the RS does not have 344 to send any certificate. 346 Figure 2 illustrates the message flow of this mode. 348 Client Trust Anchor Resource Server 349 | 1. Req. authz cert for | | 350 |----------------------->| | 351 | public key PubK_C | 2. Process | 352 | | authorization | 353 | 3. authz cert + | | 354 |<-----------------------| | 355 | public key PubK_RS + | 356 | | 357 | 4. DTLS handshake using authz cert | 358 |<------------------------------------------>| 359 | | 361 Figure 2: The message flow for AuthorizedPublicKey mode 363 How C authenticates with the TA, and how the TA authorizes the 364 request for an authorization certificate out of scope for this memo. 366 3.1 Structure of the Authorization Certificate Extension 368 This section outlines the changes to the DTLS handshake message 369 contents for the AuthorizedPublicKey mode. The procedure is analogous 370 to the one in [I-D.ietf-tls-oob-pubkey], using the new 371 certificate_type 'AuthzCert' and the new structure 'MacCert'. 373 struct { 374 select(certificate_type) { 375 // certificate type defined in this document 376 case AuthzCert: 377 MacCert certificate; 379 // certificate type defined in [I-D.ietf-tls-oob-pubkey] 380 case RawPublicKey: 381 opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; 383 // X.509 certificate defined in RFC 5246 384 case X.509: 385 ASN.1Cert certificate_list<0..2^24-1>; 387 // Additional certificate type based on TLS 388 // Certificate Type Registry 389 }; 390 } Certificate; 392 The MacCert structure is defined as follows: 394 struct { 395 opaque ASN.1_subjectPublicKeyInfo<1..2^24-1> 396 opaque trust_anchor_id; 397 uint32 sequence_number; 398 MACAlgorithm mac_algorithm; 399 uint8 mac_length; 400 opaque MAC[mac_length]; 401 } MacCert; 403 Where ASN.1_subjectPublicKeyInfo is defined in section 3 of [I- 404 D.ietf-tls-oob-pubkey], and the MACAlgorithm type is defined in 405 [RFC5246]. The 'mac_algorithm' parameter specifies a function MAC = 406 M(key, message), where K_RS-TA is used as the key, and the 407 certificate with an empty MAC value as the message. 409 Note that the size of the MacCert structure is only marginally larger 410 than the RawPublicKey certificate used in RPK mode. 412 The extended client_hello and extended server_hello defined in 413 section 3 of [I-D.ietf-tls-oob-pubkey] are also used here, with the 414 new certificate_type 'AuthzCert'. 416 3.2 Client and Server Handshake Behavior 418 Section 4 of [I-D.ietf-tls-oob-pubkey] shows the use of the client 419 and server certificate types in TLS. The AuthorizedPublicKey mode 420 uses a variant of the handshake exemplified in section 5.3 of [I- 421 D.ietf-tls-oob-pubkey] as illustrated by figure 4. 423 client_hello, 424 client_certificate_type=(AuthzCert) //(1) 425 -> 426 <- server_hello, 427 server_certificate_type=(X.509) //(2) 428 certificate, //(3) 429 client_certificate_type=(AuthzCert) //(4) 430 certificate_request, //(5) 431 server_key_exchange, 432 server_hello_done 433 certificate, // (6) 434 client_key_exchange, 435 change_cipher_spec, 436 finished -> 437 <- change_cipher_spec, 438 finished 440 Application Data <-------> Application Data 442 Figure 4: Example of a DTLS handshake with Authorization 443 Certificate provided by the Client 445 This handshake starts with the client indicating its ability to use 446 AuthorizedPublicKey mode (1). Since the client has already received 447 the server's public key from the TA, the server sends an empty 448 certificate_list in the certificate message (3), using the indication 449 for X.509 certificates in (2). This indication is only used, because 450 it allows to send an empty certificate_list. For client 451 authentication the server indicates in (4) that it selected the 452 AuthorizedPublicKey mode and requests a certificate from the client 453 in (5). The client provides a MacCert structure (6) after receiving 454 and processing the server hello message. 456 3.3 Payload Verification Procedure 458 After negotiating client_certificate_type="AuthzCert" in the 459 ClientHello/ServerHello steps of the DTLS protocol, and receiving the 460 ClientCertificate message, the RS proceeds to verify the C's public 461 key using the following steps: 463 o Check if the trust_anchor_id identifies a trust anchor 464 o Check if the sequence_number is valid 465 o Check that the ASN.1_subjectPublicKeyInfo contains a valid 466 SubjectPublicKeyInfo structure 467 o Check the mac with the shared key K_RS-TA. 469 If any of these checks fail, the DTLS handshake is aborted and the RS 470 MUST send a bad_certificate alert. 472 3.4 Key Expiration, Anti-replay, And Revocation 474 The rationale and procedures for handling sequence numbers are the 475 same as described in section 2.4. 477 4. Access Control Lists 479 The CoAP specification uses Access Control Lists to keep track of 480 pre-shared symmetric keys, raw public keys, and root trust anchors 481 for X.509 certificates, used in the corresponding security modes (see 482 section 9 and especially 9.1.3.2.1 of [I-D.ietf-core-coap]). An 483 implementation supporting one or both of the security modes specified 484 above MUST be extended to support storing lists of identifiers and 485 secret keys of the trust anchors. 487 5. Security Considerations 489 All security consideration from [RFC6347] and [RFC4279] also apply to 490 this approach. Furthermore the trust anchors used for authorizing the 491 use of keys in the two proposed security modes are valuable targets 492 for attacks since they potentially allow access to many devices. They 493 should be protected accordingly. 495 The nonce used to generate the shared key for the DK mode is static 496 except for the sequence number, an attacker could exploit this for a 497 dictionary attack. If such an attack is considered feasible, an 498 additional random seed should be added to the nonce to increase the 499 variable part. The client identifier and other information in the 500 nonce cannot be trusted until the client is authenticated using the 501 key derived from the nonce. 503 The sequence number mechanism for expiration can potentially lead to 504 keys being valid for a longer time than expected. This will be the 505 case if the number of requests for a device drops significantly, and 506 it therefore takes longer to fill the sliding window. Trust anchors 507 can monitor this and explicitly revoke keys if the frequency of 508 requests drops significantly. It is also possible to use timers in 509 the device to implement complementing expiry mechanisms. 511 An attacker can induce a server to perform the DTLS handshake up to 512 Flight 4, without having any legitimate key material from a trust 513 anchor. This could be used for denial of service attacks against the 514 server. However these problems are also present with any of the 515 standard CoAP security modes and respective DTLS handshakes. 517 6. IANA Considerations 519 IANA is asked to register a new value in the "TLS Certificate Types" 520 registry of Transport Layer Security (TLS) Extensions [TLS- 521 Certificate-Types-Registry], as follows: 523 Value: 3 Description: Authorized Public Key Certificate 524 (AuthzCert) Reference: [[THIS RFC]] 526 7. Acknowledgements 528 The authors would like to thank Stefanie Gerdes, Mats Naeslund, and 529 John Mattsson for contributions and helpful comments. 531 8. References 533 8.1 Normative References 535 [I-D.ietf-core-coap] 536 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 537 "Constrained Application Protocol (CoAP)", draft-ietf- 538 core-coap-18 (work in progress), June 2013. 540 [I-D.ietf-tls-oob-pubkey] 541 Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 542 T. Kivinen, "Out-of-Band Public Key Validation for 543 Transport Layer Security (TLS)", draft-ietf-tls-oob- 544 pubkey-10 (work in progress), October 2013. 546 [TLS-Certificate-Types-Registry] 547 "TLS Certificate Types Registry", February 2013, 548 . 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, March 1997. 554 [RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key 555 Ciphersuites for Transport Layer Security (TLS)", 556 RFC 4279, December 2005. 558 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 559 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 561 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 562 Security Version 1.2", RFC 6347, January 2012. 564 8.2 Informative References 566 [I-D.ietf-lwig-terminology] 567 Bormann, C., Ersue, M., and Keranen, A., "Terminology for 568 Constrained Node Networks", draft-ietf-lwig-terminology-05 569 (work in progress), July 2013. 571 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 572 Internet Protocol", RFC 2401, November 1998. Obsoleted by 573 RFC4301. 575 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 576 RFC 2402, November 1998. Obsoleted by RFC4302, RFC4305. 578 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 579 36, RFC 4949, August 2007. 581 Authors' Addresses 583 Ludwig Seitz 584 SICS Swedish ICT AB 585 Scheelevagen 17 586 22370 Lund 587 SWEDEN 588 EMail: ludwig@sics.se 590 Goeran Selander 591 Ericsson 592 Farogatan 6 593 16480 Kista 594 SWEDEN 595 EMail: goran.selander@ericsson.com