Subject: [Ace] DCAF Review (draft-gerdes-ace-dcaf-authorize)

From: Renzo Navas <[email-masked]>
Date: Mon, 14 Sep 2015 15:01:19 +0200

Good Afternoon ACE ML,

I send here a review of DCAF
https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-02
version 02, though most of comments applies for -recent- 03.

I want to publicly thank to the authors of DCAF (Steffi, Olaf, Carsten),
I found it a very useful document (very detailed), I found it one of
the most 'mature' ACE architectures, and with a lot of pointers to
take it to reality from an implementation point of view. In fact at my
everyday-work we want some AA Architecture for IoT, and are trying to
push something like DCAF, though I'm interested on trying to offer
COSE security instead of DTLS.

This is my first review ever, so sorry in advance for my inexperience.
I have a software development background, so I believe most of my
comments come from an implementation point of view. In the last months
I've been trying to get more on the AA and security world.

I've been following the ACE working group for some months now, and I
really appreciate the effort of all of you.
I hope to start contributing more, and these are my two cents for now.

Have a good start of the week

Renzo

--------------------------------------

DCAF Review

>1.2.1 Actors
Harmonize definitions with draft-ietf-ace-actors-00:
S -- RS  ;  SAM -- AS ; CAM -- CAS ;  AM -- ?? (how to map AM concept
into actors draft, needs discussion?) ;
COP -- RqP;  ROP -- RO

>1.2.2. Other Terms

"Verifier" (can be clarifying to mention on parentheses an example of
a verifier?, for instance adding : Verifier e.g: information
representing a 128-bit PSK)

Should not be useful to define CAI , SAI?
They are defined on Section 5. but before the formal definition they
are used a lot.

