Subject: Re: [Ace] Container Use Case

From: Göran Selander <[email-masked]>
Date: Sat, 10 Jan 2015 11:51:37 +0000

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

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

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?

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

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

Regards,
Göran

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Jan 2015 12:37:21 +0100

actually wanted to send this to the mailing list.

-------- Forwarded Message --------
Subject: Re: [Ace] Container Use Case
Date: Mon, 12 Jan 2015 10:31:39 +0100
From: Hannes Tschofenig <[email-masked]>
To: Göran Selander <[email-masked]>, Stefanie Gerdes
<[email-masked]>, Ludwig Seitz <[email-masked]>
CC: Likepeng <[email-masked]>

Hi Goeran,

thanks for your detailed review. Let me respond to the following
question you raised in your review:

>> does not include an architecture document which I guess speaks in favor of

Currently, we only have the use case document and the solution
document(s) in the charter and nothing else.

As mentioned in earlier discussions I think it makes sense to include
useful terminology in this document but there will for sure be
terminology that is very solution specific and such terminology could
best be included in a solution document.

For example, I believe the following terms would be very useful to have
in the use case document:

 * Authorization Server

 * (Constrained) Client

 * (Constrained) Resource Server

 * Resource Owner (RO)

We could reference other security documents for basic security terms
(such as RFC 3552 and/or RFC 4949) regarding authentication,
authorization, integrity, confidentiality, non-repudiation, accounting,
etc.)

There are, however, a few things I am not sure about.

When it comes to ownership the story gets a bit complex as the devices
is owned and not necessarily a role (such as a client or a server role).
Embedded in this ownership concept into the terminology seems to imply a
notion about who has access to data on that device. Of course, ownership
does not automatically imply access to data. So, it is not clear to me
whether focusing on ownership is the right way to cast the story.

I am also looking for input from the group whether there is interest to
include different forms of authorization servers. The authorization
server of the client, and the server, for example. In some cases there
is no just one authorization server for a given entity but a chain of
servers (particularly in the enterprise world) when you delegate certain
rights to other parties. Is this worthwhile to discuss/to include?

Sometimes in the identity management space there is also the desire to
separate the entity that does the authentication from the entity that
does the authorization. Is this useful in our case?

When attributes come into the picture then these attributes may not all
come from the same entity. The authentication attributes are a simple
example, which may come from a separate authentication server. In theory
attributes can came from various sources.

Regarding the assumptions I think the same approach as with terminology
applies. It is reasonable to state assumptions in the use case document
(which are today implicit). For example, an assumption covered in the
use case document is that there is an authorization server and that
devices have credentials pre-provisioned with that authorization server.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Jan 2015 12:56:14 +0100

FYI: message from Goeran.

-------- Forwarded Message --------
Subject: Re: [Ace] Container Use Case
Date: Tue, 13 Jan 2015 09:31:17 +0000
From: Göran Selander <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, Stefanie Gerdes
<[email-masked]>, Ludwig Seitz <[email-masked]>, Kumar, Sandeep
<[email-masked]>, [email-masked] <[email-masked]>
CC: Likepeng <[email-masked]>

Hi Hannes,

Also including the other co-authors (or did you intend to send it on the
ACE list?)

Some comments inline.

> * (Constrained) Resource Server

This is fine by me, but see below.

>rights to other parties. Is this worthwhile to discuss/to include?

We have had this discussion before and there are different models. My
proposal was that we maybe could get around re-iterating the previous
discussion by looking carefully at the functions, in particular
authorization decision and authorization enforcement split. Since
authorization is about making decisions we should answer the question what
role takes this decision and what role is enforcing the decision. This
provides a set of necessary roles which should be termed in the use case
document to allow a good discussion of security considerations.

As a natural consequence of this the PEP need to access ³authorization
information² from the PDP. And this access needs to be secured. This is
also a necessary part of the architecture, independent of solution, and
should IMHO be part of the security considerations of the use case
document.

draft-seitz-ace-problem-description provides one example of how to term
and structure this, but it may be expressed in different ways.

>does the authorization. Is this useful in our case?

I think that this is not strictly necessary in our case. In my opinion
there are two parts:

1. how the PEP securely access authorization information (as mentioned
above)
2. how the authorization information is used by the PEP to secure the
resource access

The second part also includes the security protocol between client and
resource server, which may depend on the authorization information. For
example: access to resource X for the holder of key Y means that the PEP
must verify that the requesting entity has key Y, or at least protect the
resource such that only can be accessed with possession of key Y.

