Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark
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:c...@tzi.org] Sent: 20 February 2018 19:05 To: Hannes Tschofenig Cc: Michael Richardson; Ludwig Seitz; ace@ietf.org Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark On Feb 20, 2018, at 08:43, Hannes Tschofenig wrote: > > 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 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. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark
On Feb 20, 2018, at 08:43, Hannes Tschofenig wrote: > > 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark
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:ace-boun...@ietf.org] On Behalf Of Michael Richardson Sent: 19 February 2018 19:21 To: Ludwig Seitz Cc: ace@ietf.org Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark Ludwig Seitz wrote: > 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. 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 , Sandelman Software Works -= IPv6 IoT consulting =- 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. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark
Ludwig Seitz wrote: > 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. 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 , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark
On 2018-02-18 17:45, Carsten Bormann wrote: On Feb 18, 2018, at 08:35, Hannes Tschofenig 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 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark
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:c...@tzi.org] 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 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:c...@tzi.org] > 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 > 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. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark
On Feb 18, 2018, at 08:52, Hannes Tschofenig 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:c...@tzi.org] > 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 > 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. > > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark
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:c...@tzi.org] 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 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. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark
On Feb 18, 2018, at 08:35, Hannes Tschofenig 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark
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:ace-boun...@ietf.org] 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: * 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 ___ Ace mailing list Ace@ietf.org 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. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
