2.05 Content
    Content-Format: application/dcaf+json

Figure 5: Example Ticket Grant Message With Reject

3.7. Ticket Transfer Message

A Ticket Transfer message delivers the access information sent by AS in a Ticket Grant message to the requesting client C. The Ticket Transfer message is the response to the Access Request message sent from C to AM and includes any access information from AS contained in the Ticket Grant message.

3.8. DTLS Channel Setup Between C and RS

Using the information contained in a positive response to its Access Request (i.e. a Ticket Transfer message that contains a Face and a Verifier), C can initiate establishment of a new DTLS channel with RS. To use DTLS with pre-shared keys, C follows the PSK key exchange algorithm specified in Section 2 of [RFC4279], with the following additional requirements:

1. C sets the psk_identity field of the ClientKeyExchange message to the ticket Face received in the Ticket Transfer message.
2. C uses the ticket Verifier as PSK when constructing the premaster secret.

Note1: As RS cannot provide C with a meaningful PSK identity hint in response to C’s ClientHello message, RS SHOULD NOT send a ServerKeyExchange message.

Note2: According to [I-D.ietf-core-coap], CoAP implementations MUST support the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. C is therefore expected to offer at least this ciphersuite to RS.

Note3: The ticket is constructed by AS such that RS can derive the authorization information as well as the PSK (refer to Section 6 for details).

3.9. Authorized Resource Request Message

Successful establishment of the DTLS channel between C and RS ties the authorization information contained in the psk_identity field to this channel. Any request that RS receives on this channel is checked against these authorization rules. Incoming CoAP requests that are not Authorized Resource Requests MUST be rejected by RS with 4.01 response as described in Section 3.2.

RS SHOULD treat an incoming CoAP request as Authorized Resource Request if the following holds:

1. The message was received on a secure channel that has been established using the procedure defined in Section 3.8.
2. The authorization information tied to the secure channel is valid.
3. The request is destined for RS.
4. The resource URI specified in the request is covered by the authorization information.
5. The request method is an authorized action on the resource with respect to the authorization information.

Note that the authorization information is not restricted to a single resource URI. For example, role-based authorization can be used to authorize a collection of semantically connected resources simultaneously. Implicit authorization also provides access rights to authenticated clients for all actions on all resources that RS offers. As a result, C can use the same DTLS channel not only for subsequent requests for the same resource (e.g. for block-wise transfer as defined in [I-D.ietf-core-block] or refreshing observe-relationships [I-D.ietf-core-observe]) but also for requests to distinct resources.

Incoming CoAP requests received on a secure channel according to the procedure defined in Section 3.8 MUST be rejected

1. with response code 4.03 (Forbidden) when the resource URI specified in the request is not covered by the authorization information, and
2. with response code 4.05 (Method Not Allowed) when the resource URI specified in the request covered by the authorization information but not the requested action.

Since AS may limit the set of requested actions in its Ticket Grant message, C cannot know a priori if a an Authorized Resource Request will succeed.

4. Ticket

Access tokens in DCAF are tickets that consist of two parts, namely the Face and the Verifier.

4.1. Face

Face is the part of the ticket generated for RS. Face MUST contain all information needed for authorized access to a resource:

• Authorization Information
• Client Identifier
• A timestamp generated by AS

Optionally, Face MAY also contain:

• A lifetime (optional)
• A DTLS pre-shared key (optional)

RS MUST verify the integrity of Face, i.e. the information contained in Face stems from AS and was not manipulated by anyone else.

Face MUST contain a timestamp to verify that the contained information is fresh. As constrained devices may not have a clock, timestamps MAY be generated using the clock ticks since the last reboot. To circumvent synchronization problems the timestamp MAY be generated by RS and included in the first AS Information message. Alternatively, AS MAY generate the timestamp. In this case, AS and RS MUST use a time synchronization mechanism to make sure that RS interprets the timestamp correctly.

Face MAY be encrypted. If Face contains a DTLS PSK, the whole content of Face MUST be encrypted.

Note: The integrity of Face can be ensured by various means. Face may be encrypted by AS with a key it shares with RS. Alternatively, RS can use a mechanism to generate the DTLS PSK which includes Face and is only able to calculate the correct key with the correct Face (refer to Section 6 for details).

4.2. Verifier

