draft-ietf-ace-dtls-authorize-07.txt   draft-ietf-ace-dtls-authorize-08.txt 
ACE Working Group S. Gerdes ACE Working Group S. Gerdes
Internet-Draft O. Bergmann Internet-Draft O. Bergmann
Intended status: Standards Track C. Bormann Intended status: Standards Track C. Bormann
Expires: September 12, 2019 Universitaet Bremen TZI Expires: October 14, 2019 Universitaet Bremen TZI
G. Selander G. Selander
Ericsson AB Ericsson AB
L. Seitz L. Seitz
RISE SICS RISE
March 11, 2019 April 12, 2019
Datagram Transport Layer Security (DTLS) Profile for Authentication and Datagram Transport Layer Security (DTLS) Profile for Authentication and
Authorization for Constrained Environments (ACE) Authorization for Constrained Environments (ACE)
draft-ietf-ace-dtls-authorize-07 draft-ietf-ace-dtls-authorize-08
Abstract Abstract
This specification defines a profile of the ACE framework that allows This specification defines a profile of the ACE framework that allows
constrained servers to delegate client authentication and constrained servers to delegate client authentication and
authorization. The protocol relies on DTLS for communication authorization. The protocol relies on DTLS for communication
security between entities in a constrained network using either raw security between entities in a constrained network using either raw
public keys or pre-shared keys. A resource-constrained server can public keys or pre-shared keys. A resource-constrained server can
use this protocol to delegate management of authorization information use this protocol to delegate management of authorization information
to a trusted host with less severe limitations regarding processing to a trusted host with less severe limitations regarding processing
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 12, 2019. This Internet-Draft will expire on October 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 29 skipping to change at page 2, line 29
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Communication between C and AS . . . . . . . . . . . . . 5 3.1. Communication between C and AS . . . . . . . . . . . . . 5
3.2. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . 6 3.2. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . 6
3.2.1. DTLS Channel Setup Between C and RS . . . . . . . . . 7 3.2.1. DTLS Channel Setup Between C and RS . . . . . . . . . 7
3.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 8 3.3. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . 8
3.3.1. DTLS Channel Setup Between C and RS . . . . . . . . . 12 3.3.1. DTLS Channel Setup Between C and RS . . . . . . . . . 12
3.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 13 3.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 13
4. Dynamic Update of Authorization Information . . . . . . . . . 14 4. Dynamic Update of Authorization Information . . . . . . . . . 14
5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 16 5. Token Expiration . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Secure Communication with AS . . . . . . . . . . . . . . . . 16
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This specification defines a profile of the ACE framework This specification defines a profile of the ACE framework
[I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource [I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource
server use CoAP [RFC7252] over DTLS [RFC6347] to communicate. The server use CoAP [RFC7252] over DTLS [RFC6347] to communicate. The
client obtains an access token, bound to a key (the proof-of- client obtains an access token, bound to a key (the proof-of-
possession key), from an authorization server to prove its possession key), from an authorization server to prove its
authorization to access protected resources hosted by the resource authorization to access protected resources hosted by the resource
skipping to change at page 5, line 49 skipping to change at page 5, line 49
verify that AS is authorized to provide access tokens (including verify that AS is authorized to provide access tokens (including
authorization information) about RS to C. Also, AS MUST securely authorization information) about RS to C. Also, AS MUST securely
have obtained keying material for C, and obtained authorization rules have obtained keying material for C, and obtained authorization rules
approved by the resource owner (RO) concerning C and RS that relate approved by the resource owner (RO) concerning C and RS that relate
to this keying material. C and AS MUST use their respective keying to this keying material. C and AS MUST use their respective keying
material for all exchanged messages. How the security association material for all exchanged messages. How the security association
between C and AS is bootstrapped is not part of this document. C and between C and AS is bootstrapped is not part of this document. C and
AS MUST ensure the confidentiality, integrity and authenticity of all AS MUST ensure the confidentiality, integrity and authenticity of all
exchanged messages. exchanged messages.
If C is constrained, C and AS should use DTLS to communicate with Section Section 6 specifies how communication with the AS is secured.
each other. But C and AS may also use other means to secure their
communication, e.g., TLS. The used security protocol MUST fulfill
the communication security requirements in Section 6.2 of
[I-D.ietf-ace-oauth-authz].
3.2. RawPublicKey Mode 3.2. RawPublicKey Mode
After C and AS mutually authenticated each other and validated each After C and AS mutually authenticated each other and validated each
other's authorization, C sends a token request to AS's token other's authorization, C sends a token request to AS's token
endpoint. The client MUST add a "req_cnf" object carrying either its endpoint. The client MUST add a "req_cnf" object carrying either its
raw public key or a unique identifier for a public key that it has raw public key or a unique identifier for a public key that it has
previously made known to the authorization server. To prove that the previously made known to the authorization server. To prove that the
client is in possession of this key, C MUST use the same keying client is in possession of this key, C MUST use the same keying
material that it uses to secure the communication with AS, e.g., the material that it uses to secure the communication with AS, e.g., the
DTLS session. DTLS session.
An example access token request from the client to the AS is depicted An example access token request from the client to the AS is depicted
in Figure 3. in Figure 3.
POST coaps://as.example.com/token POST coaps://as.example.com/token
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Payload: Payload:
{ {
"grant_type" : "client_credentials", grant_type : client_credentials,
"req_aud" : "tempSensor4711", req_aud : "tempSensor4711",
"req_cnf" : { req_cnf : {
"COSE_Key" : { COSE_Key : {
"kty" : "EC2", kty : EC2,
"crv" : "P-256", crv : P-256,
"x" : h'e866c35f4c3c81bb96a1...', x : h'e866c35f4c3c81bb96a1...',
"y" : h'2e25556be097c8778a20...' y : h'2e25556be097c8778a20...'
} }
} }
} }
Figure 3: Access Token Request Example for RPK Mode Figure 3: Access Token Request Example for RPK Mode
The example shows an access token request for the resource identified The example shows an access token request for the resource identified
by the string "tempSensor4711" on the authorization server using a by the string "tempSensor4711" on the authorization server using a
raw public key. raw public key.
skipping to change at page 7, line 24 skipping to change at page 7, line 21
resource server with which C wants to communicate. resource server with which C wants to communicate.
An example access token response from the AS to the client is An example access token response from the AS to the client is
depicted in Figure 4. depicted in Figure 4.
2.01 Created 2.01 Created
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Max-Age: 3600 Max-Age: 3600
Payload: Payload:
{ {
"access_token" : "b64'SlAV32hkKG ... access_token : b64'SlAV32hkKG...
(remainder of CWT omitted for brevity; (remainder of CWT omitted for brevity;
CWT contains clients RPK in the "cnf" claim)', CWT contains clients RPK in the cnf claim)',
"expires_in" : "3600", expires_in : 3600,
"rs_cnf" : { rs_cnf : {
"COSE_Key" : { COSE_Key : {
"kty" : "EC2", kty : EC2,
"crv" : "P-256", crv : P-256,
"x" : h'd7cc072de2205bdc1537...', x : h'd7cc072de2205bdc1537...',
"y" : h'f95e1d4b851a2cc80fff...' y : h'f95e1d4b851a2cc80fff...'
} }
} }
} }
Figure 4: Access Token Response Example for RPK Mode Figure 4: Access Token Response Example for RPK Mode
3.2.1. DTLS Channel Setup Between C and RS 3.2.1. DTLS Channel Setup Between C and RS
Before the client initiates the DTLS handshake with the resource Before the client initiates the DTLS handshake with the resource
server, C MUST send a "POST" request containing the new access token server, C MUST send a "POST" request containing the new access token
skipping to change at page 9, line 23 skipping to change at page 9, line 23
token MUST be bound to the same symmetric key by means of the cnf token MUST be bound to the same symmetric key by means of the cnf
claim. claim.
An example access token request for an access token with a symmetric An example access token request for an access token with a symmetric
proof-of-possession key is illustrated in Figure 5. proof-of-possession key is illustrated in Figure 5.
POST coaps://as.example.com/token POST coaps://as.example.com/token
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Payload: Payload:
{ {
"audience" : "smokeSensor1807", audience : "smokeSensor1807",
} }
Figure 5: Example Access Token Request, symmetric PoP-key Figure 5: Example Access Token Request, symmetric PoP-key
An example access token response is illustrated in Figure 6. In this An example access token response is illustrated in Figure 6. In this
example, the authorization server returns a 2.01 response containing example, the authorization server returns a 2.01 response containing
a new access token and information for the client, including the a new access token and information for the client, including the
symmetric key in the cnf claim. The information is transferred as a symmetric key in the cnf claim. The information is transferred as a
CBOR data structure as specified in [I-D.ietf-ace-oauth-authz]. CBOR data structure as specified in [I-D.ietf-ace-oauth-authz].
2.01 Created 2.01 Created
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Max-Age: 86400 Max-Age: 86400
Payload: Payload:
{ {
"access_token" : h'd08343a10... access_token : h'd08343a10...
(remainder of CWT omitted for brevity) (remainder of CWT omitted for brevity)
"token_type" : "pop", token_type : pop,
"expires_in" : 86400, expires_in : 86400,
"profile" : "coap_dtls", profile : coap_dtls,
"cnf" : { cnf : {
"COSE_Key" : { COSE_Key : {
"kty" : "symmetric", kty : symmetric,
"kid" : h'3d027833fc6267ce', kid : h'3d027833fc6267ce',
"k" : h'73657373696f6e6b6579' k : h'73657373696f6e6b6579'
} }
} }
} }
Figure 6: Example Access Token Response, symmetric PoP-key Figure 6: Example Access Token Response, symmetric PoP-key
The access token also comprises a "cnf" claim. This claim usually The access token also comprises a "cnf" claim. This claim usually
contains a "COSE_Key" object that carries either the symmetric key contains a "COSE_Key" object that carries either the symmetric key
itself or a key identifier that can be used by the resource server to itself or a key identifier that can be used by the resource server to
determine the secret key shared with the client. If the access token determine the secret key shared with the client. If the access token
carries a symmetric key, the access token MUST be encrypted using a carries a symmetric key, the access token MUST be encrypted using a
"COSE_Encrypt0" structure. The AS MUST use the keying material "COSE_Encrypt0" structure. The AS MUST use the keying material
shared with the RS to encrypt the token. shared with the RS to encrypt the token.
The "cnf" structure in the access token is provided in Figure 7. The "cnf" structure in the access token is provided in Figure 7.
"cnf" : { cnf : {
"COSE_Key" : { COSE_Key : {
"kty" : "symmetric", kty : symmetric,
"kid" : h'eIiOFCa9lObw' kid : h'6549694f464361396c4f6277'
} }
} }
Figure 7: Access Token without Keying Material Figure 7: Access Token without Keying Material
A response that declines any operation on the requested resource is A response that declines any operation on the requested resource is
constructed according to Section 5.2 of [RFC6749], (cf. constructed according to Section 5.2 of [RFC6749], (cf.
Section 5.6.3. of [I-D.ietf-ace-oauth-authz]). Section 5.6.3. of [I-D.ietf-ace-oauth-authz]).
4.00 Bad Request 4.00 Bad Request
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
Payload: Payload:
{ {
"error" : "invalid_request" error : invalid_request
} }
Figure 8: Example Access Token Response With Reject Figure 8: Example Access Token Response With Reject
The method for how the resource server determines the symmetric key The method for how the resource server determines the symmetric key
from an access token containing only a key identifier is application from an access token containing only a key identifier is application
specific, the remainder of this section provides one example. specific, the remainder of this section provides one example.
The AS and the resource server are assumed to share a key derivation The AS and the resource server are assumed to share a key derivation
key used to derive the symmetric key shared with the client from the key used to derive the symmetric key shared with the client from the
key identifier in the access token. The key derivation key may be key identifier in the access token. The key derivation key may be
derived derived from some other secret key shared between the AS and the
from some other secret key shared between the AS and the resource resource server. This key needs to be securely stored and processed
server. This key needs to be securely stored and processed in the in the same way as the key used to protect the communication between
same way as the key used to protect the communication between AS and AS and RS.
RS.
Knowledge of the symmetric key shared with the client must not reveal Knowledge of the symmetric key shared with the client must not reveal
any information about the key derivation key or other secret keys any information about the key derivation key or other secret keys
shared between AS and resource server. shared between AS and resource server.
In order to generate a new symmetric key to be used by client and In order to generate a new symmetric key to be used by client and
resource server, the AS generates a key identifier and uses the key resource server, the AS generates a key identifier and uses the key
derivation key shared with the resource server to derive the derivation key shared with the resource server to derive the
symmetric key as specified below. Instead of providing the keying symmetric key as specified below. Instead of providing the keying
material in the access token, the AS includes the key identifier in material in the access token, the AS includes the key identifier in
skipping to change at page 16, line 19 skipping to change at page 16, line 19
may become invalid at any time (e.g. because it has expired), the may become invalid at any time (e.g. because it has expired), the
session may become useless at some point. A resource server session may become useless at some point. A resource server
therefore MUST terminate existing DTLS sessions after the access therefore MUST terminate existing DTLS sessions after the access
token for this session has been deleted. token for this session has been deleted.
As specified in Section 5.8.3 of [I-D.ietf-ace-oauth-authz], the As specified in Section 5.8.3 of [I-D.ietf-ace-oauth-authz], the
resource server MUST notify the client with an error response with resource server MUST notify the client with an error response with
code 4.01 (Unauthorized) for any long running request before code 4.01 (Unauthorized) for any long running request before
terminating the session. terminating the session.
6. Security Considerations 6. Secure Communication with AS
As specified in the ACE framework (sections 5.6 and 5.7 of
[I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or client)
and the AS communicate via the token endpoint or introspection
endpoint. The use of CoAP and DTLS for this communication is
RECOMMENDED in this profile, other protocols (such as HTTP and TLS or
CoAP and OSCORE) MAY be used instead.
How credentials (e.g., PSK, RPK, X.509 cert) for using DTLS with the
AS are established is out of scope for this profile.
If other means of securing the communication with the AS are used,
the security protocol MUST fulfill the communication security
requirements in Section 6.2 of [I-D.ietf-ace-oauth-authz].
7. Security Considerations
This document specifies a profile for the Authentication and This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework Authorization for Constrained Environments (ACE) framework
[I-D.ietf-ace-oauth-authz]. As it follows this framework's general [I-D.ietf-ace-oauth-authz]. As it follows this framework's general
approach, the general security considerations from section 6 also approach, the general security considerations from section 6 also
apply to this profile. apply to this profile.
When using pre-shared keys provisioned by the AS, the security level When using pre-shared keys provisioned by the AS, the security level
depends on the randomness of PSK, and the security of the TLS cipher depends on the randomness of PSK, and the security of the TLS cipher
suite and key exchange algorithm. suite and key exchange algorithm.
skipping to change at page 17, line 5 skipping to change at page 17, line 17
time with interjected or otherwise retrieved valid access tokens. time with interjected or otherwise retrieved valid access tokens.
The use of multiple access tokens for a single client increases the The use of multiple access tokens for a single client increases the
strain on the resource server as it must consider every access token strain on the resource server as it must consider every access token
and calculate the actual permissions of the client. Also, tokens may and calculate the actual permissions of the client. Also, tokens may
contradict each other which may lead the server to enforce wrong contradict each other which may lead the server to enforce wrong
permissions. If one of the access tokens expires earlier than permissions. If one of the access tokens expires earlier than
others, the resulting permissions may offer insufficient protection. others, the resulting permissions may offer insufficient protection.
Developers SHOULD avoid using multiple access tokens for a client. Developers SHOULD avoid using multiple access tokens for a client.
7. Privacy Considerations 8. Privacy Considerations
This privacy considerations from section 7 of the This privacy considerations from section 7 of the
[I-D.ietf-ace-oauth-authz] apply also to this profile. [I-D.ietf-ace-oauth-authz] apply also to this profile.
An unprotected response to an unauthorized request may disclose An unprotected response to an unauthorized request may disclose
information about the resource server and/or its existing information about the resource server and/or its existing
relationship with the client. It is advisable to include as little relationship with the client. It is advisable to include as little
information as possible in an unencrypted response. When a DTLS information as possible in an unencrypted response. When a DTLS
session between the client and the resource server already exists, session between the client and the resource server already exists,
more detailed information MAY be included with an error response to more detailed information MAY be included with an error response to
skipping to change at page 17, line 29 skipping to change at page 17, line 41
Also, unprotected requests to the resource server may reveal Also, unprotected requests to the resource server may reveal
information about the client, e.g., which resources the client information about the client, e.g., which resources the client
attempts to request or the data that the client wants to provide to attempts to request or the data that the client wants to provide to
the resource server. The client SHOULD NOT send confidential data in the resource server. The client SHOULD NOT send confidential data in
an unprotected request. an unprotected request.
Note that some information might still leak after DTLS session is Note that some information might still leak after DTLS session is
established, due to observable message sizes, the source, and the established, due to observable message sizes, the source, and the
destination addresses. destination addresses.
8. IANA Considerations 9. IANA Considerations
The following registrations are done for the ACE OAuth Profile The following registrations are done for the ACE OAuth Profile
Registry following the procedure specified in Registry following the procedure specified in
[I-D.ietf-ace-oauth-authz]. [I-D.ietf-ace-oauth-authz].
Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
with the RFC number of this specification and delete this paragraph. with the RFC number of this specification and delete this paragraph.
Profile name: coap_dtls Profile name: coap_dtls
Profile Description: Profile for delegating client authentication and Profile Description: Profile for delegating client authentication and
authorization in a constrained environment by establishing a Datagram authorization in a constrained environment by establishing a Datagram
Transport Layer Security (DTLS) channel between resource-constrained Transport Layer Security (DTLS) channel between resource-constrained
nodes. nodes.
Profile ID: 1 Profile ID: 1
Change Controller: IESG Change Controller: IESG
Reference: [RFC-XXXX] Reference: [RFC-XXXX]
skipping to change at page 18, line 5 skipping to change at page 18, line 15
authorization in a constrained environment by establishing a Datagram authorization in a constrained environment by establishing a Datagram
Transport Layer Security (DTLS) channel between resource-constrained Transport Layer Security (DTLS) channel between resource-constrained
nodes. nodes.
Profile ID: 1 Profile ID: 1
Change Controller: IESG Change Controller: IESG
Reference: [RFC-XXXX] Reference: [RFC-XXXX]
9. References 10. References
9.1. Normative References 10.1. Normative References
[I-D.ietf-ace-cwt-proof-of-possession] [I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-06 (work in progress), February 2019. possession-06 (work in progress), February 2019.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24
(work in progress), March 2019. (work in progress), March 2019.
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-04 (work in progress), February 2019. params-05 (work in progress), March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005, RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/info/rfc4279>. <https://www.rfc-editor.org/info/rfc4279>.
skipping to change at page 19, line 19 skipping to change at page 19, line 28
<https://www.rfc-editor.org/info/rfc7925>. <https://www.rfc-editor.org/info/rfc7925>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 10.2. Informative References
[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, Transport Layer Security (TLS)", RFC 6655,
DOI 10.17487/RFC6655, July 2012, DOI 10.17487/RFC6655, July 2012,
<https://www.rfc-editor.org/info/rfc6655>. <https://www.rfc-editor.org/info/rfc6655>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
skipping to change at page 20, line 39 skipping to change at page 21, line 4
Email: bergmann@tzi.org Email: bergmann@tzi.org
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
Goeran Selander Goeran Selander
Ericsson AB Ericsson AB
Email: goran.selander@ericsson.com Email: goran.selander@ericsson.com
Ludwig Seitz Ludwig Seitz
RISE SICS RISE
Scheelevaegen 17 Scheelevaegen 17
Lund 223 70 Lund 223 70
Sweden Sweden
Email: ludwig.seitz@ri.se Email: ludwig.seitz@ri.se
 End of changes. 27 change blocks. 
64 lines changed or deleted 75 lines changed or added

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