Thanks Goran, It looks good to me. I believe that a new version can be published to reflect the changes and close this issue.
Yours, Daniel On Mon, Mar 8, 2021 at 2:35 AM Göran Selander <goran.selan...@ericsson.com> wrote: > Hi Daniel, > > Here is a proposed changed to the last sentence: > > Section 5: > OLD > "Profiles MUST specify a communication security protocol that > provides the features required above." > > NEW > "Profiles MUST specify a communication security protocol between > client and RS that provides the features required above. Profiles MUST > specify a communication security protocol RECOMMENDED to be used between > client and AS that provides the features required above. Profiles MUST > specify for introspection a communication security protocol RECOMMENDED to > be used between RS and AS that provides the features required above. These > recommendations enable interoperability between different implementations > without the need to define a new profile if the communication between C and > AS, or between RS and AS, is protected with a different security protocol > complying with the security requirements above." > > > Göran > > > On 2021-03-05, 22:23, "Daniel Migault" <mglt.i...@gmail.com> wrote: > > Thanks. "C/RS and AS" may not be very clear as it seems - at least to > me - to include the communication between the client and the RS. It seems > to me that only communications between Client and AS as well as between AS > and RS are in scope. If that is correct, I would suggest expanding "C/RS > and AS" accordingly. > Yours, > Daniel > > > On Fri, Mar 5, 2021 at 11:03 AM Francesca Palombini < > francesca.palomb...@ericsson.com> wrote: > > > Hi, > > (Adding back the ace ml that was dropped at some point) > > Here is a proposal for the paragraph in Section 5 with a different > last sentence to hopefully clarify the need for recommendations but not > mandate only one sec protocol per profile: > > Section 5: > OLD > "Profiles MUST specify a communication security protocol that > provides the features required above." > > NEW > "Profiles MUST specify a communication security protocol between > client and RS that provides the features required above. Profiles MUST > specify a communication security protocol RECOMMENDED to be used between > client and AS that provides the features required above. Profiles MUST > specify for introspection a communication security protocol RECOMMENDED to > be used between RS and AS that provides the features required above. These > recommendations enable interoperability between different implementations, > without the need to define a new profile if the communication between C/RS > and AS is protected with a different security protocol complying with the > security requirements above." > > > The proposal for the other section looks good to me. > Francesca > > From: Daniel Migault <mglt.i...@gmail.com> > Date: Thursday, 4 March 2021 at 17:49 > To: Göran Selander <goran.selan...@ericsson.com> > Cc: Stefanie Gerdes <ger...@tzi.de>, Olaf Bergmann <bergm...@tzi.org>, > Francesca Palombini <francesca.palomb...@ericsson.com>, Russ Mundy < > mu...@tislabs.com>, "draft-ietf-ace-oauth-au...@ietf.org" < > draft-ietf-ace-oauth-au...@ietf.org>, Loganaden Velvindron < > logana...@gmail.com> > Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14 > > > > HI Goran, > > > > sure any wordsmithing / alternative are fine to me. For the second > alternative the repetition of "with" may sound to me a bit strange. > > > Unless anyone objects that would be greatly appreciate to have a new > version submitted. Thanks! > > > > Yours, > Daniel > > > > > > > > On Thu, Mar 4, 2021 at 11:12 AM Göran Selander < > goran.selan...@ericsson.com> wrote: > > > Hi Daniel, > > The proposal coincides with the text I proposed Feb 22 except for one > sentence: > > "Such recommendations are expected, among others, to guarantee > independent implementations interoperate." > > This sentence does not read well to me, perhaps we can change it? For > example: > > "These recommendations are expected to enable interoperability between > independent implementations." > > . . . or even add the reason why it is only a recommendation: > > "These recommendations are expected to enable interoperability between > independent implementations, without preventing this profile to be used > with other security protocols with the AS complying with the security > requirements." > > I can make the changes and submit a new version of > draft-ietf-ace-oauth-authz in the beginning of next week when ID submission > has reopened. > > Regards > Göran > > > > On 2021-03-04, 15:54, "Daniel Migault" <mglt.i...@gmail.com> wrote: > > > Hi all, > I know everyone is very busy by now, but I am wondering if you > could provide your input so that we can think of closing this issue before > the IETF 110 - or at least as soon as possible. Our initial milestones were > to send these doc in February ;-) > > Yours, > Logan and Daniel > ---------- Forwarded message --------- > From: Daniel Migault <mglt.i...@gmail.com> > Date: Tue, Mar 2, 2021 at 11:09 PM > Subject: Re: [Ace] secdir review of > draft-ietf-ace-dtls-authorize-14 > To: Olaf Bergmann <bergm...@tzi.org> > Cc: Göran Selander <goran.selan...@ericsson.com>, Olaf Bergmann < > bergm...@tzi.org>, Russ Mundy <mu...@tislabs.com>, ace@ietf.org < > ace@ietf.org>, Stefanie Gerdes <ger...@tzi.de>, Francesca Palombini < > francesca.palomb...@ericsson.com>, Daniel Migault <daniel.migault= > 40ericsson....@dmarc.ietf.org> > > > > Thanks for the feedbacks Olaf. So I understand why we need such > flexibility on the client side. The main reason seems that the > communication with the AS is seen as bootstrapping the communication > between the client and the RS and as such we would like to keep them as > independent as possible. > I see interoperability being achieved when a) client, RS, and AS > implemented by independent vendors and b) all three follow the framework > and the given profile is sufficient to make them work together. Currently > the client - RS communication is well defined, but the client AS > communication is left to a RECOMMENDATION. > > RFC2119 defines RECOMMEND as follows: > SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood > and > carefully weighed before choosing a different course. > The question becomes how RECOMMENDED is sufficient or not. > > > > > It seems to me the definition above makes it clear that the > recommended protocol is expected to be supported, and AS or clients that > are independently developed are expected to support the recommended > protocol. To ensure the implementers are well aware of the consequences of > the implication we could clarify this explicitly. Of course this does not > provide a formal proof for interoperability, but this seems acceptable in > the scope of a framework. > > From the latest suggestion, I would propose the following changes, > - that I expect will reach consensus. Please let us know by Friday March 5 > if you agree or disagree with the proposed changes. > > > Section 5: > OLD > "Profiles MUST specify a communication security protocol that > provides the features required above." > > NEW > "Profiles MUST specify a communication security protocol between > client and RS that provides the features required above. Profiles MUST > specify a communication security protocol RECOMMENDED to be used between > client and AS that provides the features required above. Profiles MUST > specify for introspection a communication security protocol RECOMMENDED to > be used between RS and AS that provides the features required above. Such > recommendations are expected, among others, to guarantee independent > implementations interoperate." > > Section 6.2: > OLD > "Profiles MUST specify how communication security according > to the requirements in Section 5 is provided." > NEW > "The requirements for communication security of profiles are > specified > in Section 5." > > > Yours, > Daniel > > > > > > > On Tue, Mar 2, 2021 at 10:20 AM Olaf Bergmann <bergm...@tzi.org> > wrote: > > > Hi Daniel, > > On 2021-03-02, Daniel Migault <mglt.i...@gmail.com> wrote: > > > This is just a follow-up. I would like to be able to close this > issue > > by the end of the week, and so far I have not heard any issues > for > > profile mandating a protocol. On the other hand, not mandating a > > specific protocol comes with interoperability issues. So unless > more > > feed back is provided, I am currently leaning toward ensuring > > interoperability. > > > > It would be good for me to hear from the WG and understand what > concrete deployment > > issues the two statements below would raise: > > * OSCORE profile mandating the AS to support OSCORE and have > the C <-> AS using > > OSCORE. > > * DTLS profile mandating the AS to support DTLS and have the > C <-> AS using DTLS. > > I think the major issue is that a client that implements both > OSCORE and > DTLS cannot just switch from one mechanism to the other because it > must > stick to either one or the other. This also raises the question > what > happens if an AS is contacted by the client via OSCORE but the RS > only > supports DTLS: Is the client allowed to switch from OSCORE to DTLS > if > the AS says so? > > Another aspect is that we would need to add another specification > if a > client implementing the DTLS profile wants to contact the AS via > TLS. As > CoAP over TLS is well-defined, this would not make any difference > regarding the security or the handling in the application, but > mandating > DTLS in the profile would currently preclude the use of TLS. > > Grüße > Olaf > > > > > > -- > Daniel Migault > > Ericsson > > > > > > -- > Daniel Migault > > Ericsson > > > > > > > > -- > Daniel Migault > > Ericsson > > > > > > > > > > > -- > Daniel Migault > > Ericsson > > -- Daniel Migault Ericsson
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
