Hi everyone,
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.
Yours,
Daniel
On Mon, Feb 22, 2021 at 10:00 AM Daniel Migault <mglt.i...@gmail.com> wrote:
> Thanks Gorand,
>
> I think the text goes in the right direction. I am reading this as
> the framework defines the protocol should be used between the client and AS
> or client and RS. It is not mandatory, sure, but at that point, my
> understanding is that it makes it clear that if you do not follow the
> recommendations you are at your own risks and so that interoperability is
> provided by this recommendation.
> I am wondering if the framework prevents a profile to mandate a protocol
> ?. I assume not
>
> The one point I need to document in my shepherd is why recommendation is
> sufficient to provide interoperability. I am happy to hear why the WG
> thinks it is sufficient other than we want to leave that open.
>
> 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.
>
> Yours,
> Daniel
>
> On Mon, Feb 22, 2021 at 4:53 AM Göran Selander <
> goran.selan...@ericsson.com> wrote:
>
>> Hi Daniel and all,
>>
>> It seems to me that there is no full consensus, so we probably have to
>> inform the AD about the disagreement. However, we do seem to agree that we
>> want to clarify some parts of the framework. Here is yet another proposal:
>>
>> 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 a
>> communication security protocol RECOMMENDED to be used between RS and AS
>> that provides the features required above."
>>
>>
>> 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."
>>
>>
>> If there is an unequivocal positive response from the WG then I may be
>> able to publish a new version today.
>>
>> Göran
>>
>>
>>
>> On 2021-02-18, 23:03, "Daniel Migault" <daniel.migault=
>> 40ericsson....@dmarc.ietf.org> wrote:
>>
>> Hi Russ,
>>
>> Thanks for the follow-up. I was waiting clearer agreement from eth WG
>> before pinging you back. I think I agree with your understanding. My
>> understanding is that the WG is willing to specify one way (RECOMMMEND) and
>> not leave that unspecified while not preventing other configurations (MAY).
>> This obviously results in implementation not following the RECOMMENDED way
>> do not interoperate with those following these recommendations.
>>
>> The question remains open on whether we should favor openness or
>> inter-operability. I suppose that this will be raised at the IESG so we
>> need to address this issue clearly.
>>
>> Going back to the profiles, it would be good to 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.
>>
>>
>>
>> Yours,
>> Daniel
>>
>> ________________________________________
>> From: Russ Mundy <mu...@tislabs.com>
>> Sent: Thursday, February 18, 2021 3:38 PM
>> To: Daniel Migault <daniel.miga...@ericsson.com>
>> Cc: Russ Mundy <mu...@tislabs.com>; Stefanie Gerdes <ger...@tzi.de>;
>> Daniel Migault <mglt.i...@gmail.com>; Francesca Palombini <
>> francesca.palomb...@ericsson.com>; Göran Selander <goran.selander=
>> 40ericsson....@dmarc.ietf.org>; Olaf Bergmann <bergm...@tzi.org>;
>> ace@ietf.org <ace@ietf.org>
>> Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
>>
>> Hi Daniel & others,
>> Thanks for the continuing effort to make the documents more clear and
>> understandable.
>>
>> I think that there may be a fairly fundamental difficulty
>> understanding (possibly on my part) about the intended relationship between
>> the ACE framework and profile documents. It seems appropriate to me that
>> the framework would define the overall requirements (especially security
>> requirements) that implementers need to meet and profiles provide the ‘how’
>> for implementers so the result is secure, interoperable implementations
>> potentially from multiple different implementers of the framework using a
>> particular profile for that framework.
>>
>> If I’m following the discussion correctly, the changes being proposed
>> to the framework would only require a profile to define one ‘example (or
>> description)’ definition that met the security requirements of the
>> framework (even if it was the RECOMMENDED protocol set) but other protocol
>> set(s) could be used (MAY) within the definition of a profile. Including
>> what amounts to unspecified protocol set(s) that do not define how they
>> will meet security requirements of the framework will likely result in
>> different implementations that comply with the profile but do not
>> interoperate from either a protocol or a security basis (or both).
>>
>> Regards,
>> Russ
>>
>>
>> On Feb 17, 2021, at 11:16 AM, Daniel Migault <
>> daniel.miga...@ericsson.com> wrote:
>>
>> Hi,
>>
>> I think that could work for me. If the changes address the initial
>> concerns, we may publish these changes in the coming days.
>>
>> Yours,.
>> Daniel
>> ________________________________________
>> From: Stefanie Gerdes <ger...@tzi.de>
>> Sent: Wednesday, February 17, 2021 8:51 AM
>> To: Daniel Migault <daniel.miga...@ericsson.com>; Daniel Migault <
>> mglt.i...@gmail.com>; Francesca Palombini <
>> francesca.palomb...@ericsson.com>
>> Cc: Göran Selander <goran.selander=40ericsson....@dmarc.ietf.org>;
>> Russ Mundy <mu...@tislabs.com>; Olaf Bergmann <bergm...@tzi.org>;
>> ace@ietf.org <ace@ietf.org>
>> Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
>>
>> Hi Daniel,
>>
>> On 02/16/2021 04:53 PM, Daniel Migault wrote:
>>
>> > Section 5:
>> > OLD
>> > "Profiles MUST specify a communication security protocol that
>> provides
>> > the features required above."
>> > NEW
>> > "Profiles MUST specify at least one communication security protocol
>> that provides the features required above."
>> >
>> > <mglt>
>> > I have the impression that with MUST specify one expects a
>> mandatory protocol to be provided. Would the following text be acceptable ?
>> >
>> > NEW2:
>> > "Profiles RECOMMENDs at least one communication security protocol
>> that provides the features required above."
>> > </mglt>
>>
>> I don't understand it like that but I see your point. But I think
>> "RECOMMENDS" leaves too much wiggle room :). The profiles could then
>> omit the protocols completely, which I think is a bad idea.
>> Implementers
>> should have at least one example how the communication between C and
>> AS
>> is protected. Since we don't provide it in the framework we must have
>> it
>> in the profiles. How about:
>>
>> NEW3:
>> "Profiles MUST specify at least one communication security protocol
>> that
>> provides the features required above as an example how the respective
>> communication can be secured."
>>
>> Viele Grüße
>> Steffi
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Daniel Migault
> Ericsson
>
--
Daniel Migault
Ericsson
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
