Subject: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

From: Carsten Bormann <[email-masked]>
Date: Sun, 18 Feb 2018 07:38:17 -0800

Page 50:

      *  Register the client at the AS.  This includes making known to
         the AS which profiles, token_types, and key types (symmetric/
         asymmetric) the client.

Shouldn’t this say how?

(This is just one instance of a rather pervasive issue.)

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 18 Feb 2018 16:35:47 +0000

Hi Carsten,

We should maybe add that this information is provisioned either during manufacturing, via a commissioning tool or some other mechanisms. Not sure whether this will indeed add more but it might be useful to know.

Ciao
Hannes

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: 18 February 2018 16:38
To: ace
Subject: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

Page 50:

Shouldn’t this say how?

Grüße, Carsten

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 18 Feb 2018 08:45:17 -0800

> We should maybe add that this information is provisioned either during manufacturing, via a commissioning tool or some other mechanisms. Not sure whether this will indeed add more but it might be u…

For a protocol that is meant to be interoperable, there need to be standard (if not MTI) ways of getting this done.
At least we need to have a defined interface between CAM (“commissioning tool”) and C for letting C know what was agreed about how to address AS and which RSes it should be used for.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 18 Feb 2018 16:52:34 +0000

Hi Carsten,

The challenge is that there is not a single way used in deployments. Some of the techniques fall outside the scope of the IETF (such as the manufacturing-related interactions), link layer specific approaches (such as a Blueooth Smart App), or Secure Element-based concepts.

Note that related solutions, such as ZeroTouch, ANIMA, EST, also leave this initial provisioning undefined.

I am not saying that nothing should be standardized but it will be difficult to recruit the appropriate expertise and to get the relevant companies to participate.

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: 18 February 2018 17:45
To: Hannes Tschofenig
Cc: ace
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 18 Feb 2018 09:14:40 -0800

> Note that related solutions, such as ZeroTouch, ANIMA, EST, also leave this initial provisioning undefined.

But this is not about initial provisioning (CAM-C), this is about C talking to an RS.
If there are only intra-silo ways in ACE to get this going, we should clearly document this.
Also, we need to clearly state what we believe needs to be achieved in that intra-silo step so the ACE protocol can rely on the security properties achieved there.

> I am not saying that nothing should be standardized but it will be difficult to recruit the appropriate expertise and to get the relevant companies to participate.

The IETF is generally most successful when it works on building blocks that then can be picked up by implementers and other SDOs (that pickup process then serves as another layer of quality control for us).  I don’t know why we have to be shy about this specific area for building blocks.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 18 Feb 2018 17:19:25 +0000

Hi Carsten

It seems that I have misunderstood you. If you are not talking about the initial provisioning then all we need to do is to clarify. Looking at Appendix B it appears that some text needs improvement.

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: 18 February 2018 18:15
To: Hannes Tschofenig
Cc: ace
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 19 Feb 2018 10:15:31 +0100

> At least we need to have a defined interface between CAM (“commissioning tool”) and C for letting C know what was agreed about how to address AS and which RSes it should be used for.

Why don't you make a new draft where you propose such a mechanism?

I don't think this fits in the scope of the framework draft, since the 
framework is supposed to deal with the interaction between C-AS and C-RS 
(after the onboarding has happened).

I agree that onboarding is a valid concern (which is why I wrote 
appendix B), but lets not delay draft-ietf-ace-oauth-authz any further 
by adding a whole new set of functionality in it.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Feb 2018 12:21:03 -0500

Ludwig Seitz <[email-masked]> wrote:
    > appendix B), 
    > but lets not delay draft-ietf-ace-oauth-authz any further by adding a whole
    > new set of functionality in it.

Back at the beginning of ACE it was clear that onboarding was an entire
project of itself.  That's why I argued to keep it out of the first charter.

Onboarding suffers from a tendancy to boil the ocean, combined with the
elephant/blind-men problem.    The way to tackle onboarding is not with
a single unifying ocean boiling protocol, but rather by letting each
interested party define small protocols, and over time find commonality.
I get the vision of:  https://en.wikipedia.org/wiki/Nibbler

So while it is unfortunate if some implementers feel to be "in the dark",
before we could rectify that situation, we'd have to know which implementers
we are worried about.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 20 Feb 2018 16:43:29 +0000

IMHO the biggest problem with "onboarding" is that people create new terms without specifying what they actually mean and thereby fail to see the relationship with existing work.

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 19 February 2018 19:21
To: Ludwig Seitz
Cc: [email-masked]
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

    > new set of functionality in it.

Back at the beginning of ACE it was clear that onboarding was an entire project of itself.  That's why I argued to keep it out of the first charter.

Onboarding suffers from a tendancy to boil the ocean, combined with the
elephant/blind-men problem.    The way to tackle onboarding is not with
a single unifying ocean boiling protocol, but rather by letting each interested party define small protocols, and over time find commonality.
I get the vision of:  https://en.wikipedia.org/wiki/Nibbler

So while it is unfortunate if some implementers feel to be "in the dark", before we could rectify that situation, we'd have to know which implementers we are worried about.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Feb 2018 09:05:23 -0800

> IMHO the biggest problem with "onboarding" is that people create new terms without specifying what they actually mean and thereby fail to see the relationship with existing work.

Right.  I have no idea what client registration has to do with “onboarding”, but I use that term for the initial integration of a device into a network only.

I continue to believe that we need a clear understanding of what information is exchanged during client registration that is relevant to the ACE OAuth.  There definitely will also be other information (“business logic”, and you can call the exchange of that part of the registration info “onboarding” if you like), and that is where the vendor differentiation can set in, but we should have no trouble defining the ACE content of client registration.  

If we don’t define that ACE content, there is no way to know whether ACE OAuth is secure.

Defining the ACE content of the client registration as a set of data structures also helps with achieving actual interoperability, even if additional business logic is required in a specific case.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 20 Feb 2018 17:12:27 +0000

Hi Carsten,

OAuth defined something called "Dynamic Client Registration", which gives you an idea what type of information is typically needed. Here is the RFC: https://tools.ietf.org/html/rfc7591

Regarding "initial integration of a device into a network only" isn't this sometimes called "network access authentication"?

In any case, I agree with you that we should add some text about what information is assumed to be present.

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: 20 February 2018 19:05
To: Hannes Tschofenig
Cc: Michael Richardson; Ludwig Seitz; [email-masked]
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

Grüße, Carsten