Subject: [Ace] Terminology and basic assumptions (Was: Re: Container Use Case)

From: Göran Selander <[email-masked]>
Date: Wed, 14 Jan 2015 10:20:24 +0000

Hi Steffi, Hannes

I note that there is a difference in opinion here whether we should try to
introduce the basic terms, concepts and assumptions in the use case draft
or not.

Pending the resolution of that I wait with responding to this mail and
instead provide more specific comments of the new version of the use case
draft (next mails).

Regards,
Göran

On 2015-01-13 15:37, "Stefanie Gerdes" <[email-masked]> wrote:

>Hi Göran,
>
>On 01/10/2015 12:51 PM, Göran Selander wrote:
>> Hi Steffi and Ludwig,
>>
>> (Also a question for WG chairs / AD a few paragraphs below)
>>
>>
>>
>> I¹ve read through the ACE use case draft with fresh eyes and have some
>> comments. Since I know the draft is in transition I will not go into
>> detail in this mail. Could you please let me know if you plan to address
>> the comments below or not in the next version?
>>
>> The main overall comment is that there is a great deal of overlapping
>> material between section 3 of the use case draft and section 4 of
>> draft-seitz-ace-problem-description:
>>
>> [1]
>> 
>>http://tools.ietf.org/html/draft-seitz-ace-problem-description-02#section
>>-4
>>
>> Recall that section 4 of [1] is to a large extent the result of a
>> discussion at the (informal) ACE meeting in Stockholm in June 2014.
>> Obviously we didn't agree on everything at the meeting, as is also
>> indicated in the draft, but some terms and assumptions were agreed and I
>> think it would save us time to re-use some of this either in the use
>>case
>> draft or in a separate [architecture?] draft.
>>
>> WG chairs/AD/anyone: Do you have an opinion about whether (a) there
>>should
>> be a separate [architecture?] draft describing additional terminology
>>and
>> assumptions of the solution space, or (b) if this should be fitted into
>> the security considerations of the use case draft, or (c) each solution
>> proposal should make its own assumptions and terminology?  The charter
>> does not include an architecture document which I guess speaks in favor
>>of
>> (b) and (c).
>
>There already was some discussion about this during the last ACE session
>in Honolulu. I really don't like the idea to mix up use cases,
>architecture and solutions. The terminology in the use cases draft
>should only contain the terminology actually used in there. Additional
>terminology will likely be solution specific. Since we don't know yet
>which solution fits best it will be more useful to leave this discussion
>for later. We will gain more from the use cases document if we focus on
>its main purpose: summarizing the main problems in representative use
>cases.
>
>If it is obvious that there are documents missing in the milestones that
>would be useful for the work in ACE, it might be better to add them
>instead of trying to press topics into a document where they don't
>really fit and will blur the focus.
>
>> Here are the comments:
>>
>> Section 3.1 "Attacks"
>> - The last part of the section describes properties of constrained
>>devices
>> that may need to be considered also for performance reasons, not just
>> attack mitigation. How about renaming the section "Constrained device
>> aspects" or "Constrained devices" or similar?
>>
>> - Section 4.2 of [1] contains a list of partly overlapping features of
>> constrained devices. Does it makes sense to include in the use case
>>draft
>> other features of section 4.2 in [1] which are not currently in? For
>> example that some constrained devices may be unable to manage complex
>> authorization policies or unable to precisely measure time (see also
>> section 5.3 in [1])?
>
>Kathleen advised us to include attack scenarios into the document (see
>http://www.ietf.org/mail-archive/web/ace/current/msg00765.html).
>
>> Section 3.2 "Configuration of Access Permissions"
>> - Different terms with similar meaning are used in the draft: "access
>> permissions"/"access control policies"/"authorization policies". A
>>single
>> term consistently used would be preferable. As an alternative, [1] uses
>> the term "authorization information". Section 4.4 of [1] proposes a
>> definition and characterization of authorization info. which is more
>> general than just premissions/policies. Does it make sense to use this
>> terminology and/or characterization in the use case draft?
>
>The term policy usually has a different meaning than the term
>authorization information. In my understanding, the latter refers to a
>collection of information that is used for authorization and contains
>e.g. the access permissions. The term "policy" is defined as "A plan or
>course of action that is stated for a system or organization and is
>intended to affect and direct the decisions and deeds of that entity's
>components or members." by RFC4949. A permission is usually one part of
>an authorization policy. It can e.g. consist of an object and an action
>that can be performed on that object.
>
>Therefore, I don't think we benefit from replacing the terms in the
>document with "authorization information" as you suggest.
>
>> - Section 3.2 also overlaps with 4.5 of [1], the latter is considering a
>> more general problem "access to authorization information". (More
>>general
>> since authz. info is more general than access policies and "access" is a
>> priori more general than "configuration"/"provisioning to the device".)
>> Does it make sense to include this more general problem and the
>>properties
>> listed in section 4.5 of [1] in the use case draft?
>>
>> - Section 4.5 of [1] also go into how to secure access to authorization
>> information. Do you think this content also makes sense in the security
>> considerations of the use case draft?
>
>Section 3.2 and 3.3 are derived from the problem descriptions of the use
>cases. If you miss a specific topic, maybe there is something missing in
>the use cases?
>
>Some of the topics mentioned in section 4.5 discuss solutions, e.g.
>"Authorization information may a priori be transferred directly between
>AS and RS, or via C; using Agent, Push or Pull mechanisms". I don't
>think this belongs into the use cases document.
>
>
>> Section 4
>> - Not only authorization of resource access, but also authorization of
>> access to resource information should be considered for privacy reasons
>> (compare section 4.3 of [1].)
>>
>>
>>
>> General
>> - The use case draft contains fragments of an authorization architecture
>> (mainly terminology in section 1.1 such as C, RS, RO). Would it make
>>sense
>> to extend this and include a basic split "authorization decision /
>> authorization enforcement" setup? Section 2 of [1] motivates why this
>> setup is particular relevant for the constrained device setting, and
>> section 4.3 of [1] maps this functionality to the architecture.
>
>This again is more about possible solutions and architecture. This is
>not in scope for the use cases draft.
>
>> - [1] also contains assumptions on keys and ciphersuites (section 4.7),
>> constrained network considerations (section 4.9) and legacy
>>considerations
>> (section 4.10). Do you think any of this makes sense in the use case
>>draft?
>>
>> - Sections 2.x.x. entitled "Authorization Problems Summary"
>> I think most of the authorization problems make more sense with "device
>> owner" replaced with "resource owner". Referring to Steffi's mail reply
>>to
>> Hannes (Subject: [ACE] Container Use Case) I think it is confusing to
>>try
>> to address server and client problems with one problem statement about
>> "device owner". I would like to separate those so it is clear to whether
>> the problem relates to server or client. Do you agree?
>>
>
>We introduced the term "principal" in the new version of the draft to
>address this problem.
>
>Best regards,
>Steffi