>3. Protocol
>    2 . transfer of access request and respective ticket grants
Change “ticket grants” for "ticket transfer" (C and CAM transfer
what's been defined as Ticket Transfer)?

>    3 . transfer of access request and respective ticket grants
Change “access request” for "ticket requests" (SAM and CAM transfer
what's been defined as Ticket Requests)?

> 3.2 “insecure channel” ('insecure' or 'unsecured' -or 'non-secured'-?
I could not find any formal definition on RFCs.  rfc4949 mentions
“unsecured networks”,
I found this discussion
http://english.stackexchange.com/questions/19653/insecure-or-unsecure-when-dealing-with-security
I point this to raise the discussion, does RFC4949 suffice or we need
more -rfc- security glossary?

> 3.5 Ticket Request,

Should not 4.03 be sent only if ALL of the requested actions are forbidden?
Stated otherwise, if at least one action is not forbidden then CAM
attempts a ticket Request. (if this is the case, should this be stated
clearer on the text?)

The ticket request will be for all actions C specified (even the ones
not allowed) or CAM will change the SAI according to COP’s policies?

About the Label for client:

“5. A label that describes the Client is added to the payload” see
comment on 10.1, what role plays this label (for my understanding does
not play any role), what is the format of the label (on the examples
is missing)?
OK, I think this point is here from previous versions of document,
should be removed?

>3.6 Ticket Grant Message
   "When access is granted, the data structure contains the Ticket Face, the
   Client Information, which at this point only consists of the Verifier
   and the Session Key Generation Method."

Access Ticket, does contain Face and Client Info. If I understood
correctly here is stated that the Client Information consist of
Verifier and the Session Key Gen? Why the CI has the Session key gen
method (should not be this part of the Face that is destined to the
RServer)? On the example the Gen method is part of the Face, so maybe
can this sentence be rephrased to let clear that the session key gen
is part of the ticket face?

> 3.7 Ticket Transfer Message
“The Ticket Transfer message is (...) and includes any access
information from SAM contained on the Ticket Grant message”,
What does this “any” mean? (explicitly the documents later says that
CAM MUST NOT include any CAI information provided by SAM), so this
“any” means “some” (Face and Verifier? but not CAI)? I think “any” is
a confusing term.

Can we have an example of CAI info from from SAM ? (the CAI will be
included on the Face or is stand alone? OK, as the Face cannot be
changed, because the same  face must be possessed by C and S for a
successful  DTLS session handshake, so I assume is stand alone)

why would a SAM add a CAI? (and not restrict the Token on SAI directly?)

maybe to force CAM to enforce that CAI?
if a CAI coming from SAM its with that purpose, then when
specification when says “CAM MUST NOT include any CAI info from SAM”
means that the CAM does not care -or on the contrary, it takes it in
account but adds its own policies also respecting COP’s enforced CAI-?

>  3.9 Authorized Resource Request Message
“must check T” -meaning- TS? ( T is not defined later)

How does RS distinguish two different clients if they have the same
Face (face must be unique then)? what identifies a client? must be on
the face?

OK, after reading the whole document the TS on the Face is the thing
that can uniquely identifies a ticket (and will be sent by CAM to one
and only one C, so one ticket with a unique TS can be possessed by
only one client)..
So I think it needs to be stressed the importance of the TS field, It
must be unique per ticket (must be a precise clock on SAM), if the TS
of two Tickets repeats/is the same we are in problems.

(comment after reading 4.1) If S generates the timestamp.. due to its
constrained nature does not this pose a problem because we can have TS
collisions? Can we really guarantee that S will not generate two times
the same TS? (e.g: if it resets..)

> 4. Ticket
The CI plus the Face goes to the Client will not be more accurate? The
client without the Face cannot start the DTLS session (so in a way the
Face is also destined to the Client)

Only Face is needed No additional information is needed to ID the
client? (so the unique way the client id can be seen as the TS?)). OK
-seems to be that way, the TS is the id of the ticket-

> 5. Payload Format and Encoding
TS: time stamp; “An optional timestamp that indicates … when the
access ticket request” ,

For the access request may be optional, but for the ticket
grant/ticket transfer is needed as a part of the Face (on Face
description 4.1 is marked as a MUST)

should not this distinction be clear(er)?

The TS for the Ticket Face is not optional is a MUST, without it a
client cannot be uniquely associated with a Ticket Face (it is the
only unique id, field, possible to distinguish one Ticket Face of
another), this is marked down when the field “F” is explained. however
it was confusing to me to be defined as optional. Maybe can be
clarified that is optional when is not a part of Face.

> 5.1 Examples
* text It says that the Face contains a “client descriptor” is
missing? . Ok now I read version 00 of the document and client
descriptor is there. So on the current version no more Client
Descriptor is needed/present, this “client descriptor” has to be
erased

* Encrypted face uses the shared S/SAM key and the TS as nonce. The TS
of the Face was put by SAM not by S -if Im not mistaken the SAM put
the TS when it generates the ticket) ? (why says “S’s timestamp”?),
also for S to decrypt the Encrypted face, it will need the nonce (TS),
but if he only receives E K V he will not have the appropriate nonce
to decrypt E. Am I mistaken or the nonce should be passed to S also?

After reading carefully the document also allows to S to generate the
Timestamp (I mentioned that this could lead to problems). But how
would S know what timestamp to use as nonce (he cannot associate an
Encrypted face with an unauthorised old request? . The problem of what
nonce to use is still true if SAM is the generator of TS. solution:
send the nonce aside the encrypted face (E ,K, nonce, V)?

OK. This nonce problem seems to be adressed on version 03 of the document

> 8. Trust Relationships

"1.  SAM has means to authenticate CAM (e.g. it has a certificate of
       CAM or a PKI in which CAM is included) and vice versa"

worth mentioning the “mutual authentication” concept?

"2. As far as SAM needs to rely on the different clients of CAM to
       receive different permissions, it can be sure that CAM correctly
       identifies these clients towards SAM and does not leak tickets"

what does “towards SAM” means/adds? is it needed to add that (would
not work the phrase/protocol the same without that)?
(CAM does not send any client information to SAM -nothing to id a
particular client-)

> FIGURE

Figure missing number?

> 10 Examples
> 10.1CAM-->SAM Ticket Request,

on section 3.5 is specified that Token Request messages contains “5. A
label that describes the client is added to the payload”
On the example is not present. What purpose serves that label? (also
on dcaf field identifiers seems not the be a “label”), should this
point 5 on section 3.5 be erased or marked as optional?
Ok now that I read older version of drafts seems that label that
describes client is no longer used, so on section 3.5 should be
erased?

Should be useful to see the message exchange between SAM and S?

---

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 15 Sep 2015 21:12:33 +0200

Hi Renzo,

Thank you very much for your thorough feedback!

> COSE security instead of DTLS.

We started integrating COSE into DCAF. Section 3.3 of the 03 version
describes how COSE content can be transported in DCAF.

> I hope to start contributing more, and these are my two cents for now.

Thank you!

> Have a good start of the week

The Authorization Manager must perform very distinct tasks. They present
user interfaces and displays to the user, have enough memory, storage
space and processing power to store complex authorization policies and
keying material and they are able to use unmodified security protocols
such as OAuth and Kerberos. They simplify the principals' authorization
decisions and perform the authentication of the opposite party.
Constrained nodes depend on their Authorization Managers and will not be
able to communicate securely without them. We are worried that people
will not understand the special role of the Authorization Managers and
will confuse them with OAuth authorization servers.

Especially when writing up examples for interactions between constrained
level protocols such as DCAF and less constrained level protocols such
as OAuth (see
https://tools.ietf.org/pdf/draft-gerdes-ace-dcaf-examples-00.pdf), we
noticed that it is very confusing if we are not able to distinguish
Authorization Server and Authorization Manager.

The OAuth model does include a Client Authorization Manager. The
current approach is to call it Client Authorization Server (CAS). The
Authorization Server on the server side is called AS, which is kind of
confusing. We cannot even write something general about authorization
servers since it is unclear whether this includes client authorization
servers or not.

(Our experience from teaching is also that the OAuth terminology is
generally confusing to new learners, so a more regular terminology may
help adoption outside the circles of hardcore OAuth experts.)

> representing a 128-bit PSK)

Ok.

> They are defined on Section 5. but before the formal definition they

True. We will add definitions for them.

> what's been defined as Ticket Requests)?

Good catch, thanks.

> http://english.stackexchange.com/questions/19653/insecure-or-unsecure-when-dealing-with-security

We can change "insecure" to "unprotected" in 3.2. and 4.2.

> attempts a ticket Request. (if this is the case, should this be stated

True. We should clarify that.

> not allowed) or CAM will change the SAI according to COP’s policies?

CAM informs C about COP's policies using the CAI in the Ticket Transfer
message. CAM needs to specify the CAI anyway in the Ticket Transfer
message if COP specified authorization policies for the client.

> OK, I think this point is here from previous versions of document,

Yes, this is a relic from a previous version and somehow slipped
through. We will remove it.

> is part of the ticket face?

Yes, there is at least a comma missing in the sentence. The ticket
consists of the face and the client information. The client information
consists of the verifier. The face contains among other stuff the
session key generation method. We will clarify that.

> “any” means “some” (Face and Verifier? but not CAI)? I think “any” is

The Ticket Transfer Message contains the SAI that SAM sent in the Ticket
Grant message. We will clarify that.

> successful  DTLS session handshake, so I assume is stand alone)