The Verifier part of the ticket is generated for C. It contains the DTLS PSK for C. The Verifier MUST NOT be transmitted over insecure channels.

4.3. Revocation

The existence of access tickets SHOULD be limited in time. This can be achieved either by explicit Revocation Messages to invalidate a ticket or implicitly by attaching a lifetime to the ticket.

4.3.1. Lifetime

Tickets MAY have a lifetime. AS is responsible for defining the ticket lifetime. If AS sets a lifetime for a ticket, AS and RS MUST use a time synchronization method to ensure that RS is able to interpret the lifetime correctly. RS SHOULD end the DTLS connection to C if the lifetime of a ticket has run out and it MUST NOT accept new requests. RS MUST NOT accept tickets with an invalid lifetime.

Note: Defining reasonable ticket lifetimes is difficult to accomplish. How long a client needs to access a resource depends heavily on the application scenario and may be difficult to decide for AS.

4.3.2. Revocation Messages

AS MAY revoke tickets by sending a ticket revocation message to RS. If RS receives a ticket revocation message, it MUST end the DTLS connection to C and MUST NOT accept any further requests from C.

If ticket revocation messages are used, RS MUST check regularly if AS is still available. If RS cannot contact AS, it MUST end all DTLS connections and reject any further requests from C.

Note: The loss of the connection between RS and AS prevents all access to RS. This might especially be a severe problem if AS is responsible for several Resource Servers or even a whole network.

5. Payload Format and Encoding (application/dcaf+json)

Various messages types of the DCAF protocol carry payloads to express authorization information and parameters for generating the DTLS PSK to be used by C and RS. In this section, a representation in JavaScript Object Notation (JSON, [RFC4627]) is defined.

The following attributes are defined:

AS:

Authorization Server. This attribute denotes the authorization server that is in charge of the resource specified in attribute R. The attribute’s value is a string that contains an absolute URI according to Section 4.3 of [RFC3986].

AI:

Authorization Information. A data structure used to convey authorization information from AS to RS (see below).

CI:

Client Identity. A string that identifies the initiator of the authorization request. This label MAY be a fully qualified domain name, an IP address, or any other character literal that is used by the Authorization Server to decide whether or not access is granted to the requesting entity.

E:

Encrypted Ticket Face. A string containing an encrypted ticket Face encoded as base64 according to Section 4 of [RFC4648].

K:

Key. A string that identifies the shared key between RS and AS that can be used to decrypt the contents of E. If the attribute E is present and no attribute K has been specified, the default is to use the current session key for the secured channel between RS and AS.

M:

Methods. The list of actions to be performed on the resource R, encoded as an array of strings. In an authorization request, this list contains the actions that the initiator of the request wants to perform. In an authorization ticket, this attribute denotes the actions that are permitted.

R:

Resource. A string that denotes the absolute URI of the resource to be accessed. As the access ticket is requested in order to establish a DTLS connection with the server that hosts this resource, the URI scheme typically is “coaps”.

TS:

Time Stamp. An optional time stamp that indicates the instant when the access ticket request was formed. This attribute can be used by the resource server in an AS Information message to convey a time stamp in its local time scale (e.g. when it does not have a real time clock with synchronized global time). When the attribute’s value is encoded as a string, it MUST contain a valid UTC timestamp without time zone information. When encoded as integer, TS contains a system timestamp relative to the local time scale of its generator, usually RS.

L:

Lifetime. A lifetime of the ticket. When encoded as a string, L MUST denote the ticket’s expiry time as a valid UTC timestamp without time zone information. When encoded as an integer, L MUST denote the ticket’s validity period in seconds relative to TS.

G:

DTLS PSK Generation Method. A string that identifies the method that RS MUST use to derive the DTLS PSK from the ticket Face. This attribute MUST NOT be used when attribute V is present within the contents of F.

F:

Ticket Face. An object containing the fields AI, CI, TS, and optionally G, L and V.

V:

Ticket Verifier. A string containing the shared secret between C and RS, encoded as base64 according to Section 4 of [RFC4648].

The exact specification of AI is out of scope for this document. AI may, e.g., contain a single role identifier known by RS, or an array of pairs (M, R) with M and R defined as above.

As AI is used to authorize resource access as defined in Section 3.9, RS MUST be able to interpret the contained information.

