Subject: [Ace] some questions andcomments about dcaf and documents

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Feb 2014 08:53:15 -0500

I have just read draft-selander-core-access-control-01 and
draft-gerdes-core-dcaf-authorize-01.

(I think that I read them because they were mentioned as background for ace,
but my reading list doesn't actually record why I'm suppposed to read
drafts...)

Question 1 are these competing proposals, or is X more of a requirements, and
Y more of a protocol?

Question 2: in dcaf-01, section 4, Face and Ticket. It seems like the Face
should go to the Client, and Ticket should go to the RS.  The text implies the
opposite, or at least is perhaps written from the point of view of the node
which verifies things.  If it is correctly written, then it seems that the RS
has to keep track of all the clients, and the clients just need to keep track
of a single DTLS PSK.

Comment on dcaf-01: I think that there may be too many MAYs that will affect
interoperability.   I noticed this first in section 4.1 about timestamps.
Section 5, says the AI definition is out of scope.  Where will it be *in*
scope?    It seems to be a URLish kind of thing in one example, and a json
object in another.

I like section 8.
thank you for including section 10.
this is a very mature document.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 13 Feb 2014 15:14:09 +0100

> Question 1 are these competing proposals, or is X more of a requirements, and

My personal take as a co-author is this:

Originally you could call them competing proposals (draft versions 00), 
but we decided to try and align them as far as possible, where 
draft-selander is supposed present the high level concepts and 
rationales (as informational draft) and dcaf would be one proposal of 
how to implement these.

I daresay we agree on the general principles but our opinions diverge in 
some of the details.

/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 92 51
http://www.sics.se

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Feb 2014 15:40:32 +0100

> scope?    It seems to be a URLish kind of thing in one example, and a json

We were trying for a separation of concerns here.

A strawman AIF is in draft-bormann-core-ace-aif-00.txt
We hope this can evolve on a separate timeline from DCAF itself, and stay pluggable for more complex requirements.

Grüße, Carsten

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 13 Feb 2014 17:34:48 +0100

On 02/13/2014 02:53 PM, Michael Richardson wrote:
> 
> Question 2: in dcaf-01, section 4, Face and Ticket. It seems like
> the Face should go to the Client, and Ticket should go to the RS.
> The text implies the opposite, or at least is perhaps written from
> the point of view of the node which verifies things.  If it is
> correctly written, then it seems that the RS has to keep track of
> all the clients, and the clients just need to keep track of a
> single DTLS PSK.

The Face goes to RS, the Verifier goes to the Client. The Face and the
Verifier are parts of the same ticket.

RS needs the information contained in the Ticket Face to authorize the
client and RS must be sure that AS generated the Ticket Face (RS can't
make authorization decisions by itself and needs AS to do it). No
additional information about the Client is needed. RS keeps the Ticket
Face as long as it is valid.

Does that answer your question?

Best regards,
Steffi

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Feb 2014 17:21:30 -0500

> Verifier are parts of the same ticket.

I was rather hoping that the ticket would go to the client (encrypted to the
RS), and the client would present the ticket when it creates the DTLS session
(somewhere in a ClientCertificate-like TLV).

This would let the protocol scale better since the RS could forget about
state on a LRU basis, and the clients, upon sensing that the DTLS session was
gone, could recreate it.

Also, while I'm kerberos expert, I would like us to at least go read the some
kerberos terminology expert, and make sure that we either use consistent
terms or have a mapping, and where we have terms that differ in definition,
we clarify what is going on.

---

From: Olaf Bergmann <[email-masked]>
Date: Sun, 16 Feb 2014 18:41:15 +0100

Michael,

> (somewhere in a ClientCertificate-like TLV).

This is exactly what happens (though encryption of the ticket Face is
optional -- we had a discussion with Ludwig Seitz who convinced us that
there might be use cases where the client needs to know its exact
authorization in case it has asked for more than it actually needs in
the first place).

> state on a LRU basis, and the clients, upon sensing that the DTLS session was

RS keeps state (i.e. stores the authorization information contained in
the ticket face) as long as the DTLS session exsists and the ticket is
valid. It needs to keep it this duration to be able to check
authorization for each request that is sent over this DTLS channel (and
for each notification generated for observed resources).

We had two reasons for designing it this way:

1. RS needs to store authorization information for the client anyway to
   enable observe. Notification should not be sent to the client when
   the ticket has expired or the DTLS session has been terminated.

2. Presenting the ticket with every CoAP request from the client would
   enlarge the message size significantly -- potentially leading to
   message fragmentation.

> we clarify what is going on.

We tried to avoid using any kerberos terminology at all to avoid
confusion.

Gruesse
Olaf

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 17 Feb 2014 08:59:55 +0100

> We tried to avoid using any kerberos terminology at all to avoid

Also note that Kerberos is an authentication protocol, and while it 
certainly can be extended to perform some authorization functions, this 
is not part of the Kerberos standard (see section 1.4 RFC4120).

We all agree that authenticating some property of the client is a 
necessary first step for authorization, but lets not forget about the 
other necessary steps ....

/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 92 51
http://www.sics.se

---

From: Göran Selander <[email-masked]>
Date: Mon, 17 Feb 2014 09:56:56 +0000

Hi

>I daresay we agree on the general principles but our opinions diverge in

In light of the new versions I would like to add a little to the
relationship between the ACF and DCAF drafts.

On a high level ACF and DCAF are very similar: Architecture, roles,
message flow, trust model, etc.

ACF provides a background and rationale for this architecture. However
there are a number of remaining design choices, e.g.

- New design vs re-use of existing protocol

- symmetric vs asymmetric keys for authenticating client/ resource server
- symmetric vs asymmetric keys for authentication of authorisation server
- communication security vs object security between client/server
- transport of access token in DTLS vs CoAP

ACF is written to allow different solutions making different choices. DCAF
has made the choices and propose solution in exquisite detail.

Göran