Subject: [Ace] General Solution Framework for ACE

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 22 Oct 2015 10:28:09 +0200

Hi,

We submitted the ACE Solutions draft [1] that presents a general
solution framework for the Privacy-Enhanced Tokens [2] and DCAF [3].

We updated DCAF accordingly. The new version also addresses Renzo's
comments and contains more explanatory text how DCAF payloads can be
transferred using COSE. More details about how DCAF works with object
security can be found in the new DCAF-COSE draft [4].

Moreover, we submitted the Server-Initiated Ticket Request (SITR) draft
[5] that explains how a (possibly constrained) server can request a
ticket for a (possibly constrained) client that represents the mutual
authentication and authorization of the Client Authorization Manager and
the Server Authorization Manager.

Comments are very welcome.

Best regards,
Steffi

[1] https://tools.ietf.org/html/draft-cuellar-ace-solutions-00
[2]
https://tools.ietf.org/id/draft-cuellar-ace-pat-priv-enhanced-authz-tokens-01.txt
[3] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04
[4] https://tools.ietf.org/html/draft-bergmann-ace-dcaf-cose-00
[5] https://tools.ietf.org/id/draft-gerdes-ace-dcaf-sitr-00.txt

-- 
Stefanie Gerdes			Tel: +49 421 218 63906
TZI Universität Bremen		E-Mail: [email-masked]
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany

---

From: Göran Selander <[email-masked]>
Date: Fri, 23 Oct 2015 06:26:16 +0000

Hi Steffi and Olaf,

It seems to me that DCAF claims to provide security on application layer
through intermediary nodes, such as CoAP proxies, but fails to do so.

The construction you make in [4] integrity protects options that are
unsafe and may be changed by a CoAP proxy. Hence the MAC calculated by the
client will be different from the MAC calculated by the server and the
message will be rejected, despite this being a legitimate proxy operation.

Details are in [4]:

Section 1:
"In the presence of intermediaries such as, e.g., CoAP proxies, channel
security may not be applicable for all configurations.  If this is the
case, the exchanged information must be protected at the application level
to help achieving the principals' security requirements. "

"This specification uses this CBOR Encoded Message Syntax
[I-D.ietf-cose-msg] to protect the DCAF protocol flow on the application
level."

Section 2.1:
"a COSE_Mac structure used to integrity-protect the request"

"Note that the integrity protection not only covers the message payload
but also the content type and various sensitive CoAP options such as
Uri-Path that will be passed to the MAC creation functions as
canonicalized external_aad as described in Section 6."

Section 6 lists the options which are integrity protected including
Uri-Host, Observe, Uri-Port, Uri-Path, Uri-Query, Proxy-Uri and
Proxy-Scheme, which are unsafe. E.g. Proxy-Uri is split by a forward proxy
into Uri-Host, Uri-Port, Uri-Path, and Uri-Query, as explained in RFC7252
section 5.7.2:

"CoAP requests to a forward-proxy are made as normal Confirmable or
Non-confirmable  requests to the forward-proxy endpoint, but they specify
the request URI in a different way: The request URI in a proxy request is
specified as a string in the Proxy-Uri Option (see Section 5.10.2), while
the request URI in a request to an origin server is split into the
Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options (see Section 5.10.1)."

Göran

On 2015-10-22 10:28, "Stefanie Gerdes" <[email-masked]> wrote:

>_______________________________________________
>Ace mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ace