Using The Delegated CoAP Authentication and Authorization Framework - - PowerPoint PPT Presentation

▶
using the delegated coap authentication and authorization
SMART_READER_LITE
LIVE PREVIEW

Using The Delegated CoAP Authentication and Authorization Framework - - PowerPoint PPT Presentation

Oct 10, 2023 311 likes •504 views

Using The Delegated CoAP Authentication and Authorization Framework (DCAF) With CBOR Encoded Message Syntax draft-bergmann-ace-dcaf-cose Olaf Bergmann, Stefanie Gerdes { gerdes | bergmann } @tzi.org Presented by Carsten Bormann cabo@tzi.org

slide-1
SLIDE 1

Using The Delegated CoAP Authentication and Authorization Framework (DCAF) With CBOR Encoded Message Syntax

draft-bergmann-ace-dcaf-cose Olaf Bergmann, Stefanie Gerdes {gerdes | bergmann}@tzi.org Presented by Carsten Bormann cabo@tzi.org IETF-94, ACE Meeting, 2015-11-02

1 / 18

slide-2
SLIDE 2

Motivation

◮ draft-gerdes-ace-dcaf-authorize

◮ Secure exchange of authorization information. ◮ Establish DTLS channel between constrained nodes. ◮ Support of class-1 devices (RFC 7228). ◮ Support cross-domain, multi-owner scenarios.

◮ draft-bergmann-ace-dcaf-cose

◮ Re-use light-weight DCAF messaging ◮ Support for application-level security using COSE objects ◮ Enable piggybacked protected content use-case 2 / 18

slide-3
SLIDE 3

Observation: DCAF Messages are not tied to DTLS

CAM SAM C S

Access Request Access Ticket

3 / 18

slide-4
SLIDE 4

Nor is the Ticket Data

CAM SAM C S

Access Request

Access Ticket

Face: Client Information:

[server authorization info] nonce [lifetime] verifier (session key) [client authorization info, nonce] [lifetime]

4 / 18

slide-5
SLIDE 5

DCAF-Messages can be protected with COSE

Example: Access Request