DCAF tickets comprise of two parts, the face and the client information.
The client information and the face. CAI is part of the client
information. We will try to make this more clear.

> account but adds its own policies also respecting COP’s enforced CAI-?

SAM is not supposed to add a CAI. A malicious (or misconfigured) SAM
might add CAI and thereby mislead C to believe that it reflects the
COP's authorization policies.

> “must check T” -meaning- TS? ( T is not defined later)

Good catch. Yes, TS.

> the same TS? (e.g: if it resets..)

Yes, true. We will need to point out more clearly what the requirements
for the TS in the Face are, including a discussion whether it can/should
be a nonce or a timestamp.

> Face is also destined to the Client)

Sure, but we wanted to point out that the Client keeps the CI part of
the ticket while the Face is destined for the Server. We will rephrase
the paragraph to make this more clear.

> -seems to be that way, the TS is the id of the ticket-

Yes. Identifying the Client is not that important for the Server. It
only needs to make sure that the Client is authorized. However, it might
be necessary to identify the ticket to be able to revoke it.

> clarified that is optional when is not a part of Face.

We will look into this more closely when we define the requirements for
TS (see above).

> Descriptor is needed/present, this “client descriptor” has to be

Yes, will be deleted.

> worth mentioning the “mutual authentication” concept?

Ok.

> (CAM does not send any client information to SAM -nothing to id a

For some use cases, CAM might need to provide information concerning the
client to SAM, e.g., if SAM only wants to authorize certain types of
devices. In this case, CAM must provide correct information about the
client to SAM. We will make this more clear.

> Figure missing number?

I can't find this in the draft, maybe it is fixed in the 03-version?

> describes client is no longer used, so on section 3.5 should be

Yes, will be deleted.

> Should be useful to see the message exchange between SAM and S?

DCAF only considers the exchange of information between SAM and S that
is included in the Ticket Face. It might be necessary for SAM and S to
exchange additional information for time synchronization or other
administrational stuff, but that is not in scope of the document. Do you
miss something in particular?

Thank you very much again for your thorough feedback! It is very helpful
for us!

Viele Grüße
Steffi