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

[Hannes Tschofenig <[e-mail]>]

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:[e-mail]]
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

On Feb 18, 2018, at 08:52, Hannes Tschofenig <[e-mail]> wrote:
>
> 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.

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

>
> Ciao
> Hannes
>
> -----Original Message-----
> From: Carsten Bormann [mailto:[e-mail]]
> 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
>
> On Feb 18, 2018, at 08:35, Hannes Tschofenig <[e-mail]> wrote:
>>
>> 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.
>
> 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
>
> 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.
>
>

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.