5.1. Examples

The following example specifies an Authorization Server that will be accessed using HTTP over TLS. The request URI is set to “/a?ep=%5B2001:DB8::dcaf:1234%5D” (hence denoting the endpoint address to authorize). TS denotes a local timestamp in UTC.

POST /a?ep=%5B2001:DB8::dcaf:1234%5D HTTP/1.1
Host: as-rs.example.com
Content-Type: application/dcaf+json

{
  "AS": "https://as-rs.example.com/a?ep=%5B2001:DB8::dcaf:1234%5D",
  "CI": "2001:DB8::dcaf:1234",
  "M":  [ "GET" ],
  "R": "coaps://temp451.example.com/s/tempC",
  "TS": "2013-07-14T11:58:22.923"
}

The following example shows a ticket for the distributed key generation method (cf. Section 6.2), comprised of a Face (F) and a Verifier (V). The Face data structure contains authorization information AI with an application-specific role identifier, a client identifier, a timestamp using the local time scale of RS, and a lifetime relative to RS’s time scale.

The DTLS PSK Generation Method is set to “hmac_sha256” denoting that the distributed key derivation is used as defined in Section 6.2 with SHA-256 as HMAC function.

The Verifier V contains a shared secret to be used as DTLS PSK between C and RS.

HTTP/1.1 200 OK
Content-Type: application/dcaf+json

{
  "F": {
         "AI": { "Role" : 3 },
         "CI": "2001:db8:ab9:1234:7920:3133:ae5f:87",
         "TS": 2938749,
         "L":  3600,
         "G": "hmac_sha256"
       },
  "V": "zrPOuc6xzr/Pjc+Bz4TOuSDOvM61IM68zq3Ou865Cg=="
}

The Face may be encrypted as illustrated in the following example. Here, the field E carries an encrypted and base64-encoded Face data structure that contains the same information as the previous example, and an additional Verifier. Encryption was done with a secret shared by AS and RS. (This example uses AES128_CCM with the secret { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f } and RS’s timestamp { 0x00, 0x2C, 0xD7, 0x7D } as nonce.) Line breaks have been inserted to improve readability.

The attribute K describes the identity of the key to be used by RS to decrypt the contents of attribute E. Here, The value “key0” in this example is used to indicate that the shared session key between RS and AS was used for encrypting E.

{
  "E": "rjtolfjyX9q7Emxgsnz+nf0xTQhe1MjzZBRoIEW4vmSVlyJdW4KDgVtW
        LyBnQSVX0lmVpxUYbdNuk/5PkCOJBeex0obiEBC1UmKoJfJfjy7bLQhq
        k9HuJD7cvjHNOVZtNZf5qrxt7xJSoZFe6j/SJuxGNH/72SPDrdMQeXJI
        pX6vCJB698FcRDOXh/ipi9KT8YWeo/ljUMgJc+LI",
  "K": "key0",
  "V": "zrPOuc6xzr/Pjc+Bz4TOuSDOvM61IM68zq3Ou865Cg=="
}

The decrypted contents of E are depicted below (whitespace has been added to improve readability). The presence of the attribute V indicates that the DTLS PSK Transfer is used to convey the session key (cf. Section 6.1).

"F":{"AI":{"Role":3},
"CI":"2001:db8:ab9:1234:7920:3133:ae5f:87",
"TS":2938749,
"L":3600,
"V":"zrPOuc6xzr/Pjc+Bz4TOuSDOvM61IM68zq3Ou865Cg=="}

6. DTLS PSK Generation Methods

One goal of the DCAF protocol is to provide for a DTLS PSK shared between C and RS. AS and RS MUST negotiate the method for the DTLS PSK generation.

6.1. DTLS PSK Transfer

The DTLS PSK is generated by AS and transmitted to C and RS using a secure channel.

The DTLS PSK transfer method is defined as follows:

• AS generates the DTLS PSK using an algorithm of its choice
• AS MUST include a representation of the DTLS PSK in Face and encrypt it together with all other information in Face with a key K(AS,RS) it shares with RS. How AS and RS exchange K(AS,RS) is not in the scope of this document. AS and RS MAY use their preshared key as K(AS,RS).
• AS MUST include a representation of the DTLS PSK in the Verifier.
• As AS and C do not have a shared secret, the Verifier MUST be transmitted to C using encrypted channels.
• RS MUST decrypt Face using K(AS,RS)

