Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

[Daniel Migault <[e-mail]>]

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 <[e-mail]>
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" <[e-mail]> 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 <
> [e-mail]> 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 <[e-mail]>
>     Date: Thursday, 4 March 2021 at 17:49
>     To: Göran Selander <[e-mail]>
>     Cc: Stefanie Gerdes <[e-mail]>, Olaf Bergmann <[e-mail]>,
> Francesca Palombini <[e-mail]>, Russ Mundy <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, Loganaden Velvindron <
> [e-mail]>
>     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 <
> [e-mail]> 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" <[e-mail]> 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 <[e-mail]>
>         Date: Tue, Mar 2, 2021 at 11:09 PM
>         Subject: Re: [Ace] secdir review of
> draft-ietf-ace-dtls-authorize-14
>         To: Olaf Bergmann <[e-mail]>
>         Cc: Göran Selander <[e-mail]>, Olaf Bergmann <
> [e-mail]>, Russ Mundy <[e-mail]>, [e-mail] <
> [e-mail]>, Stefanie Gerdes <[e-mail]>, Francesca Palombini <
> [e-mail]>, Daniel Migault <daniel.migault=
> [e-mail]>
>
>
>
>         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 <[e-mail]>
> wrote:
>
>
>         Hi Daniel,
>
>         On 2021-03-02, Daniel Migault <[e-mail]> 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