< draft-ietf-dice-profile-11.txt   draft-ietf-dice-profile-12.txt >
dice H. Tschofenig, Ed. dice H. Tschofenig, Ed.
Internet-Draft ARM Ltd. Internet-Draft ARM Ltd.
Intended status: Standards Track T. Fossati Intended status: Standards Track T. Fossati
Expires: November 28, 2015 Alcatel-Lucent Expires: November 29, 2015 Alcatel-Lucent
May 27, 2015 May 28, 2015
A TLS/DTLS Profile for the Internet of Things A TLS/DTLS Profile for the Internet of Things
draft-ietf-dice-profile-11.txt draft-ietf-dice-profile-12.txt
Abstract Abstract
A common design pattern in Internet of Things (IoT) deployments is A common design pattern in Internet of Things (IoT) deployments is
the use of a constrained device that collects data via sensor or the use of a constrained device that collects data via sensor or
controls actuators for use in home automation, industrial control controls actuators for use in home automation, industrial control
systems, smart cities and other IoT deployments. systems, smart cities and other IoT deployments.
This document defines a Transport Layer Security (TLS) and Datagram This document defines a Transport Layer Security (TLS) and Datagram
TLS (DTLS) 1.2 profile that offers communications security for this TLS (DTLS) 1.2 profile that offers communications security for this
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 28, 2015. This Internet-Draft will expire on November 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 25 skipping to change at page 5, line 25
familiar with DTLS the differences are: familiar with DTLS the differences are:
o An explicit sequence number and an epoch field is included in the o An explicit sequence number and an epoch field is included in the
Record Protocol. Section 4.1 of RFC 6347 explains the processing Record Protocol. Section 4.1 of RFC 6347 explains the processing
rules for these two new fields. The value used to compute the MAC rules for these two new fields. The value used to compute the MAC
is the 64-bit value formed by concatenating the epoch and the is the 64-bit value formed by concatenating the epoch and the
sequence number. sequence number.
o Stream ciphers must not be used with DTLS. The only stream cipher o Stream ciphers must not be used with DTLS. The only stream cipher
defined for TLS 1.2 is RC4 and due to cryptographic weaknesses it defined for TLS 1.2 is RC4 and due to cryptographic weaknesses it
is not recommended anymore even for use with TLS is not recommended anymore even for use with TLS [RFC7465]. Note
[I-D.ietf-tls-prohibiting-rc4]. Note that the term 'stream that the term 'stream cipher' is a technical term in the TLS
cipher' is a technical term in the TLS specification. Section 4.7 specification. Section 4.7 of RFC 5246 defines stream ciphers in
of RFC 5246 defines stream ciphers in TLS as follows: in stream TLS as follows: in stream cipher encryption, the plaintext is
cipher encryption, the plaintext is exclusive-ORed with an exclusive-ORed with an identical amount of output generated from a
identical amount of output generated from a cryptographically cryptographically secure keyed pseudorandom number generator.
secure keyed pseudorandom number generator.
o The TLS Handshake Protocol has been enhanced to include a o The TLS Handshake Protocol has been enhanced to include a
stateless cookie exchange for Denial of Service (DoS) resistance. stateless cookie exchange for Denial of Service (DoS) resistance.
For this purpose a new handshake message, the HelloVerifyRequest, For this purpose a new handshake message, the HelloVerifyRequest,
was added to DTLS. This handshake message is sent by the server was added to DTLS. This handshake message is sent by the server
and includes a stateless cookie, which is returned in a and includes a stateless cookie, which is returned in a
ClientHello message back to the server. Although the exchange is ClientHello message back to the server. Although the exchange is
optional for the server to execute, a client implementation has to optional for the server to execute, a client implementation has to
be prepared to respond to it. Furthermore, the handshake message be prepared to respond to it. Furthermore, the handshake message
format has been extended to deal with message loss, reordering, format has been extended to deal with message loss, reordering,
skipping to change at page 15, line 38 skipping to change at page 15, line 38
Authentication: Authentication:
The next challenge concerns the provisioning of authentication The next challenge concerns the provisioning of authentication
credentials to the clients as well as servers. In Section 4.1 we credentials to the clients as well as servers. In Section 4.1 we
assumed that credentials (and other configuration information) are assumed that credentials (and other configuration information) are
provisioned to the device and that those can be used with the provisioned to the device and that those can be used with the
authorization servers. Of course, this leads to a very static authorization servers. Of course, this leads to a very static
relationship between the clients and their server-side relationship between the clients and their server-side
infrastructure but poses fewer challenges from a deployment point infrastructure but poses fewer challenges from a deployment point
of view, as described in Section 2 of of view, as described in Section 2 of [RFC7452] these different
[I-D.iab-smart-object-architecture] these different communication communication patterns. In any case, engineers and product
patterns. In any case, engineers and product designers have to designers have to determine how the relevant credentials are
determine how the relevant credentials are distributed to the distributed to the respective parties. For example, shared
respective parties. For example, shared secrets may need to be secrets may need to be provisioned to clients and the constrained
provisioned to clients and the constrained servers for subsequent servers for subsequent use of TLS/DTLS PSK. In other deployments,
use of TLS/DTLS PSK. In other deployments, certificates, private certificates, private keys, and trust anchors for use with
keys, and trust anchors for use with certificate-based certificate-based authentication may need to be utilized.
authentication may need to be utilized.
Practical solutions either use pairing (also called imprinting) or Practical solutions either use pairing (also called imprinting) or
a trusted third party. With pairing two devices execute a special a trusted third party. With pairing two devices execute a special
protocol exchange that is unauthenticated to establish an shared protocol exchange that is unauthenticated to establish an shared
key (for example using an unauthenticated Diffie-Hellman exchange) key (for example using an unauthenticated Diffie-Hellman exchange)
key. To avoid man-in-the-middle attacks an out-of-band channel is key. To avoid man-in-the-middle attacks an out-of-band channel is
used to verify that nobody has tampered with the exchanged used to verify that nobody has tampered with the exchanged
protocol messages. This out-of-band channel can come in many protocol messages. This out-of-band channel can come in many
forms, including: forms, including:
skipping to change at page 18, line 4 skipping to change at page 17, line 40
<------------------------------- <-------------------------------
22.5 C 22.5 C
Configure Actuator Configure Actuator
(authenticated/authorized) (authenticated/authorized)
-------------------------------------------------> ------------------------------------------------->
PUT /fan?on-off=true PUT /fan?on-off=true
CoAP 2.04 Changed CoAP 2.04 Changed
<------------------------------------------------- <-------------------------------------------------
Figure 6: Local Discovery and Resouce Access. Figure 6: Local Discovery and Resouce Access.
5. The Ciphersuite Concept 5. The Ciphersuite Concept
TLS (and consequently DTLS) has the concept of ciphersuites and an TLS (and consequently DTLS) has the concept of ciphersuites and an
IANA registry [IANA-TLS] was created to register the suites. A IANA registry [IANA-TLS] was created to register the suites. A
ciphersuite (and the specification that defines it) contains the ciphersuite (and the specification that defines it) contains the
following information: following information:
o Authentication and key exchange algorithm (e.g., PSK) o Authentication and key exchange algorithm (e.g., PSK)
o Cipher and key length (e.g., Advanced Encryption Standard (AES) o Cipher and key length (e.g., Advanced Encryption Standard (AES)
with 128 bit keys [AES]) with 128 bit keys [AES])
o Mode of operation (e.g., Counter with Cipher Block Chaining - o Mode of operation (e.g., Counter with Cipher Block Chaining -
Message Authentication Code (CBC-MAC) Mode (CCM) for AES) Message Authentication Code (CBC-MAC) Mode (CCM) for AES)
[RFC3610] [RFC3610]
o Hash algorithm for integrity protection, such as the Secure Hash o Hash algorithm for integrity protection, such as the Secure Hash
Algorithm (SHA) in combination with Keyed-Hashing for Message Algorithm (SHA) in combination with Keyed-Hashing for Message
Authentication (HMAC) (see [RFC2104] and [RFC4634]) Authentication (HMAC) (see [RFC2104] and [RFC6234])
o Hash algorithm for use with pseudorandom functions (e.g., HMAC o Hash algorithm for use with pseudorandom functions (e.g., HMAC
with the SHA-256) with the SHA-256)
o Misc information (e.g., length of authentication tags) o Misc information (e.g., length of authentication tags)
o Information whether the ciphersuite is suitable for DTLS or only o Information whether the ciphersuite is suitable for DTLS or only
for TLS for TLS
The TLS ciphersuite TLS_PSK_WITH_AES_128_CCM_8, for example, uses a The TLS ciphersuite TLS_PSK_WITH_AES_128_CCM_8, for example, uses a
skipping to change at page 31, line 42 skipping to change at page 31, line 42
approach. approach.
If both the client and the server are constrained devices both If both the client and the server are constrained devices both
devices SHOULD implement RFC 5077 and MUST implement basic session devices SHOULD implement RFC 5077 and MUST implement basic session
resumption. Clients that do not want to use session resumption are resumption. Clients that do not want to use session resumption are
always able to send a ClientHello message with an empty session_id to always able to send a ClientHello message with an empty session_id to
revert to a full handshake. revert to a full handshake.
10. Compression 10. Compression
Section 3.3 of [I-D.ietf-uta-tls-bcp] recommends to disable TLS/DTLS- Section 3.3 of [RFC7525] recommends to disable TLS/DTLS-level
level compression due to attacks, such as CRIME. For IoT compression due to attacks, such as CRIME. For IoT applications
applications compression at the TLS/DTLS layer is not needed since compression at the TLS/DTLS layer is not needed since application
application layer protocols are highly optimized and the compression layer protocols are highly optimized and the compression algorithms
algorithms at the DTLS layer increases code size and complexity. at the DTLS layer increases code size and complexity.
This TLS/DTLS profile MUST NOT implement TLS/DTLS layer compression. This TLS/DTLS profile MUST NOT implement TLS/DTLS layer compression.
11. Perfect Forward Secrecy 11. Perfect Forward Secrecy
Perfect forward secrecy (PFS) is a property that preserves the Perfect forward secrecy (PFS) is a property that preserves the
confidentiality of past conversations even in situations where the confidentiality of past conversations even in situations where the
long-term secret is compromised. long-term secret is compromised.
The PSK ciphersuite recommended in Section 6.1 does not offer this The PSK ciphersuite recommended in Section 6.1 does not offer this
skipping to change at page 38, line 52 skipping to change at page 38, line 52
higher than what it knows about. This is the behaviour that leads higher than what it knows about. This is the behaviour that leads
some clients to re-run the handshake with lower version. As a some clients to re-run the handshake with lower version. As a
result, a potential security vulnerability is introduced when a result, a potential security vulnerability is introduced when a
system is running an old TLS/SSL version (e.g., because of the need system is running an old TLS/SSL version (e.g., because of the need
to integrate with legacy systems). In the worst case, this allows an to integrate with legacy systems). In the worst case, this allows an
attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is
so broken that there is no secure cipher available for it (see so broken that there is no secure cipher available for it (see
[I-D.ietf-tls-sslv3-diediedie]). [I-D.ietf-tls-sslv3-diediedie]).
The above-described downgrade vulnerability is solved by the TLS The above-described downgrade vulnerability is solved by the TLS
Fallback Signaling Cipher Suite Value (SCSV) Fallback Signaling Cipher Suite Value (SCSV) [RFC7507] extension.
[I-D.ietf-tls-downgrade-scsv] extension. However, the solution is However, the solution is not appliable to implementations conforming
not appliable to implementations conforming to this profile since the to this profile since the version negotiation MUST use TLS/DTLS
version negotiation MUST use TLS/DTLS version 1.2 (or higher). More version 1.2 (or higher). More specifically, this implies:
specifically, this implies:
o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in
the ClientHello. the ClientHello.
o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS
version lower than 1.2. version lower than 1.2.
o Servers MUST fail the handshake by sending a protocol_version o Servers MUST fail the handshake by sending a protocol_version
fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated. fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated.
Note that the aborted connection is non-resumable. Note that the aborted connection is non-resumable.
skipping to change at page 40, line 22 skipping to change at page 40, line 21
who gives developers access to the AES crypto function can use it who gives developers access to the AES crypto function can use it
to build an efficient AES-GCM implementations. Another example is to build an efficient AES-GCM implementations. Another example is
to make a special instruction available that increases the speed to make a special instruction available that increases the speed
of speed-up carryless multiplications. of speed-up carryless multiplications.
As a recommendation for developers and product architects we As a recommendation for developers and product architects we
recommend that sufficient headroom is provided to allow an upgrade to recommend that sufficient headroom is provided to allow an upgrade to
a newer cryptographic algorithms over the lifetime of the product. a newer cryptographic algorithms over the lifetime of the product.
As an example, while AES-CCM is recommended thoughout this As an example, while AES-CCM is recommended thoughout this
specification future products might use the ChaCha20 cipher in specification future products might use the ChaCha20 cipher in
combination with the Poly1305 authenticator combination with the Poly1305 authenticator [RFC7539]. The
[I-D.irtf-cfrg-chacha20-poly1305]. The assumption is made that a assumption is made that a robust software update mechanism is
robust software update mechanism is offered. offered.
22. Key Length Recommendations 22. Key Length Recommendations
RFC 4492 [RFC4492] gives approximate comparable key sizes for RFC 4492 [RFC4492] gives approximate comparable key sizes for
symmetric- and asymmetric-key cryptosystems based on the best-known symmetric- and asymmetric-key cryptosystems based on the best-known
algorithms for attacking them. While other publications suggest algorithms for attacking them. While other publications suggest
slightly different numbers, such as [Keylength], the approximate slightly different numbers, such as [Keylength], the approximate
relationship still holds true. Figure 11 illustrates the comparable relationship still holds true. Figure 11 illustrates the comparable
key sizes in bits. key sizes in bits.
skipping to change at page 40, line 46 skipping to change at page 40, line 45
------------+---------+------------- ------------+---------+-------------
80 | 163 | 1024 80 | 163 | 1024
112 | 233 | 2048 112 | 233 | 2048
128 | 283 | 3072 128 | 283 | 3072
192 | 409 | 7680 192 | 409 | 7680
256 | 571 | 15360 256 | 571 | 15360
Figure 11: Comparable Key Sizes (in bits) based on RFC 4492. Figure 11: Comparable Key Sizes (in bits) based on RFC 4492.
At the time of writing the key size recommendations for use with TLS- At the time of writing the key size recommendations for use with TLS-
based ciphers found in [I-D.ietf-uta-tls-bcp] recommend DH key based ciphers found in [RFC7525] recommend DH key lengths of at least
lengths of at least 2048 bit, which corresponds to a 112-bit 2048 bit, which corresponds to a 112-bit symmetric key and a 233 bit
symmetric key and a 233 bit ECC key. These recommendations are ECC key. These recommendations are roughly inline with those from
roughly inline with those from other organizations, such as the other organizations, such as the National Institute of Standards and
National Institute of Standards and Technology (NIST) or the European Technology (NIST) or the European Network and Information Security
Network and Information Security Agency (ENISA). The authors of Agency (ENISA). The authors of [ENISA-Report2013] add that a 80-bit
[ENISA-Report2013] add that a 80-bit symmetric key is sufficient for symmetric key is sufficient for legacy applications for the coming
legacy applications for the coming years, but a 128-bit symmetric key years, but a 128-bit symmetric key is the minimum requirement for new
is the minimum requirement for new systems being deployed. The systems being deployed. The authors further note that one needs to
authors further note that one needs to also take into account the also take into account the length of time data needs to be kept
length of time data needs to be kept secure for. The use of 80-bit secure for. The use of 80-bit symmetric keys for transactional data
symmetric keys for transactional data may be acceptable for the near may be acceptable for the near future while one has to insist on
future while one has to insist on 128-bit symmetric keys for long 128-bit symmetric keys for long lived data.
lived data.
Note that the recommendations for 112-bit symmetric keys are chosen Note that the recommendations for 112-bit symmetric keys are chosen
conservatively under the assumption that IoT devices have a long conservatively under the assumption that IoT devices have a long
expected lifetime (such as 10+ years) and that this key length expected lifetime (such as 10+ years) and that this key length
recommendation refers to the long-term keys used for device recommendation refers to the long-term keys used for device
authentication. Keys, which are provisioned dynamically, for the authentication. Keys, which are provisioned dynamically, for the
protection of transactional data (such as ephemeral Diffie-Hellman protection of transactional data (such as ephemeral Diffie-Hellman
keys used in various TLS/DTLS ciphersuites) may be shorter keys used in various TLS/DTLS ciphersuites) may be shorter
considering the sensitivity of the exchanged data. considering the sensitivity of the exchanged data.
skipping to change at page 45, line 46 skipping to change at page 45, line 46
[I-D.bmoeller-tls-falsestart] [I-D.bmoeller-tls-falsestart]
Langley, A., Modadugu, N., and B. Moeller, "Transport Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", draft-bmoeller-tls- Layer Security (TLS) False Start", draft-bmoeller-tls-
falsestart-01 (work in progress), November 2014. falsestart-01 (work in progress), November 2014.
[I-D.bormann-core-cocoa] [I-D.bormann-core-cocoa]
Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,
"CoAP Simple Congestion Control/Advanced", draft-bormann- "CoAP Simple Congestion Control/Advanced", draft-bormann-
core-cocoa-02 (work in progress), July 2014. core-cocoa-02 (work in progress), July 2014.
[I-D.iab-smart-object-architecture]
Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
"Architectural Considerations in Smart Object Networking",
draft-iab-smart-object-architecture-06 (work in progress),
October 2014.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z. and C. Bormann, "CoRE Resource Directory", Shelby, Z. and C. Bormann, "CoRE Resource Directory",
draft-ietf-core-resource-directory-02 (work in progress), draft-ietf-core-resource-directory-02 (work in progress),
November 2014. November 2014.
[I-D.ietf-lwig-tls-minimal]
Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's
Guide to the (Datagram) Transport Layer Security Protocol
for Smart Objects and Constrained Node Networks", draft-
ietf-lwig-tls-minimal-01 (work in progress), March 2014.
[I-D.ietf-tls-downgrade-scsv]
Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade
Attacks", draft-ietf-tls-downgrade-scsv-05 (work in
progress), February 2015.
[I-D.ietf-tls-negotiated-dl-dhe] [I-D.ietf-tls-negotiated-dl-dhe]
Gillmor, D., "Negotiated Discrete Log Diffie-Hellman Gillmor, D., "Negotiated Discrete Log Diffie-Hellman
Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- Ephemeral Parameters for TLS", draft-ietf-tls-negotiated-
dl-dhe-00 (work in progress), July 2014. dl-dhe-00 (work in progress), July 2014.
[I-D.ietf-tls-prohibiting-rc4]
Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf-
tls-prohibiting-rc4-01 (work in progress), October 2014.
[I-D.ietf-tls-sslv3-diediedie] [I-D.ietf-tls-sslv3-diediedie]
Barnes, R., Thomson, M., Pironti, A., and A. Langley, Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", draft- "Deprecating Secure Sockets Layer Version 3.0", draft-
ietf-tls-sslv3-diediedie-03 (work in progress), April ietf-tls-sslv3-diediedie-03 (work in progress), April
2015. 2015.
[I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-11 (work in progress), February 2015.
[I-D.irtf-cfrg-chacha20-poly1305]
Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
protocols", draft-irtf-cfrg-chacha20-poly1305-10 (work in
progress), February 2015.
[I-D.irtf-cfrg-curves] [I-D.irtf-cfrg-curves]
Langley, A., Salz, R., and S. Turner, "Elliptic Curves for Langley, A., Salz, R., and S. Turner, "Elliptic Curves for
Security", draft-irtf-cfrg-curves-02 (work in progress), Security", draft-irtf-cfrg-curves-02 (work in progress),
March 2015. March 2015.
[I-D.josefsson-eddsa-ed25519] [I-D.josefsson-eddsa-ed25519]
Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft- Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft-
josefsson-eddsa-ed25519-03 (work in progress), May 2015. josefsson-eddsa-ed25519-03 (work in progress), May 2015.
[I-D.mathewson-no-gmtunixtime] [I-D.mathewson-no-gmtunixtime]
skipping to change at page 48, line 19 skipping to change at page 47, line 37
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004. 3748, June 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006. for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", RFC Overview, Assumptions, Problem Statement, and Goals", RFC
4919, August 2007. 4919, August 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
skipping to change at page 49, line 19 skipping to change at page 48, line 36
[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Management Protocol (TAMP)", RFC 5934, August 2010. Management Protocol (TAMP)", RFC 5934, August 2010.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, October 2010. Requirements", RFC 6024, October 2010.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011. Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", RFC 6655, July 2012. Transport Layer Security (TLS)", RFC 6655, July 2012.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012. Format", RFC 6690, August 2012.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012. "Diameter Base Protocol", RFC 6733, October 2012.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
skipping to change at page 50, line 9 skipping to change at page 49, line 29
Constrained Application Protocol (CoAP)", RFC 7390, Constrained Application Protocol (CoAP)", RFC 7390,
October 2014. October 2014.
[RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart [RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart
Object Security Workshop", RFC 7397, December 2014. Object Security Workshop", RFC 7397, December 2014.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", RFC 7400, November 2014. (6LoWPANs)", RFC 7400, November 2014.
[RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
"Architectural Considerations in Smart Object Networking",
RFC 7452, March 2015.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
February 2015.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade
Attacks", RFC 7507, April 2015.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015.
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 7539, May 2015.
[SP800-22b] [SP800-22b]
National Institute of Standards and Technology, "Special National Institute of Standards and Technology, "Special
Publication 800-22, Revision 1a, A Statistical Test Suite Publication 800-22, Revision 1a, A Statistical Test Suite
for Random and Pseudorandom Number Generators for for Random and Pseudorandom Number Generators for
Cryptographic Applications", Cryptographic Applications",
http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/ http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/
SP800-22rev1a.pdf, April 2010. SP800-22rev1a.pdf, April 2010.
[SP800-90A] [SP800-90A]
NIST, "DRAFT Special Publication 800-90a, Revision 1, NIST, "DRAFT Special Publication 800-90a, Revision 1,
 End of changes. 19 change blocks. 
83 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/