6.2. Distributed Key Derivation

AS generates a DTLS PSK for C which is transmitted using a secure channel. RS generates its own version of the DTLS PSK using the information contained in Face (see also Section 4.1).

The distributed key derivation method is defined as follows:

• AS and RS both generate the DTLS PSK using the information. included in Face. They use an HMAC algorithm on Face with a shared key. The result serves as the DTLS PSK. How AS and RS negotiate the used HMAC algorithm is not in the scope of this document. They MAY however use the HMAC algorithm they use for their DTLS connection.
• AS MUST include a representation of the DTLS PSK in the Verifier.
• As AS and C do not have a shared secret, the Verifier MUST be transmitted to C using encrypted channels.
• AS MUST NOT include a representation of the DTLS PSK in Face.
• AS MUST NOT encrypt Face.

7. Authorization Configuration

For the protocol defined in this document, proper configuration of AS is crucial. The principal who owns the resources hosted by RS (i.e. the Resource Owner) needs to define permissions for the resources. The data representation of these permissions are not in the scope of this document.

8. Trust Relationships

C trusts AM, and RS trusts AS. Obviously, AM trusts C with the specific permissions it hands over to it. How this trust is established, is not in the scope of this document. It may be achieved by using a bootstrapping mechanism similar to [bergmann12].

Additionally, AS and AM need to have a trust relationship established. Its establishment is also not in the scope of this document. It fulfills the following conditions:

1. AS has means to authenticate AM (e.g. it has a certificate of AM or a PKI in which AM is included) and vice versa
2. As far as AS needs to rely on the different clients of AM to receive different permissions, it can be sure that AM correctly identifies these clients towards AS and does not leak tickets that have been generated for a specific client C to another client.

AS trusts C indirectly because it trusts AM and AM vouches for C. The DCAF Protocol does not provide any means for AS to validate that a resource requests stems from C.

C indirectly trusts AS with some potentially confidential information, and that AS correctly represents RS, because AM trusts AS.

AM trusts RS indirectly because it trusts AS and AS vouches for RS.

C implicitly trusts RS with some potentially confidential information because it trusts AM and because RS can prove that it shares a key with AS.

   AM <--------------------> AS

   /|\                      /|\
    |                        |
   \|/                      \|/

    C .....................  RS

9. Listing Authorization Server Information in a Resource Directory

CoAP utilizes the Web Linking format [RFC5988] to facilitate discovery of services in an M2M environment. [RFC6690] defines specific link parameters that can be used to describe resources to be listed in a resource directory [I-D.ietf-core-resource-directory].

This section defines a resource type “auth-request” that can be used by clients to retrieve the request URI for a server’s authorization service. When used with the parameter rt in a web link, “auth-request” indicates that the corresponding target URI can be used in a POST message to request authorization for the resource and action that are described in the request payload.

The Content-Format “application/dcaf+json” with numeric identifier TBD1 defined in this specification MAY be used to express access requests and their responses.

The following example shows the web link used by AM in this document to relay incoming Authorization Request messages to AS. (Whitespace is included only for readability.)

<client-authorize>;rt="auth-request";ct=TBD1
                  ;title="Contact Remote Authorization Server"

The resource directory that hosts the resource descriptions of RS could list the following description. In this example, the URI “ep/node138/a/switch2941” is relative to the resource context “coaps://as-rs.example.com/”, i.e. the authorization server AS.

<ep/node138/a/switch2941>;rt="auth-request";ct=TBD1;ep="node138"
                         ;title="Request Client Authorization"
                         ;anchor="coaps://as-rs.example.com/"

10. Examples

This section gives a number of short examples with message flows for the initial Unauthorized Resource Request and the subsequent retrieval of a ticket from AS. The notation here follows the role conventions defined in Section 1.2.1. The payload format is encoded as proposed in Section 5. The IP address of AS is 2001:DB8::1, the IP address of RS is 2001:DB8::dcaf:1234, and C’s IP address is 2001:DB8::c.

10.1. Access Granted

This example shows an Unauthorized PUT request from C to RS that is answered with an AS Information message. C then sends a POST request to AM with a description of its intended request. AM forwards this request to AS using CoAP over a DTLS-secured channel. The response from AS contains an access ticket that is relayed back to AM.