We should also have a high level understanding of what the authorization
information contains, i.e. what are the different options: for example
authorization decisions or capability lists. But we don¹t need to specify
*how* the authorization information is produced, e.g. how the client was
authenticated (even if this may be included in the authorization
information).

Moreover the authorization decision may not require the identity of the
entity: it may be sufficient that the entity has the right key (producing
a correct MAC). In practice different different roles may require
different proofs from the requesting client: The PDP may require the
client to authenticate, whereas the PEP will settle for key confirmation.

So I don¹t think we need to include the authentication server as a
separate entity, but I do think we should keep integrity protection and
encryption of resource access as part of the authorization procedure.

>attributes can came from various sources.

Yes, but I think we should avoid this complication and stay on the level
of ³authorization information² which in principle may contain
authentication attributes, come from different sources etc. but let¹s not
assume that in the first place.

>devices have credentials pre-provisioned with that authorization server.

OK by me. We should also be explicit that this could be either symmetric
keys or public keys.

Regards
Göran

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Jan 2015 12:56:07 +0100

Hi Goeran,

a quick response.

~snip~

Summary of proposal by Goeran: Look at what role makes authorization
decision and what role is enforcing it.

> and structure this, but it may be expressed in different ways.

I guess you are particularly pointing to Section 3 of
https://tools.ietf.org/html/draft-seitz-ace-problem-description-02#section-3
(which defines the problem description).

The content makes sense to me; I only have a minor remark.
There are different models for authorization, namely

1) The PEP gets the authorization information from the PDP. Think about
an actual policy sent to the PEP in the form of "IF request used key X
and resource=Y THEN accept ELSE deny" statements.

2) The PEP gets only the decision of the authorization request from the
PDP. This is a YES and NO decision.

3) Then, there is the approach of entitlements. Here you define an
abstract term like 'email' and that has a specific meaning for the RS.
For example, it means 'client is requesting to send emails notifications
by the RS.'

I got the impression that your description focuses on #1. Is that correct?

(We can actually ask Eve today to talk about this issue since she has a
long history with the standardization of access control policies.)

> resource such that only can be accessed with possession of key Y.

I was more talking about the authentication of the client (or the user)
rather than authentication of the RS.

Of course, there is no need to always do authentication and
authorization into separate entities.

> authenticated (even if this may be included in the authorization

This is a good idea.

> client to authenticate, whereas the PEP will settle for key confirmation.

I agree. It might purely be trait-based.

> encryption of resource access as part of the authorization procedure.

It is certainly an architectural decision to think about. In the AAA/EAP
case the EAP server is logically separated from the AAA server even
though they may often reside in the same box.

> assume that in the first place.

Thanks for the feedback.

> OK by me. We should also be explicit that this could be either symmetric

I think we should be explicit about it. I don't think we even made a
decision yet about this topic yet but it would be good to get an
agreement since it will obviously impact the solution space.

Ciao
Hannes

---

From: Göran Selander <[email-masked]>
Date: Tue, 13 Jan 2015 13:14:48 +0000

Hi Hannes

Thanks for quick reply and good comments, some answers/comments inline.

>(which defines the problem description).

Yes, but it is more compactly summarized in sections 4.3 - 4.5
https://tools.ietf.org/html/draft-seitz-ace-problem-description-02#section-
4.3

>I got the impression that your description focuses on #1. Is that correct?

All these are encompassed in the term “authorization information”, so, no,
#2 and #3 are not a priori excluded. In section 4.4 we used the term
“access control policy”, “authorization decision” and “client capability”
which I believe maps to 1, 2 and 3, respectively.

>rather than authentication of the RS.

Yes, so did I. Maybe I misunderstood or confused the terminology? I’m
mainly thinking of PDP = Authorization Server and PEP = Resource Server,
but don’t want to exclude other cases.

>authorization into separate entities.

Agree 

>agreement since it will obviously impact the solution space.

Yes, at least when we dig down into the details. Since we don’t have an
architecture draft, I understand these type of decisions should be
recorded in the use case document.

Regards,
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 13 Jan 2015 15:37:31 +0100

Hi Göran,

> does not include an architecture document which I guess speaks in favor of

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.

> authorization policies or unable to precisely measure time (see also

Kathleen advised us to include attack scenarios into the document (see 
http://www.ietf.org/mail-archive/web/ace/current/msg00765.html).

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

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

> 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