POST /client-authorize Content-Format: application/cose+cbor [ h'a1031862', # protected { content_type: application/dcaf+cbor } { alg: AES-CCM-16-64-128 # unprotected nonce: h'd6150b90e6f0eb5be42164062c', # nonce }, h'{encrypted payload w/ tag}', # encrypted DCAF payload # recipients: [ [ h'', # protected (absent for AE algorithm) { alg: A128KW, # unprotected kid: h'383261622e6161733432' # context identifier: "82ab.aas42" }, h'52ff9ed52d...' # encrypted session key ] ] ]

5 / 18

slide-6
SLIDE 6

DCAF-Messages can be protected with COSE

Example: Access Request

POST /client-authorize Content-Format: application/cose+cbor [ h'a1031862', # protected { content_type: application/dcaf+cbor } { alg: AES-CCM-16-64-128 # unprotected nonce: h'd6150b90e6f0eb5be42164062c', # nonce }, h'{encrypted payload w/ tag}', # encrypted DCAF payload # recipients: [ [ h'', # protected (absent for AE algorithm) { alg: A128KW, # unprotected kid: h'383261622e6161733432' # context identifier: "82ab.aas42" }, h'52ff9ed52d...' # encrypted session key ] ] ]

6 / 18

slide-7
SLIDE 7

Key Derivation

CAM SAM C S

Security Association

transfer Ticket Face during setup use session key from Verifier (direct

  • r derived)

derive session key from Ticket Face and K S,SAM

7 / 18

slide-8
SLIDE 8

Convey Ticket Face from C to S

POST /authorize Content-Format: application/cose+cbor [ h'a1031862', # protected { content_type: application/dcaf+cbor } { alg: HMAC 256/256 }, # unprotected h'{ SAI: [ "/s/tempC" ... }', # DCAF payload wrapped in CBOR binary h'....', # tag: HMAC(options+protected+payload, secret) [ [ h'', {}, h'' ] ] # recipients ]

8 / 18

slide-9
SLIDE 9

Convey Ticket Face from C to S

POST /authorize Content-Format: application/cose+cbor [ h'a1031862', # protected { content_type: application/dcaf+cbor } { alg: HMAC 256/256 }, # unprotected h'{ SAI: [ "/s/tempC" ... }', # DCAF payload wrapped in CBOR binary h'....', # tag: HMAC(options+protected+payload, secret) [ [ h'', {}, h'' ] ] # recipients ]

9 / 18

slide-10
SLIDE 10

Creation of Security Context

POST /authorize Content-Format: application/cose+cbor [ h'a1031862', # protected { content_type: application/dcaf+cbor } { alg: HMAC 256/256 }, # unprotected h'{ SAI: [ "/s/tempC" ... }', # DCAF payload wrapped in CBOR binary h'....', # tag: HMAC(options+protected+payload, secret) [ [ h'', {}, h'' ] ] # recipients ] 2.01 Created Content-Format: application/cose+cbor Location-Path: 238dsa29 Authorization: [ h'a1031862', # protected { alg: HMAC 256/256 }, # unprotected h'', # empty payload h'....', # tag: HMAC(options+protected, secret) [ [ h'', {}, h'' ] ] # recipients ]

10 / 18

slide-11
SLIDE 11

Creation of Security Context

POST /authorize Content-Format: application/cose+cbor [ h'a1031862', # protected { content_type: application/dcaf+cbor } { alg: HMAC 256/256 }, # unprotected h'{ SAI: [ "/s/tempC" ... }', # DCAF payload wrapped in CBOR binary h'....', # tag: HMAC(options+protected+payload, secret) [ [ h'', {}, h'' ] ] # recipients ] 2.01 Created Content-Format: application/cose+cbor Location-Path: 238dsa29 Authorization: [ h'a1031862', # protected { alg: HMAC 256/256 }, # unprotected h'', # empty payload h'....', # tag: HMAC(options+protected, secret) [ [ h'', {}, h'' ] ] # recipients ]

derived from Ticket Face and KS,SAM used as security context identifier new option

11 / 18

slide-12
SLIDE 12

Usage of Security Context

without payload

GET /r Authorization: [ h'', # protected (empty) { alg: HMAC 256/256, # unprotected kid: h'3233386473613239' # context identifier: "238dsa29" }, nil, # payload (empty) h'....', # tag: HMAC(options+protected, secret) [ [ h'', {}, h'' ] ] # recipients ]

12 / 18

slide-13
SLIDE 13

Usage of Security Context

without payload

GET /r Authorization: [ h'', # protected (empty) { alg: HMAC 256/256, # unprotected kid: h'3233386473613239' # context identifier: "238dsa29" }, nil, # payload (empty) h'....', # tag: HMAC(options+protected, secret) [ [ h'', {}, h'' ] ] # recipients ]

as returned in Location-Path

13 / 18

slide-14
SLIDE 14

Usage of Security Context

with payload

GET /r Authorization: [ h'', # protected (empty) { alg: HMAC 256/256, # unprotected kid: h'3233386473613239' # context identifier: "238dsa29" }, nil, # payload (empty) h'....', # tag: HMAC(options+protected, secret) [ [ h'', {}, h'' ] ] # recipients ] PUT /r Content-Format: application/cose+cbor [ h'a10300', # protected { content_type: text/plain } { alg: HMAC 256/256, # unprotected kid: h'3233386473613239' # context identifier: "238dsa29" }, h'48656c6c6f20576f726c6421', # payload: "Hello World!\n" h'....', # tag: HMAC(options+protected+payload, secret) [ [ h'', {}, h'' ] ] # recipients ]

as returned in Location-Path

14 / 18

slide-15
SLIDE 15

Usage of Security Context

with payload

GET /r Authorization: [ h'', # protected (empty) { alg: HMAC 256/256, # unprotected kid: h'3233386473613239' # context identifier: "238dsa29" }, nil, # payload (empty) h'....', # tag: HMAC(options+protected, secret) [ [ h'', {}, h'' ] ] # recipients ] PUT /r Content-Format: application/cose+cbor [ h'a10300', # protected { content_type: text/plain } { alg: HMAC 256/256, # unprotected kid: h'3233386473613239' # context identifier: "238dsa29" }, h'48656c6c6f20576f726c6421', # payload: "Hello World!\n" h'....', # tag: HMAC(options+protected+payload, secret) [ [ h'', {}, h'' ] ] # recipients ]

as returned in Location-Path

15 / 18

slide-16
SLIDE 16

Open Issues

◮ protection of changeable CoAP options (-> CoRE WG) ◮ describe how to apply key derivation methods from

draft-ietf-cose-msg

16 / 18

slide-17
SLIDE 17

Summary

◮ DCAF-COSE supports application-level security using COSE

  • bjects

◮ use plain COSE as described in draft-ietf-cose-msg ◮ two new CoAP options:

◮ Authorization: convery authorization information ◮ Authorization-Format: allow for future extensions 17 / 18

slide-18
SLIDE 18

DCAF-COSE vs. OSCOAP

DCAF-COSE OSCOAP Changes to COSE use COSE as is (-06) no changes required Replay protection use parameter nonce (-> local time) invent new parameter seq (-> sequence number, no freshness information) Security Context use parameter kid (identifies auth info and session key) invent new parameter cid (identifies cipher suite, keys, alg-specific parameters, different for client and server: "typically identifies the sending party") invent "Secure Message format" (COSE-profile in Appendix A) invent "COSE Optimizations" that are not COSE- compatible (new message types, remove unprot- ected header, alg ...) Re-key Server sends SAM Information Message "out of scope" (Section 7.1) Signaling use existing payload types implicit, new payload type new critical option two new options (not critical due to usual content-format handling)

Handling

  • f unknown
  • ptions

COSE extension parameter to signal required options not supported

RFC 7252, 7641 options block-wise

needs more work in CoRE WG

18 / 18