C --> RS
PUT a/switch2941 [Mid=1234]
Content-Format: application/senml+json
{e: [{"bv": "1"}]}

C <-- RS
4.01 Unauthorized  [Mid=1234]
Content-Format: application/dcaf+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941"}

C --> AM
POST client-authorize [Mid=1235,Token="tok"]
Content-Format: application/dcaf+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
 "CI": "2001:DB8::c",
 "M": [ "PUT" ],
 "R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941"
}

AM --> AS [Mid=23146]
POST ep/node138/a/switch2941
Content-Format: application/dcaf+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
 "CI": "2001:DB8::c",
 "M": [ "PUT" ],
 "R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941"
}

AM <-- AS
2.05 Content  [Mid=23146]
Content-Format: application/dcaf+json
{ "F": { "AI": { "R" : "a/switch2941", "M" : [ "GET", "PUT" ] },
         "CI": "2001:DB8::c",
         "TS": "2013-07-04T20:17:38.002,
         "G": "hmac_sha256"
       },
  "V": "yYVLYZZ5Nssbn0by3fqel9WK6jHdoYyNej2d/kSuBLw="
}

C <-- AM
2.05 Content  [Mid=1235,Token="tok"]
Content-Format: application/dcaf+json
{ "F": { "AI": { "R" : "a/switch2941", "M" : [ "GET", "PUT" ] },
         "CI": "2001:DB8::c",
         "TS": "2013-07-04T20:17:38.002",
         "G": "hmac_sha256"
       },
  "V": "MR5TMrNngbSEAkFl0akmsdbmzF0gqxGI/d3KjwT8GxI="
}

C --> RS
ClientHello (TLS_PSK_WITH_AES_128_CCM_8)

C <-- RS
ServerHello (TLS_PSK_WITH_AES_128_CCM_8)
ServerHelloDone

C --> RS
ClientKeyExchange
  psk_identity='"F":{"AI":{"R":"a/switch2941","M":["GET","PUT"]},
                     "CI": "2001:DB8::c",
                     "TS": "2013-07-04T20:17:38.002",
                     "G": "hmac_sha256"')

(C decodes the contents of V and uses the result as PSK)
ChangeCipherSpec
Finished

(RS calculates PSK from AI, CI, TS and its session key
 HMAC_sha256("{\"R\":\"a/switch2941\",\"M\":[\"GET\",\"PUT\"]}"+
             "2001:DB8::c"+"2013-07-04T20:17:38.002",
             "secret")
= 311e5332b36781b484024165d1a926b1d6e6cc5d20ab1188fdddca8f04fc1b12
)

C <-- RS
ChangeCipherSpec
Finished

10.2. Access Denied

This example shows a denied Authorization request for the DELETE operation.

C --> RS
DELETE a/switch2941

C <-- RS
4.01 Unauthorized
Content-Format: application/dcaf+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941"}

C --> AM
POST client-authorize
Content-Format: application/dcaf+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
 "CI": "2001:DB8::c",
 "M": [ "DELETE" ],
 "R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941"
}

AM --> AS
POST ep/node138/a/switch2941
Content-Format: application/dcaf+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
 "CI": "2001:DB8::c",
 "M": [ "DELETE" ],
 "R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941"
}

AM <-- AS
2.05 Content
Content-Format: application/dcaf+json

C <-- AM
2.05 Content
Content-Format: application/dcaf+json

10.3. Access Restricted

This example shows a denied Authorization request for the operations GET, PUT, and DELETE. AS grants access for PUT only.

AM --> AS
POST ep/node138/a/switch2941
Content-Format: application/dcaf+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
 "CI": "2001:DB8::c",
 "M": [ "GET", "PUT", "DELETE" ],
 "R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941"
}

AM <-- AS
2.05 Content
Content-Format: application/dcaf+json
{ "F": { "AI": { "R" : "a/switch2941", "M" : [ "GET", "PUT" ] },
         "CI": "2001:DB8::c",
         "TS": "2013-07-04T21:33:11.930",
         "G": "hmac_sha256"
       },
  "V": "NZ8Q3o8P4eHOzkoscaUpoRvrn5d74Cscw/aXAiNmC/k="
}

