Subject: [Ace] Authentication, Authorization and Key Distribution

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Apr 2014 11:19:55 -0700

Hi all,

based on the recent discussion I believe it is useful to clarify the
relationship between authentication, authorization, and key
distribution/key establishment.

There are various sources of literature but there is nothing that is
universally accepted. Needless to say that this typically causes a lot
of confusion in every identity management conversation. I am re-using
terminology text from the "Handbook of Applied Cryptography" and from
"Who goes there? Authentication Through the Lens of Privacy".

In a simplistic view what we are trying to accomplish is to allow a
client to access a protected resource and he gets access granted when he
is authorized to do so.

Authorization is the process of deciding what an entity ought to be
allowed to do. Authorization is distinct from authentication (which
establishes what an individual “is” rather than what the individual “is
allowed.”). Authorization policies determine how authorization decisions
are made. Authorization policies base decision making on a variety of
factors, including identifiers (such as names) and attributes.

Hence, authentication and authorization are separate steps but they are
obviously related to each other.

At this point the story becomes more complex.

Many deployments involve a centralized or trusted party, for either or
both initial system setup and on-line actions (i.e., involving real-time
participation). This party is referred to by a variety of names
depending on the role played, including: trusted third party, trusted
server, authentication server, key distribution center (KDC), key
translation center (KTC), and certification authority (CA).

So, we are not just talking about a two-party environment but about a
multi-party environment.

Earlier this year we discussed this topic on the ACE mailing list and we
said that we want to work with solutions that involve such a trusted
party (as I tried to explain in Section 1 of
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00).

When you have a trusted third party you can use that party to develop a
more scalable way to manage authorization policies. Better management
comes with the price of having that additional party in the game.

Hence, instead of having the client to authenticate to the relying party
directly the exchange involves the trusted third party to which the
client is authenticated instead. To provide confidence to the relying
party that this step has indeed happened some information (in a
protected form) needs to be communicated from the trusted party to the
relying party (the resource server). This is where key establishment
comes into the picture.

Key establishment is a process or protocol whereby a shared secret
becomes  available to two or more parties, for subsequent cryptographic
use. Of course there are differences in the details depending on the use
of symmetric vs. asymmetric keys. (We don't want to go into any of these
details but if you look at Section 2 of
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00 then you can
see how existing protocols have dealt with this issue.)

I hope that this clarification helps to convince you that it is a bit
difficult to capture this and the necessary background in the charter.

Ciao
Hannes

---

From: Rene Struik <[email-masked]>
Date: Fri, 11 Apr 2014 02:37:17 +0200

Hi Hannes:

I am not sure the assertion that protocols that involve three parties are
more scalable is necessarily justified at this point. In my mind,
pre-sorting for this solution direction in the charter is unjustified (we
may end up there, but should cast the net wider with the SoW). Do you have
any supporting evidence for your assertion? What if, for example, the
communication channel is spotty, with relatively sparse (in time)
opportunities to communicate?

Glad you consulted the Handbook, though.

Rene

Traveling right now...
On Apr 10, 2014 7:48 PM, "Hannes Tschofenig" <[email-masked]>
wrote:

> establishes what an individual "is" rather than what the individual "is
> allowed."). Authorization policies determine how authorization decisions
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>
>

---

From: Göran Selander <[email-masked]>
Date: Fri, 11 Apr 2014 05:51:42 +0000

Hi Rene

The TTP is also assumed to support authorisation decision and/or manage authorisation policies for which the relying party may be too constrained. When communication security context is available in client and relying party, and when relying party has an applicable and valid authorisation decision/policy cached, it should not be necessary to involve the TTP.

My understanding of the case where both client and relying party has no communication channel with the TTP, and when there is no applicable authorisation decision/policy cached at the relying party, it is acceptable that the client is not granted access even though it being authorised (according to policy). For the same reason immediate revocation may be impossible.

Göran

(As a side remark in light of this pre-sorting discussion, I find the most restrictive assumption in the current charter to insist on the main security protocol being DTLS.)

From: Rene Struik <[email-masked]<mailto:[email-masked]>>
Date: Friday 11 April 2014 02:37
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] Authentication, Authorization and Key Distribution

Hi Hannes:

I am not sure the assertion that protocols that involve three parties are more scalable is necessarily justified at this point. In my mind, pre-sorting for this solution direction in the charter is unjustified (we may end up there, but should cast the net wider with the SoW). Do you have any supporting evidence for your assertion? What if, for example, the communication channel is spotty, with relatively sparse (in time) opportunities to communicate?

Rene

Traveling right now...

On Apr 10, 2014 7:48 PM, "Hannes Tschofenig" <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Ciao
Hannes

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Apr 2014 08:19:29 +0200

Hi Hannes,

thanks for writing this up.

One point maybe merits mention here:

On 10 Apr 2014, at 20:19, Hannes Tschofenig <[email-masked]> wrote:

> client is authenticated instead.

In the Berlin model, the (resource) client never authenticates to the authorization server of the (resource) server either.
(How would it?  The two don’t know anything about each other.)
Similarly, the resource server cannot authenticate the client as an entity, but of course it needs to authenticate its authorization.
(That’s why it is useful to point out that it is not necessarily an identity that is being authenticated, see RFC 4949:

   $ authenticate
      (I) Verify (i.e., establish the truth of) an attribute value
      claimed by or for a system entity or system resource. (See:
      authentication, validate vs. verify, "relationship between data
      integrity service and authentication services" under "data
      integrity service”.)

Obviously, even for identity attributes, the term “truth” here is suboptimal: You can use my passport to authenticate that the State of Germany authorized me to claim that I’m German citizen Carsten Bormann, but you’ll never find out the “truth" from that passport.)

As a terminology comment, I’d like to replace “A is trusted” (or, more specifically “B trusts A”) with “B has authorized A to speak for X”, where X is something specific and not a nebulous, all-encompassing concept of “trust”.  (The latter works nicely in the mother-duckling model, but in general is too limited.)

Grüße, Carsten

---

From: "Natale, Bob" <[email-masked]>
Date: Fri, 11 Apr 2014 13:10:33 +0000

Hi Hannes,

Agreed ... and I would recommend also distinguishing between "Authorization" and "Access Control", using definitions similar to the ones below:

Authentication:	 The process of establishing confidence in the identity of users or information systems. 

Authorization:  The processes of granting or denying the right to access specific resources (systems, services, data, facilities, etc.). Authorization grant/deny decisions are the purview of the business process and/or resource owner.

Access Control:  The process of granting or denying requests to access specific resources (systems, services, data, facilities, etc.). Access control evaluates entity authentication and authorization attributes, resource access requirements, and relevant contextual information to make instance-specific grant/deny access decisions. In sum, access control enables authorized access and prevents unauthorized access.

Avanti,
BobN

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, April 10, 2014 2:20 PM
To: [email-masked]
Subject: [Ace] Authentication, Authorization and Key Distribution

Hi all,

Ciao
Hannes

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 14 Apr 2014 10:55:55 +0200

> Authentication:	 The process of establishing confidence in the identity of users or information systems.

We already had this discussion several times, and came to the conclusion 
that this is a far too restrictive definition of authentication. Have a 
look at the mailing list archives. Short version: You can authenticate a 
lot of things besides identity.

> Access Control:  The process of granting or denying requests to access specific resources (systems, services, data, facilities, etc.). Access control evaluates entity authentication and authorizati…

Trying to define the meaning and difference of 'authorization' and 
'access control' is not something that this WG should attempt to do. I 
think most of us can agree on the first sentence in both of your 
definitions, and that's good enough for me.

/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