Great,
thank you for the clarification on how to handle this.
El 31/1/24 a las 1:38, Mark Nottingham escribió:
On 29 Jan 2024, at 8:04 pm, Dan Garcia Carrillo wrote:
- I was a bit surprised that the spec didn't update the coap spec to put the
new resource under /.well-known/coap/eap
Dear Roni,
Thank you for the comments.
Please see responses inline.
El 24/1/24 a las 10:04, Roni Even via Datatracker escribió:
Reviewer: Roni Even
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF
Dear Esko,
Thank you for your comments.
Please, see responses inline.
El 12/1/24 a las 10:55, Esko Dijk escribió:
Hello,
I believe the draft would need a few updates to clarify the new media type and
the precise request.
* application/coap-eap is registered but never used (i.e. referred to
Dear Mark,
Thank you for your comments.
Please, see responses inline.
El 12/1/24 a las 23:23, Mark Nottingham escribió:
Hi David,
This is approved.
Non-blocking comments:
- I was a bit surprised that the spec didn't update the coap spec to put the
new resource under /.well-known/coap/eap
clarifying text will allow you to claim that the MSK is a 'strong
cryptographic key', and therefore ok to use the HKDF KDF Expand directly.
I apologize for not catching this in the early review!
Deb
On Thu, Jan 25, 2024 at 5:46 AM Dan Garcia Carrillo
wrote:
Dear Deb,
Thank you
Dear Deb,
Thank you for the update on the review.
Please let us comment inline.
El 23/1/24 a las 13:07, Deb Cooley via Datatracker escribió:
Reviewer: Deb Cooley
Review result: Has Nits
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF
Dear Carsten,
Thank you very much for the comments.
Yes, you are correct. The content of the array contains a non-empty list
of RFC 9052 algorithm identifiers.
There is a case, where the element representing the list is not sent,
that is intended to signify that the default cipher suites are
of the Authentication and Authorization for Constrained Environments
(ACE) WG of the IETF.
Title: EAP-based Authentication Service for CoAP
Authors: Rafa Marin-Lopez
Dan Garcia-Carrillo
Name:draft-ietf-ace-wg-coap-eap-09.txt
Pages: 38
Dates: 2023-10-23
Abstract
Dear Heikki,
Thank you for your comments.
Please see some notes inline.
El 27/7/23 a las 16:07, Heikki Vatiainen escribió:
On Wed, 19 Jul 2023 at 11:45, Dan Garcia Carrillo
wrote:
On 5/7/23 15:36, Alan DeKok wrote:
> Given that the EAP packets can be forced to be no more t
Dear Deb,
Thank you for your time to review the document.
El 25/7/23 a las 1:01, Deb Cooley via Datatracker escribió:
Reviewer: Deb Cooley
Review result: Has Issues
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed
Hi Alan,
Thank you very much for your time to review the document and for the
clarifications.
On 5/7/23 15:36, Alan DeKok wrote:
On Jul 5, 2023, at 4:09 AM, Eliot Lear via Datatracker wrote:
3. The terminology is a problem. On the one hand, some people like
to use the terms "IoT Device"
Hi Eliot,
Thank you very much for your time to review the document.
On 5/7/23 10:09, Eliot Lear via Datatracker wrote:
Reviewer: Eliot Lear
Review result: On the Right Track
This draft provides a means for EAP authentication via CoAP. This is
an evolution on top of EAPoL/EAP so as to not
Hi Paul,
Thank you for your time to review the document.
On 27/6/23 03:55, Paul Wouters wrote:
Hi,
I have three questions, in order of importance :)
Why does "CoAP-EAP Exporter Label" need to be an IANA registry? These
are free
form strings, no limited numbers, etc. If there is a risk
regards
Göran
*From: *Dan Garcia Carrillo
"The communication with the last resource (e.g. '/a/w') from this
point MUST be protected with OSCORE except during a new
(re)authentication (see Section 3.3)."
I don't understand why there is an exception. OSCORE seems to be
-eap-05.txt
has been successfully submitted by Dan Garcia-Carrillo and posted to the
IETF repository.
Name: draft-ietf-ace-wg-coap-eap
Revision: 05
Title: EAP-based Authentication Service for CoAP
Document date: 2021-12-05
Group: ace
Pages: 31
URL
her suite negotiation can be
verified. We think it is simpler and we can get rid of a bad request.
Does it sound reasonable?
Best regards
Göran
*From: *Ace on behalf of John Mattsson
*Date: *Monday, 25 October 2021 at 17:03
*To: *Dan Garcia Carrillo , ace@ietf.org
, EMU WG
*Subject: *Re
We agree. that this consideration applies. We will add that to
the DTLS annex.
- Probably good if the labels have “CoAP-EAP” in all the labels to
guarantee that they do not collide with anything else.
[authors] Thank you for this point. We will apply this change when using
labels for key de
mitation should be
clearly stated.
- Probably good if the labels have “CoAP-EAP” in all the labels to
guarantee that they do not collide with anything else.
Cheers,
John
*From: *Emu on behalf of Dan Garcia Carrillo
*Date: *Monday, 25 October 2021 at 13:27
*To: *ace@ietf.org , EMU WG
suites
between EAP authenticator and EAP peer cannot be verified. For
example, a man-in-the-middle could replace cipher suites in either
message which would not be noticed if the protocol is ended after step 2.
Best regards
Göran
*From: *Ace on behalf of John Mattsson
*Date: *Monday, 2
For example, a man-in-the-middle could replace cipher suites in
either message which would not be noticed if the protocol is ended
after step 2.
Best regards
Göran
*From: *Ace on behalf of John Mattsson
*Date: *Monday, 25 October 2021 at 17:03
*To: *Dan
+1 for adoption.
Best Regards,
Dan.
On 10/11/21 09:11, Marco Tiloca wrote:
+1 for adoption
Best,
/Marco
On 2021-11-09 17:50, Carsten Bormann wrote:
On 9. Nov 2021, at 17:35, Daniel Migault wrote:
Hi,
This email starts a 2 week Working Group Adoption Call for
of I-D, draft-ietf-ace-wg-coap-eap-04.txt
has been successfully submitted by Dan Garcia-Carrillo and posted to the
IETF repository.
Name: draft-ietf-ace-wg-coap-eap
Revision: 04
Title: EAP-based Authentication Service for CoAP
Document date: 2021-10-25
Group: ace
Dear Christian,
Thank you very much for your detailed revision,
Please see inline our comments.
On 16/8/21 16:40, Christian Amsüss wrote:
Hello CoAP-EAP authors and involved groups,
(CC'ing core@ as this is a review on CoAP usage),
I've read the -03 draft and accumulated a few comments;
Dear Christian,
Thank you for your detailed review. You are raising indeed very
interesting points.
Just came back from vacation and we will respond as soon as possible.
Best Regards.
On 16/8/21 16:40, Christian Amsüss wrote:
Hello CoAP-EAP authors and involved groups,
(CC'ing core@ as this
Dear ACE and EMU WG members,
In the last exchange of CoAP-EAP we intended to run OSCORE to achieve
key confirmation, a protected EAP success and the establishment of the
OSCORE security association. It was our understanding that only
integrity protection was possible but it is not the case
Dear EMU WG members,
We thought this document may be of interest to the working group.
https://datatracker.ietf.org/doc/html/draft-ietf-ace-wg-coap-eap-03
"CoAP-EAP" defines an EAP lower layer based on CoAP.
We would appreciate feedback or reviews on it.
Thank you,
Best Regards.
Dear ACE,
We have uploaded a new version of the EAP-based Authentication Service
for CoAP draft.
https://datatracker.ietf.org/doc/html/draft-ietf-ace-wg-coap-eap-03
In this version we believe that comments from Mohit and Carsten are
addressed. I hope we can discuss it during the meeting.
Hi Carsten,
Thank you very much for contributing to the discussion.
El 6/20/2021 a las 1:50 PM, Carsten Bormann escribió:
Hi Mohit,
great review!
There are a few places where I think you might be overcompensating, or where we
actually have found good solutions previously that could be
Hi Mohit:
First of all, thank you very much for review. It is really appreciated
and will help to improve the document.
Please see our comments inline
El 6/20/2021 a las 11:14 AM, Mohit Sethi M escribió:
The document is currently intended for standards track publication. But
both the
-coap-eap-02.txt
has been successfully submitted by Dan Garcia-Carrillo and posted to the
IETF repository.
Name: draft-ietf-ace-wg-coap-eap
Revision: 02
Title: EAP-based Authentication Service for CoAP
Document date: 2021-06-14
Group: ace
Pages: 24
URL
item of the Authentication and Authorization for
Constrained Environments WG of the IETF.
Title : EAP-based Authentication Service for CoAP
Authors : Rafa Marin-Lopez
Dan Garcia-Carrillo
Filename: draft-ietf-ace-wg-coap
ue, Mar 30, 2021 at 06:49:32PM +0200, Dan Garcia Carrillo wrote:
Hi ACE,
Last Thursday we had a conversation with Christian regarding possible
optimizations on how to provide the requisite of the ordering guarantee
for EAP.
This is currently achieved with an Option we define (SeqNum) to main
Hi ACE,
Last Thursday we had a conversation with Christian regarding possible
optimizations on how to provide the requisite of the ordering guarantee
for EAP.
This is currently achieved with an Option we define (SeqNum) to maintain
a sequence number. This number is initialized randomly by
.
This draft is a work item of the Authentication and Authorization for
Constrained Environments WG of the IETF.
Title : EAP-based Authentication Service for CoAP
Authors : Rafa Marin-Lopez
Dan Garcia-Carrillo
Filename
Hi Michael,
I hope the last email answered your questions.
Best Regards,
Dan.
El 22/01/2021 a las 17:38, Michael Richardson escribió:
Mohit Sethi M wrote:
> Is your concern only in the context of IoT or do you think in general
> we are better off using protocols directly without
Hi Michael,
El 21/01/2021 a las 16:26, Michael Richardson escribió:
I reviewed the document before, and my concerns were not really answered.
I can not understand what the applicability is.
Did you check the last version of the use case?
The use case is a bit more ellaborate than the
-marin-ace-wg-coap-eap-06
spans 3 pages and consumes 2 round trips just to get things started!
Surely, we can do better?
Yes, we will submit an updated version of the draft.
Best Regards,
Dan
Mališa
*From: *Dan Garcia Carrillo
*Date: *Friday 11 December 2020 at 18:41
*To: *Mališa Vučinić
Hi Mališa,
My intention was not to turn this conversation into a criticism of your
work. “deficiencies” was not the most appropriate word.
What we had in mind was a way of providing authentication to the
variety of IoT devices with different capabilities, limitations or
different types of
38 matches
Mail list logo