10.4. Implicit Authorization

This example shows an Authorization request using implicit authorization. AM initially requests the actions GET and POST on the resource “coaps://[2001:DB8::dcaf:1234]/a/switch2941”. AS returns a ticket that has no AI field in its ticket Face, hence implicitly authorizing C.

AM --> AS
POST ep/node138/a/switch2941
Content-Format: application/dcaf+json
{"AS": "coaps://[2001:DB8::1]/ep/node138/a/switch2941",
 "CI": "2001:DB8::c",
 "M": [ "GET", "POST" ],
 "R": "coaps://[2001:DB8::dcaf:1234]/a/switch2941"
}

AM <-- AS
2.05 Content
Content-Format: application/dcaf+json
{ "F": { "CI": "2001:DB8::c",
         "TS": "2013-07-16T10:15:43.663",
         "G": "hmac_sha256"
       },
  "V": "mCYtLG/oZIWki/mCFNJ4nxI0WMPwlDKAnXIo/ir2dtI="
}

11. Security Considerations

As this protocol builds on transitive trust between authorization servers as mentioned in Section 8, AS has no direct means to validate that a resource request originates from C. It has to trust AM that it correctly vouches for C and that it does not give authorization tickets meant for C to another client nor disclose the contained session key.

The Authorization Server also could constitute a single point of failure. If the Authorization Server fails, the resources on all Resource Servers it is responsible for cannot be accessed any more. Thus, it is crucial for large networks to use Authorization Servers in a redundant setup.

12. IANA Considerations

The following registrations are done following the procedure specified in [RFC6838].

Note to RFC Editor: Please replace all occurrences of “[RFC-XXXX]” with the RFC number of this specification.

12.1. dcaf+json Media Type Registration

Type name: application

Subtype name: dcaf+json

Required parameters: none

Optional parameters: none

Encoding considerations: Must be encoded as using a subset of the encoding allowed in [RFC4627]. Specifically, only the primitive data types String and Number are allowed. The type Number is restricted to unsigned integers (i.e., no negative numbers, fractions or exponents are allowed). Encoding MUST be UTF-8. These restrictions simplify implementations on devices that have very limited memory capacity.

Security considerations: TBD

Interoperability considerations: TBD

Published specification: [RFC-XXXX]

Applications that use this media type: TBD

Additional information:

Magic number(s): none

File extension(s): dcaf

Macintosh file type code(s): none

Person & email address to contact for further information: TBD

Intended usage: COMMON

Restrictions on usage: None

Author: TBD

Change controller: IESG

12.2. CoAP Content Format Registration

This document specifies a new media type application/dcaf+json (cf. Section 12.1). For use with CoAP, a numeric Content-Format identifier is to be registered in the “CoAP Content-Formats” sub-registry within the “CoRE Parameters” registry.

Note to RFC Editor: Please replace all occurrences of “RFC-XXXX” with the RFC number of this specification.

Media type	Encoding	Id.	Reference
application/dcaf+json	-	TBD1	[RFC-XXXX]

13. References

13.1. Normative References

[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986]	Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC4279]	Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC6838]	Freed, N., Klensin, J. and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[RFC4648]	Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC6347]	Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[I-D.ietf-core-coap]	Shelby, Z., Hartke, K. and C. Bormann, "Constrained Application Protocol (CoAP)", Internet-Draft draft-ietf-core-coap-18, June 2013.

13.2. Informative References

[RFC4627]	Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5988]	Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC6655]	McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, July 2012.
[RFC6690]	Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, August 2012.
[bergmann12]	Bergmann, O., Gerdes, S., Schaefer, S., Junge, F. and C. Bormann, "Secure Bootstrapping of Nodes in a CoAP Network", IEEE Wireless Communications and Networking Conference Workshops (WCNCW), April 2012.
[I-D.ietf-core-block]	Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", Internet-Draft draft-ietf-core-block-13, October 2013.
[I-D.ietf-core-observe]	Hartke, K., "Observing Resources in CoAP", Internet-Draft draft-ietf-core-observe-11, October 2013.
[I-D.ietf-core-resource-directory]	Shelby, Z., Krco, S. and C. Bormann, "CoRE Resource Directory", Internet-Draft draft-ietf-core-resource-directory-00, June 2013.

Authors' Addresses