| ACE Working Group | J. Cuellar |
| Internet-Draft | P. Kasinathan |
| Intended status: Standards Track | Siemens AG |
| Expires: July 2, 2017 | D. Calvo |
| Atos Research and Innovation | |
| December 29, 2016 |
Privacy-Enhanced Tokens for Authorization in ACE
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-04
This specification defines PAT, "Privacy-Enhanced-Authorization-Tokens" or "Pseudonym-based Authorization Tokens", a protocol and a token construction procedure for client authorization in a constrained environment.
This memo also specifies a profile for ACE framework for Authentication and Authorization for constrained environments. This draft uses CBOR Web Token (CWT) and CBOR Object Signing and Encryption (COSE) to encode PAT messages.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 2, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Three well-known problems in constrained environments are the authorization of clients to access resources on servers, the realization of secure communication between nodes, and the preservation of privacy. The reader is referred for instance to [draft-ietf-ace-actors], [I-D.ietf-ace-oauth-authz] and [KoMa2014].
This memo describes a way of constructing Token Material (Key Material) that can be used by clients and servers (or in some cases, more generally by arbitrary nodes) to create secure channels and provide authentication. Moreover, the construction can be used to offer user consent (in the sense of privacy) and to dynamically create pseudonyms to enhance the unlinkability of the information, see section [Features] below.
This draft uses the architecture of [draft-ietf-ace-actors] and [I-D.ietf-ace-oauth-authz], designed to help constrained nodes in authorization-related tasks via less-constrained nodes. Terminology for constrained nodes is described in [RFC7228]. PAT supports an implicit authorization mode where no authorization information is exchanged and uses access tokens to implement this architecture. A device that wants to access an item of interest on a constrained node first has to gain permission in the form of a token from the node's Authorization Server. This memo also specifies a profile for ACE framework (Authentication and Authorization for constrained environments).
One of the goal of PAT is to securely transmit authorization tokens. A by-product is the set-up of a Datagram Transport Layer Security (DTLS) [RFC6347] channel with symmetric pre-shared keys (PSK) [RFC4279] between two nodes. The main goal of the PAT is to present methods for constructing authorization tokens and to securely transmit them to the parties involved with privacy features such as unlinkability. The CoAP protocol [RFC7252] is used as the application layer protocol together with CWT.
Note that DTLS channel [I.D-draft-gerdes-ace-dtls-authorize] or Object security of CoAP (OSCOAP) [I-D.selander-ace-object-security] can be used to securely transmit the authorization tokens. In some cases, relevant in constrained environments, it is also not necessary for a secure transmission of the payload data from server to client. Further details will be presented in future versions of this draft.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance.
Terminology for entities in the architecture is defined in OAuth 2.0 [RFC6749] and [I-D.ietf-ace-actors], such as client (C), resource server (RS), resource owner (RO), resources (R) and authorization server (AS).
In addition to the terms defined in [I-D.ietf-ace-actors], we use additionally the following terms:
In future versions of this draft, the differences in token names and its purposes will be harmonized with [I-D.ietf-ace-oauth-authz].
This specification defines the PAT protocol and the PAT profile for ACE framework for authorization in the Internet of Things environment. The PAT protocol is built around the building blocks described in [I-D.ietf-ace-oauth-authz].
In this specification we assume the following:
For instance, the C may or may not know the corresponding AS to request a CT for the resource it would like to access from RS. Based on the knowledge C has, the first message from C can be either to RS or to AS. This draft assumes that RS is offline after commissioning, i.e., RS cannot make any introspective queries to the AS to verify the authorization information provided by the C.
Based on the above assumption, the simple message flow can be described as follows: a C may request a resource on RS without valid access token, the RS will reject and may provide AS information to the C. Then C may perform an Access-Request to AS for the required resource on RS. Then AS decides if C is allowed to access the resource or not based on permissions set by the RO. If so, AS generates a Client-Token (CT) used for the authorization with the symmetric proof-of-possession key between AS and RS. The C uses CT to construct Access-Token (AT) through which a security context (PAT secret) can be established between C and RS.
In particular, the method can be used in context where unlinkability (privacy) is a main goal: the tokens convey only the assurance of the authorization claims of the clients. This means that the payloads of our protocol, and in particular, the Authentication Token secrets used, can be constructed in such a way that they not leak information about the correspondence of messages to the same Client. In other words: if an eavesdropper observes the messages from the different Clients to and from the server, the protocol does not give him information about which messages correspond to the same Client. Of course, other information, like the IP-addresses or the contents themselves of the requests/responses may leak some information in this regard can be treated separately via other methods.
In short, the PAT protocol presents as the most important features:
The PAT protocol includes three actors: the RS, the C, and the AS. The PAT message flow is shown in Figure 1. Messages in [square brackets] mean they are optional.
,-. ,--. ,--. |C| |RS| |AS| `+' `+-' `+-' | | 1 Security-Association-Setup| | | <---------------------------> | | | | 2 [Resource-REQ] | | |------------------------> | | | | |3 [Un-Auth-REQ(AS-Info)]| | |<------------------------ | | | | | 4 Security-Association-Setup | |<-----------------------------------------------------> | | | | 5 Access-REQ | |------------------------------------------------------> | | | | 6 Access-RSP | |<------------------------------------------------------ | | | | 7 Resource-REQ | | |------------------------> | | | | | 8 Resource-RSP | | |<------------------------ | ,+. ,+-. ,+-. |C| |RS| |AS| `-' `--' `--' Figure 1: PAT protocol message flow
The AS and RS share a long term secret (K). To determine AS which in charge of a resource hosted at the RS, C MAY send an initial Resource-Request without valid access token to RS. RS denies the request without valid access token and could possibly include the address of its AS (AS-Info) to C in the response. Or, instead of the initial Resource-Request without valid access token, C MAY look up the desired resource in a resource directory as described in [I-D.ietf-core-resource-directory] that lists the available resources.
Once C knows AS's address, it can send an Access-Request for authorization to AS (directly, or indirectly using its own CAS). If the access is to be authorized, AS generates an Access-Request Response to C. It contains client token and a symmetric PoP key (the verifier) which is necessary for the C to create valid access tokens for RS.
Each time C sends RS a Resource-Request, it generates and presents an Access-Token to RS to prove its right to access. If the access-token is valid, RS sends a Resource-Response to the C. Later with the common established secret C and RS can generate derived keys which are described later in the draft.
The following section describes the message flow in more detail, especially how the messages, tokens are constructed and how RS and C can use their common knowledge i.e., initial PAT secret to verify the authenticity of the ATs.
Further, C and RS may derive keys from the initial PAT secret:
As CoAP [RFC7252] is the recommended application layer protocol for constrained devices, the PAT protocol is designed to work with CoAP.
The following notation:
A -> B : <Msg_Name>
represents the message with name Msg_Name, sent from A to B.
This memo assumes that the Resource Server RS and its Authentication Server AS share a secure channel and share a long term shared secret, i.e., a shared key (K), which MAY be implemented via USB (and physical security) or when commissioning the devices or by other means (out of scope). The shared secret (K) is used both by the AS and the RS to create a proof-of-possession keys (verifiers).
It must be stressed that the security of the protocol strongly depends on how secure this channel is. We can also assume that the CAS and AS share a secure connection, say over DTLS if CAS exist as an actor.
Also, during this process RS registers the cryptographic algorithms and parameters it can support validating the access-tokens for authorization. The internal clock of RS can be synchronized with the AS during the commissioning phase. How this time synchronization is refreshed will be discussed in the future version of this draft.
Initially, a C may not have a valid access token to access a protected resource hosted in RS or the corresponding AS-information from which it needs to get the authorization token. In this scenario, the Client may send a Resource-Request message to RS without valid access-token.
To enable resource discovery, RS may expose the URI "/.well-known/core" [RFC6690], but this resource itself MAY be protected. Thus, to discover the resources available on RS, the C can optionally make a CoAP GET request to the URI "/.well-known/core". As with any other unauthorized GET request, the Client C is asked to access the AS.
Once RS receives a request from a C, it checks the following:
Figure 2 shows the sequence of messages with detailed CoAP types between C and RS for the above Unauthorized resource request:
,-. ,--.
|C| |RS|
`+' `+-'
| | ,---------------------------.
| 1 Res-REQ | |Header:GET |
|----------->| |Type:Confirmable |
| | |URI-Path:.well-known/core |
| | `---------------------------'
| | ,---------------------------.
| | |Header: 4.01 Unauthorized |
| 2 Res-RSP | |Type: Acknowledgement |
|<-----------| |content-type: |
| | |application/cbor |
| | |Payload:{AS-Info,params} |
,+. ,+-.`---------------------------'
|C| |RS|
`-' `--'
Figure 2: C<->RS Resource-Request and Unauthorized as response
TBD: together with AS-Info, the RS may also send params. To mitigate attacks based on time synchronization the Lightweight Authenticated Time (LATe) synchronization protocol for constrained environments as described in [I.D-draft-navas-ace-secure-time-synchronization].
Figure 3 shows an example of the response message sent by RS to C encoded using CBOR [RFC7049] with pat-type="UnAuthReq". The response message might include key-reference ID of the shared secret between RS and AS, nonce to prevent replay attacks of C. Further, in the next versions of the draft time synchronization draft will be studied and adopted if necessary. Examples of binary encoded representations will available in the next versions of this draft.
Header: 4.01 (Unauthorized)
Content-Type: application/cbor+pat;
pat-type="UnAuthReq"
Payload:
{#Unprotected
AS-Info: "coaps://as.example.com/token",
params:
{
TBD: { ... }
}
}
Figure 3: AS information payload example
If C is registered with the AS as described in [I-D.ietf.ace-oauth-authz] or after C receives AS-Info, the C or CAS (if involved) MUST establish a secure connection channel with the AS.
Notice that, it is important to ensure that this connection is reliable and secure as the remainder of this protocol relies on the fact that the messages exchanged between C and AS are protected and confidential.
Once C establishes a secure communication channel with AS, C sends an access-request (ACC-REQ) message to AS to the endpoint /token requesting an access token for RS as described in [I-D.ietf.ace-oauth-authz].
Optionally, the C includes the details about the resources (R) or the corresponding URI with operations it needs to access or perform on RS to AS as part of the Access-Request Message, if not AS should prepare an access token with default permissions. Fine grained access to resources (R) of RS depends on the infrastructure or services the RS offers. For example, if RS exposes different resources such as temperature and humidity, a generic token may be granted by AS to C to access both resources on RS. On the other hand, the application developer or administrator may decide to have fine grained (different) tokens for each resource.
Figure 4 shows an access-request from C for a token to AS. The "aud" represents a specific resource R ("tempSensor") and "scope" represents the allowed actions that C is requesting to perform on the requested resource R as described in [I-D.ietf-ace-oauth-authz] using CWT [I-D.ietf-ace-cbor-web-token]. The Scope parameter can be designed based on application requirements i.e., it can be "read" or "write" or methods such as "GET|POST" etc. Note that we assume a DTLS-based communication defined in the DTLS profile [I.D-draft-gerdes-ace-dtls-authorize] for this example.
How the client is authenticating itself to the AS is out of scope of this draft, but in the following example the client presents its credentials i.e., password based authentication by presenting its client_secret (see section 2.3.1. of [RFC6749]).
Header: POST (Code=0.02)
Uri-Host: "coaps://as.example.com"
Uri-Path: "token"
Content-Type: "application/cbor+cwt"
Payload:
{
"grant_type" : "client_credentials",
"client_id": "client123",
"client_secret": "Secret123",
"aud" : "tempSensor",
"scope": "GET|POST",
... omitted for brevity ...
}
Figure 4: Example Client Access-Request message to AS
When AS receives an access-request from a C, AS validates and performs the following:
The Figure 5 shows the Access request from C to AS and the access-response from AS to C.
,-. ,--.
|C| |AS|
`+' `+-'
| 1 DTLS |
|<----------->
| |
| | ,------------------------.
| | |Header:POST(code=0.02) |
|2 Access-REQ| |content-type: |
|------------> |application/cbor |
| | |URI-Path: token |
| | |Payload:{ACC-REQ} |
| | `------------------------'
| | ,-----------------------------.
|3 Access-RSP| |Header: Created (code=2.01) |
|<------------ |content-type: |
| | |application/cbor |
| | |Payload:{ACC-RSP} |
,+. ,+-.`-----------------------------'
|C| |AS|
`-' `--'
Figure 5: Access-Request and Access-Response
The Access Request payload is already shown in Figure 4. How AS constructs the Client-Token (CT) and the verifier (the symmetric PoP key) for the C is described in the following:
The contents of the access-response (ACC-RSP) payload is logically spit into two major parts, the Client-Token (CT) and the Verifier (Symmetric PoP key). When the Client makes the authorized request to RS, the C will not send the verifier, but only the Client-Token with some additional parameters such as AuthenticationHash to prove RS that C holds the proof-of-possession (PoP) key.
The Verifier is constructed in such a way that with the Client-Token the RS is able to construct the Verifier with the shared key (K) between AS and RS.
Client-Token construction:
Verifier construction:
Important Note:
Figure 6 shows the example Access-Response from AS to C after successful validation of C's credentials presented in Access-Request message by C. The AS MUST include client_token, the verifier encoded in COSE-key using "cnf" parameter. The AS should specify required parameters as described in [I-D.ietf-ace-oauth-authz] such as the type of token, etc. Also, if the Access-Request from C does not include any profile, AS MUST signal the C to use appropriate or default profile that RS uses in the Access-Response payload.
Header: 2.01 (Created)
Content-Type: application/cbor+cwt+pat; pat-type="ct"
Location-Path: token/...
Payload:
{
"client_token": b64'SlAV32hkKG ...
{
"token_type": pop,
"aud": "tempSensor",
"scope": "read",
"seq": 1..,
"iat": 1...,
"nbf": 0...,
"cti": "..", # Unique can be a Sequence Number
"exp": 5...,
"alg": "chacha20/poly1305",
"profile": "ace_pat"
}
"cnf":
{
COSE_Key: {
"kty": "symmetric",
"kid": h'...
"k": b64'jb3yjn... #[verifier]
}
}
optional(TBD):{
"LATE time sync"
}
}
Figure 6: Example Access-Response message from AS to C
with detailed CWT params and payload info
Once C receives the Access-Response from AS, C can construct an Access-Token (AT) which will demonstrate that C has got the authorization to access resources (R) in RS. The message Resource-Request (RES-REQ) with new AT has to be sent afresh: Client C has to renew his Authorization status at the Resource Server.
The frequency in which the Client has to send a new AT can be enforced by RS and is determined indirectly by the owner of RS (or by AS). This allows a fine-grained control on the service level that the Resource Server will provide to the Client (for instance, on the amount of information of sensor data)
Each time a RES-REQ is sent from C to RS, a new Access-Token (AT) MAY be needed. Optionally, communications between C and RS can be encrypted to protect the payload and to enforce confidentiality if necessary. PAT profile provides necessary recommendations by using chach20/poly1305 AEAD algorithm.
The RS MUST implement /authz-info endpoint to allow any Client to transfer the access-token as described in [I-D.ietf-ace-oauth-authz]. The Resource-Request message with valid Access-Token shall be constructed by C and can be transported to RS in one of the following ways:
option1:
Request Message:{
CoAP request: POST
endpoint: /authz-info
payload:{
Access-Token:{ Client-Token,
AuthenticationHash=Hash(verifier+nonce)
}
}
Figure 7: option1: RES-REQ using /authz-info implemented at RS
Header: POST (Code=0.02)
Content-Type: application/cose+cbor+pat;
pat-type="AuthReq";
Uri-Host: "coap://rs.example"
Uri-Path: /authz-info
Payload:
{ # Unprotected
access_token: {
"client_token": b64'SlAV32hkKG {
"aud": "tempSensor"
"scope": "read"
... CWT omitted for brevity.
}
"nonce": "C_nonce"
"auth_hash": b64'v4Sugr7.. #[Hash=(verifier+nonce)]
}
}
Figure 8: Example of valid option1 request from C to RS
using endpoint /authz-info.
option2:
Request Message:{
CoAP request: GET/POST/PUT/DELETE
Access-Token: Client-Token,
AuthenticationHash= Hash(verifier+C_nonce)
MSG_PAYLOAD: Chach20/Poly1305(Verifier,C_nonce,
AAD=null, payload)
}
Figure 9: Example of option2 RES-REQ with native
PAT token transfer method
Header: POST (Code=0.02)
Content-Type: application/cose+cbor+pat;
cose-type="encrypt0";
"pat-type="AuthReq";
Uri-Host: "coap://rs.example"
Uri-Path: /firmware
Payload:
{# COSE Unprotected
access_token: {
"client_token": b64'SlAV32hkKG {
"aud": "firmwareUpd"
"scope": "write"
... CWT omitted for brevity,
}
"nonce": .. # C_nonce
"auth_hash": h'bfa03.. #[Hash=(verifier+nonce)]
}
# COSE_Encrypt0 + COSE_MAC0 Protected
ciphertext:{
#Chacha20/Poly1305 AEAD payload using
# key=verifier,
# nonce=C_nonce,
# AAD=auth_hash
h'....omitted for brevity
},
tag: h'... omitted for brevity
}
Figure 10: Example of valid POST request from C to RS
When the request with access-token arrives the RS from a C, RS MUST evaluate the resource request and its access-token in the following order:
Response to request option1:
When RS receives resource-request from a C of type option1, RS validates the access-token as described above,
Figure 11 shows an example of successful request and response for option1 to the endpoint /authz-info implemented in RS, RS should maintain a security context to enable subsequent communication channel with RS. RS could establish a secure channel with the initial PAT secret (the Verifier) i.e., the symmetric PoP key between C and RS using the DTLS profile described in [I.D-draft-gerdes-ace-dtls-authorize]. Further information about other methods of establishing secure channel will be presented in the future version of this draft.
,-. ,--.
|C| |RS|
`+' `+-'
| | ,-----------------------------.
| | |Code: POST |
| 1 Res-REQ | |URI-Path: /authz-info |
|----------->| |Payload:{ |
| | |access-token:{client-token, |
| | | auth_hash |
| | | } |
| | `-----------------------------'
| 2 Res-RSP | ,----------------------.
|<-----------| |Code: 2.04 (changed) |
,+. ,+-.`----------------------'
|C| |RS|
`-' `--'
Figure 11: Example RS response to C request on /authz-info
Response to request option2: If RS receives an option2 resource-request from C, RS should verify the following conditions before sending a response to C:
If the Access-Token is valid for every condition, then RS prepares a valid response. If request message's payload is encrypted, RS decrypts it using ChaCha20/Poly1305 AEAD algorithm using (key=verifier, nonce=C_nonce, AAD, payload). The response from RS MUST be encrypted so that only C with a valid key (the Verifier or using derived keys for subsequent messages) can decrypt the payload:
Encrypted Response payload:{
CoAP request: request type
RSP_MSG_PAYLOAD: Chach20/Poly1305(Key=verifier,
nonce = nonce++, AAD, payload)
}
Figure 12: Example of RS response payload with Encryption
for native PAT request option2
Notice the difference in the nonce parameter. A difference nonce MUST be used while encrypting the response, generally incrementing the nonce parameter is acceptable.
Figure 13 shows Authorized resource request from C->RS and response message RS->C.
,-. ,--.
|C| |RS|
`+' `+-'
| | ,-----------------------.
| | |Code: POST |
| | |URI-Path: /firmware |
| | |Payload: |
| | |{ |
| 1 Res-REQ | | access-token: |
|----------->| | {Client-Token, |
| | | AuthHash} |
| | | chacha20/poly1305( |
| | | key=Verifier, |
| | | nonce=C_nonce, |
| | | AAD, |
| | | data=firmware)} |
| | `-----------------------'
| | ,--------------------------.
| | |Code:2.01(Created) |
| | |Location-Path:/... |
| 2 Res-RSP | |Payload: |
|<-----------| |{ chacha20/poly1305 |
| | | (key=Verifier, |
| | | nonce=nonce++, AAD, |
| | | data=value)} |
,+. ,+-.`--------------------------'
|C| |RS|
`-' `--'
Figure 13: [C<->RS] Authorized Resource Request and Response
for native PAT request option2
Figure 14 shows the valid response from RS to C for the request type option2 presented in previous section. The chacha20/poly1305 function produces a ciphertext and a tag. It is important to note that "cks" means that C and RS understand the parameters for cryptographic operations that they use for communication.
Header: 2.01/2.04 (Created/Changed)
Content-Type: application/cose;
Payload:
{ cks: # COSE_Encrypt0 + COSE_MAC0 Protected
{
ciphertext:{ # Chacha20/Poly1305
# key=verifier, nonce=nonce++, payload
....omitted for brevity...
}
tag: ...omitted for brevity..
}
}
Figure 14: Example of valid response from RS to C
for native PAT request option2
TBD
The CoAP messaging layer parameters such as token and message-id can be used for matching a specific request and response.
TBD
TBD
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7252] Shelby, Z., Hartke, K. and Borman, C., "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014.
[RFC6347] Rescorla E. and Modadugu N., "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC4279] Eronen P. and Tschofenig H., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC7539] Y. Nir and A. Langley: ChaCha20 and Poly1305 for IETF Protocols, RFC7539, May 2015
[I-D.ietf-ace-actors] Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An architecture for authorization in constrained environments", draft-ietf-ace-actors-04 (work in progress), March 2017.
[I-D.ietf-oauth-pop-architecture] Hunt, P., Richer, J., Mills, W., Mishra, P., and H. Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security Architecture", draft-ietf-oauth-pop-architecture-07 (work in progress), December 2015.
[I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authorization for the Internet of Things using OAuth 2.0", draft-ietf-ace-oauth-authz-04 (work in progress), October 2016.
[I-D.ietf-core-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security of CoAP (OSCOAP)", draft-ietf-core-object-security-00 (work in progress), october 2016.
[I-D.ietf-cose-msg] Schaad, J., "CBOR Object Signing and Encryption (COSE)", draft-ietf-cose-msg-24 (work in progress), November 2016.
[KoMa2014] Kohnstamm, J. and Madhub, D., "Mauritius Declaration on the Internet of Things", 36th International Conference of Data Protection and Privacy Comissioners, October 2014.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>.
[I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., Van der Stok, P., "CoRE Resource Directory", draft-ietf-core-resource-directory-08 (work in progress), July 2016.
[I.D-draft-navas-ace-secure-time-synchronization] Navas, G., Selander, G., Seitz, L., "Lightweight Authenticated Time (LATe) Synchronization Protocol", draft-navas-ace-secure-time-synchronization-00 (work in progress), October 2016.
[I.D-draft-gerdes-ace-dtls-authorize] Gerdes, S., Begmann, O., Bormann, C., Selander, G., Seitz, L. Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE),draft-gerdes-ace-dtls-authorize-00, October 2016
[I-D.ietf-ace-cbor-web-token] Jones, M., Tschofenig, H., Erdtman, S., CBOR Web Token (CWT), draft-ietf-ace-cbor-web-token-01 (work in progress), July 2016.
This draft is the result of collaborative research in the RERUM EU funded project and has been partly funded by the European Commission (Contract No. 609094).
The authors thank Ludwig Seitz for reviewing previous version of the draft.
TBD
|----------------------+-----| | ACE profile template | PAT | |----------------------+-----| | Profile name | TBD | | Profile Description | TBD | | Profile ID | TBD | |----------------------+-----| Table2: ACE profile registration template
Copyright (c) 2015 IETF Trust and the persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents <http://trustee.ietf.org/license-info)>.