-Original Message-
From: Ace On Behalf Of Michael Richardson
Sent: Wednesday, September 9, 2020 8:32 AM
To: ace@ietf.org
Subject: Re: [Ace] bringing draft-selander-ace-ake-authz to ACE?
Göran Selander wrote:
> We have been working on lightweight procedures for an IoT device to
-Original Message-
From: Ace On Behalf Of Stefanie Gerdes
Sent: Wednesday, September 9, 2020 4:12 AM
To: ace@ietf.org
Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address,
DoS, and privacy
Hi John,
On 09/09/2020 11:36 AM, John Mattsson wrote:
>>> As currently
Göran Selander wrote:
> We have been working on lightweight procedures for an IoT device to
> join a network. The join process may include a number of components
> such as authentication, remote attestation, authorization, enrolment of
> locally significant certificate, etc. Much
John Mattsson writes:
> Hi Olof,
>
> Your reasoning does seem to be anchored in the draft. See inline.
>
> The current state of the draft is not acceptable.
I may agree with you in this point in so far as the sections 6.4 and 6.5
might contradict each other as Steffi has pointed out previously.
Hi John,
On 09/09/2020 11:36 AM, John Mattsson wrote:
>>> As currently specified in draft-ietf-ace-oauth-authz-35, the RS will
>>> happily send the AS address to any node that asks. This causes two
>>> problems.
>>>
>>> - If C acts on the unauthorized information, this is an attack vector
>>>
Hi Olof,
Your reasoning does seem to be anchored in the draft. See inline.
The current state of the draft is not acceptable.
Grüße,
John Preuß Mattsson
-Original Message-
From: Olaf Bergmann
Date: Wednesday, 9 September 2020 at 10:20
To: John Mattsson
Cc: "ace@ietf.org" ,
I agree very much with you Jim regarding the use on symmetric keys, and I think
this is something IETF needs to work with in the future. I think a lot of IETF
groups and drafts are using way too much symmetric keys for authentication and
key exchange. There seems to be a belief that symmetric
Hi Michael, and all,
No, this hasn't been discussed in ACE yet. But since you brought it to the
list, we may restart the discussion here.
We have been working on lightweight procedures for an IoT device to join a
network. The join process may include a number of components such as
Hello John,
Thank you for condensing this discussion thread. See inline for my
reasoning why I think that this issue is less severe than one would
expect at first:
John Mattsson writes:
> Summarizing my thoughts and opinion on this issue. Changing the title
> to highlight the issues better.
>
Hi,
Summarizing my thoughts and opinion on this issue. Changing the title to
highlight the issues better.
As currently specified in draft-ietf-ace-oauth-authz-35, the RS will happily
send the AS address to any node that asks. This causes two problems.
- If C acts on the unauthorized
I agree we need to distinguish between managed id-spaces, like groupcomm, and
cases where we do not strictly need to manage the ids.
Given the discussion we are having here, a recommendation for to add to RFC8613
would be "Each endpoint SHOULD assign its recipient identifiers." This is what
The question in my view is if this draft should create collisions. All other
drafts assigning identities to RFC 8613 that have ever been discussed in the
IETF takes efforts to not create any collisions in the first place
https://tools.ietf.org/html/draft-selander-lake-edhoc-01
The question in my view is if this draft should create collisions. All other
drafts that have ever been discussed in the IETF takes efforts to not create
any collisions in the first place
https://tools.ietf.org/html/draft-selander-lake-edhoc-01
13 matches
Mail list logo
