Subject: Re: [Ace] CoAP option for Access token

From: Carsten Bormann <[email-masked]>
Date: Mon, 01 Feb 2016 10:59:37 +0100

How is the token bound to the current request?  To the next request?
I have trouble following the conversation because I don't understand
what the assumptions are about protection (integrity/authentication of
the message being specifically authorized by using the token; also of
course confidentiality of the token).

In a constrained environment, it is probably better to establish the
access (authorization) in a separate transaction and bind this to a
specific request via the communication state.  This should be done
explicitly (e.g., during connection establishment or by using a RESTful
mechanism bound to the connection after connection establishment).

Grüße, Carsten

Ludwig Seitz wrote:
> Wouldn't it still be possible for the RS to save a token sent in an option?
> Would it then not be possible for the client to remember that it already
> sent this token in a previous request (and that it is still valid)?
> Would the client then not be able to omit it from further requests
> (until it is no longer valid)?

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 1 Feb 2016 11:47:11 +0100

>> (until it is no longer valid)?

The underlying assumption is that the token is a proof-of-possession 
token, i.e. that it is associated with a key (symmetric or asymmetric) 
that the client possesses and that the RS can verify possession of.

The binding of the token to a request happens by either using that key 
to establish session security (e.g. as PSK or RPK for DTLS), or by using 
that key in an object security protocol and using that protocol to 
secure the request.

Could you exemplify what you mean with "by using a RESTful
mechanism bound to the connection after connection establishment" I'm 
not sure I'm following you here.

Regards,

Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70 349 9251
http://www.sics.se

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 01 Feb 2016 12:07:31 +0100

> that key in an object security protocol and using that protocol to

OK, both kinds of communication security (via DTLS or via an "object
security" protocol above DTLS) establish a security session that can be
bound to, using the PoP token once, not per request.

> not sure I'm following you here.

As in

POST /authorize

(Note that since we are in an authenticated session, this is just about
establishing additional authorization, not about re-authenticating
either side.  The server needs to bind that authorization to the session.)

Look, Ma, no option :-)
(Except for protecting the message in any "object security" session, if
needed.)

Grüße, Carsten

---

From: Erik Wahlström <[email-masked]>
Date: Tue, 2 Feb 2016 14:28:03 +0100

Hi,

I think an Access-Token option (or Bearer as in https://tools.ietf.org/html/rfc6750#section-2.1 <https://tools.ietf.org/html/rfc6750#section-2.1>?) is a good thing if both client and resource server knows that it’s such a small token. I do however think it’s an optimisation and that it’s something that could be sorted later on (maybe even in an future optimisation extension).

/ Erik

> On 30 Jan 2016, at 22:48, Samuel Erdtman <[email-masked]> wrote:
> 
> Hi,
> 
> Working on the draft-ietf-ace-oauth-authz draft I see the need for a CoAP Option to send access token in. This option can be used when token is smaller then 255 bytes. Then it comes down to the trade-of between sending the access token once to the authorization information resource at the RS and sending it in each request as this option.
> 
> Can we agree that we need this option?
> Should we call it Access-Token or is that to specific?
> 
> Best Regards
> //Samuel
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Samuel Erdtman <[email-masked]>
Date: Tue, 2 Feb 2016 20:52:05 +0100

Hi,

I think there is one key benefit of being able to send the access token as
an option, if the access token is included as an option the request can be
self contained i.e. one operation one request with the access token to
prove the rights to do the operation. I think this is useful for operations
where the token is used once or very seldom, then it is beneficial not
having to send first the token and then do the operation. Further by having
the self contained request (access token + operation) the RS does not need
to store session data and can in that way serve more clients and If I
remember correctly statelessness  is one of the key constraints of RESTful
design.

In the current draft we mention an authorization information resource on
the RS in the current working draft it is further detailed. This resource
on the RS is meant to be used before the security context (session) has
been established. The POST request to the authorization information
resource contains the PoP token i.e. an encrypted or signed token that
transports the credentials (key) of the client to the RS protected by the
AS. Then the key of the client from the token is used for the
secure communication DTLS or object security.

Best regards
// Samuel

On Tue, Feb 2, 2016 at 2:28 PM, Erik Wahlström <[email-masked]>
wrote:

> Hi,
>
> I think an Access-Token option (or Bearer as in
> https://tools.ietf.org/html/rfc6750#section-2.1?) is a good thing if both
> client and resource server knows that it’s such a small token. I do however
> think it’s an optimisation and that it’s something that could be sorted
> later on (maybe even in an future optimisation extension).
>
> / Erik
>
>
>
> Working on the draft-ietf-ace-oauth-authz draft I see the need for a CoAP
> Option to send access token in. This option can be used when token is
> smaller then 255 bytes. Then it comes down to the trade-of between sending
> the access token once to the authorization information resource at the RS
> and sending it in each request as this option.
>

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 5 Feb 2016 13:38:12 +0100

> (Except for protecting the message in any "object security" session, if

Question to the list: in draft-ietf-ace-oauth-authz the default way to 
transfer authorization tokens C-->RS is POSTing it to an authorization 
resource at the RS (identical to what Carsten suggests here).
We also discuss some alternatives, optimized for specific situations in 
appendix C:
1. Using the TLS supplemental data extension [RFC4680] with TLS or DTLS
2. Using a CoAP option (for very small tokens, e.g. reference tokens)

Do we need these options?

These having such options means that we have to specify some signaling 
from the AS to the client, telling it which token transfer method to use.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70 349 9251
http://www.sics.se

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 05 Feb 2016 14:53:01 +0100

Using credentials for creating DTLS connections has the advantage that
you get mutual authentication at the constrained layer pretty much for
free.  The disadvantage is that upgrading authorizations requires a
separate mechanism (e.g., POST).

I'm not seeing much use for a per-request authorization options, but
apparently others do.

The presence of a POSTable authorization resource could be signalled
using the normal hypermedia controls (e.g., /.well-known/source).

We typically contain connection-setup information (IP adresses and port
numbers) in the URIs, but the way (D)TLS is parameterized from the URI
is inadequate.  (Just having the "s" bit is adequate only for a
homogeneous PKI world such as the big Web.)  So that requires some
innovation.

Innovation would also be required for soliciting per-request
authorization options.  In HTTP, we have 401 and WWW-Authenticate for
this.  In CoAP, the WWW-Authenticate style information could also be
part of a 4.01 payload (saving the use of another option in exchange for
defining another media type).  (The 4.01 payload can also be used to
initiate upgrading to a DTLS connection, so that would solve some of the
above as well.  See DCAF-COSE.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 05 Feb 2016 15:06:52 +0100

> /.well-known/source

That must be my DYAC of the week...

/.well-known/core, of course.

Grüße, Carsten