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

[Stefanie Gerdes <[e-mail]>]

Hi Renzo,

Thank you very much for your thorough feedback!

On 09/14/2015 03:01 PM, Renzo Navas wrote:
> 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.

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

> 
> 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.

Thank you!

> 
> 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

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.)

> 
>> 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)

Ok.

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

True. We will add definitions for them.

> 
> 
>> 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)?

Good catch, thanks.

> 
>> 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

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

> 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?)

True. We should clarify that.

> 
> 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?

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.

> 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?

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

> 
> 
>> 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?

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.

> 
> 
>> 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.

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

> 
> 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)

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.

> 
> 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-?

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.

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

Good catch. Yes, TS.

> 
> 
> 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..)

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.

> 
>> 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)

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.

> 
> 
> 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-

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.

> 
> 
>> 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.

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

> 
> 
>> 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

Yes, will be deleted.

> * 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?

Ok.

> 
> "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-)

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
> 
> Figure missing number?

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

> 
> 
> 
>> 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?

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