Subject: Re: [Ace] Terms to avoid

From: Göran Selander <[email-masked]>
Date: Sat, 14 Dec 2013 00:33:23 +0000

Hi Hannes,

Just stepping in briefly in this thread (will not be able to keep as prompt dialogue as I would like).

On terminology in general: I agree, in part based on the same experience, on the importance of aligning terms. 

On terminology in draft-selander-core-access-control-01.txt in particular: yes some terminology is aligned with OAuth, and for exactly that reason. 

Having said that, the main part of the job is still to be done. The alignment is on names of nodes in the architecture and on the central object (access token). We have not yet tried to understand the exact dependency. Neither are we claiming that OAuth is the only means to acquire access tokens in constrained environments. And vice versa except for a few comments in Berlin, no one with deep insights in OAuth have commented on this draft. IIRC from Carsten's presentation at the OAuth meeting in Berlin, there was an agreement to coordinate between OAuth and CoRE on this topic. (This is at least one of the reasons this missing analysis has slipped down on my todo list - I thought it ended up also on someone elses ;-)

I think this is a good reminder for some of us to pick up this again in preparation for London. 

Best regards,
Göran

--Original message---
Sender: "Ace" <[email-masked]>
Sent time: 13 dec 2013 17:41
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Ace] Terms to avoid

Carsten,    I always get worried when new terminology is introduced because 
it somehow prevents people to see the connection to earlier work anymore. I 
am not saying that without some experience. I have seen EU funded projects 
(with good people) working in different working groups (who use different 
terminology) to find out after two years that they have been actually 
working on the same problem and came up with the same solution (but just 
called it differently).    Just to give you an example in this conversation 
about terminology for access token. Where does that term come from? Hmmm. 
It comes from OAuth since the write-up offered in 
draft-selander-core-access-control-01.txt is essentially OAuth. (Of course, 
one has to say that the OAuth group also "re-invented" Kerberos to a large 
extend.) The terminology defined in the base OAuth 2.0 spec is "access 
token -- a string denoting a specific scope, lifetime, and other access 
attributes". Access token was OAuth specific and one could as well look at 
the Kerberos terminology for a very similar concept (the ticket) --   
Ticket: A record that helps a client authenticate itself to a server; it 
contains the client's identity, a session key, a timestamp, and other 
formation, all sealed using the server's secret key.  It only serves to 
authenticate a client when presented along with a fresh Authenticator."    
If you acknowledge that it has something to do with OAuth one can start 
differently, namely by saying the following: "Here is OAuth and it has the 
features we like in the IoT context. There are a few things we do not like 
(and we profile them away) and here are some additional features we need, 
which are X, Y, and Z." That would save us a lot of time.    Regarding your 
reference to the lifecycle in  
http://tools.ietf.org/html/draft-garcia-core-security-01
<http://tools.ietf.org/html/draft-garcia-core-security-01>  concerning 
bootstrapping. It shows that bootstrapping consists of the phases 
"installed" and "commissioned" but unfortunately it does not define them in 
detail. I would much more comfortable if the authors had explained it, 
which I raised in my review 
http://www.ietf.org/mail-archive/web/ace/current/msg00027.html.    
Regarding your remark about not looking at the keys. Of course, key 
establishment protocols are not only about keys. There is more to them and 
authorization is part of the story. It turns out that you cannot separate 
all these different phases into distinct pieces. As an example, I can point 
to a good description about the AAA framework:  
http://tools.ietf.org/search/rfc5247 <http://tools.ietf.org/search/rfc5247> 
 (Of course it has the AAA alike communication framework underneath, which 
you may or may not like.)   I think I am really not asking for too much 
here, I believe. All I am looking for is for the group to take existing 
IETF work (terminology, and concepts) into account and if it cannot be used 
then to describe it clearly what the new things does. Am I asking for too 
much?   Ciao
Hannes   Gesendet: Freitag, 13. Dezember 2013 um 13:07 Uhr
Von: "Carsten Bormann" <[email-masked]>
An: "Hannes Tschofenig" <[email-masked]>
Cc: "Carsten Bormann" <[email-masked]>, [email-masked], [email-masked]
Betreff: Re: [Ace] Terms to avoid On Dec 13 2013, at 13:14, Hannes 
Tschofenig wrote:

> Carsten says: "Bootstrapping is not a method, it is an objective,
> which can be pinpointed pretty precisely in the lifecycle of a device.
> More specifically, it relates to achieving the transition from a
> sparse or minimal, pre-operational set of authenticated
> authorizations to a set that can be used operationally."
>
> Carsten, you are pointing to a lifecycle that seems to be
> universally agreed. Where is that lifecycle?

draft-garcia

> The definition you offer is also vague and IMHO does not help to
> guide the work in the group.

It is pretty much as un-vague as it can be.

If that makes you uncomfortable because it doesn't immediately lead to
a separable "bootstrap protocol", I'm with you.
I would be very unhappy if we needed a separate piece of technology
for bootstrapping.
Bootstrapping is just one area among the set of requirements this work
needs to meet.
If several good ways to do bootstrapping don't fall naturally out of
the ACE work, we have failed.

Re 1 and 2: both, of course.

Maybe it's best to stop thinking about these keys for a moment.
Keys are a means to an end.
What is the end?
Thinking about this might help prevent us from getting another key
establishment protocol that only addresses a bizarre subset of the
problem.

This is all about authorization.
(Authenticated authorization, specifically.
Not Authentication and authorization as if those were separable.)

Grüße, Carsten