Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Michael Richardson]

Dan Garcia  wrote:
> EAP can be used in the context of IoT for authentication.

But, to what end?

1) If it is onboarding a new device, then there is no connectivity until after 
authentication.
   so you can't use CoAP, you have to use 802.1x, or some equivalent, or
   create a system such as draft-ietf-6tisch-minimal-security.
   Which does use CoAP and OSCORE already.

2) If it for application authentication, then you need to use EAP to setup
   MSK for later use by a context.
   We do this in IKEv2, (D)TLS already.

So the only left would be OSCORE, yet you write "could", as if it was an 
afterthought.

Tell me what is your application?  What will be impossible if we don't do
this work?

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC draft-ietf-ace-oscore-profile-13.txt

[Marco Tiloca]

Hi Francesca,

Thank you for taking care of the review! I think the commits in the PR
address all my comments.

Best,
/Marco

On 2020-12-08 16:42, Francesca Palombini wrote:
>
> Hi Marco,
>
>  
>
> Thanks, very helpful as always! I have implemented all the comments in
> this PR https://github.com/ace-wg/ace-oscore-profile/pull/44
> 
> , if you give me the OK I can merge and upload a new submission. Happy
> to see that the comments were about clarifications and editorials.
>
>  
>
> Inline detailed answers.
>
>  
>
> Thanks again!
> Francesca
>
>  
>
> *From: *Marco Tiloca 
> *Date: *Thursday, 19 November 2020 at 17:04
> *To: *, Ace Wg 
> *Subject: *Re: [Ace] WGLC draft-ietf-ace-oscore-profile-13.txt
> *Resent from: *
> *Resent to: *Francesca Palombini ,
> , Göran Selander
> , 
> *Resent date: *Thu, 19 Nov 2020 08:03:54 -0800 (PST)
>
>  
>
> Hello OSCORE profile authors and ACE,
>
> Please, find below some WGLC comments. Hope it helps!
>
> Best,
> /Marco
>
>
>
> Section 1
>
>  
>
> * s/is not done by a/is not achieved through a
>
>  
>
> FP: Ok, fixed.
>
>  
>
> * s/after the first OSCORE exchange/after the first message exchange
>
> using OSCORE
>
>  
>
> FP: Ok, fixed.
>
>  
>
> Section 2
>
>  
>
> * "This specific identifier, encoded as a byte string, is assigned by
>
> the AS to be unique in the sets of its OSCORE Security Contexts ..."
>
>  
>
>    To avoid confusion, it's probably better to say "unique among the
>
> issued sets of OSCORE input material", since the AS can have actual
>
> OSCORE Security Contexts it uses to communicate with Clients or Resource
>
> Servers.
>
>  
>
> FP: Ok, fixed. Replaced with OSCORE security input materials
>
>  
>
> * Referring to 'id' as specific identifier, the text says: "and is not
>
> used as input material to derive the full OSCORE Security Context."
>
>  
>
>    That's correct, but then the identifier is later included in Table 1
>
> "OSCORE_Input_Material Parameters" :-)
>
>  
>
>    Perhaps it's fine to just revert to OSCORE_Security_Context_Object,
>
> both for the name of Table 1 and in different spots of the text? They
>
> would still consider 'id' as OSCORE Input Material Identifier, while
>
> aligned with the registry name from Section 9.4.
>
>  
>
> FP: I see your point, but the name was source of discussion before and
> I'd rather not go back on that. I don't think it is a problem that the
> 'id' is both part of the "OSCORE_Input_Material" object and also not
> part of the actual input material. After all it needs to be part of
> the object to identify it. What I did is to change its CBOR label
> though, to have it as 0, since I think that makes more sense that to
> be in the middle of other input materials. Note that this is a change
> that will affect implementations.
>
>  
>
> * s/If the request verifies/If the request is successfully verified
>
>  
>
> FP: Ok, fixed.
>
>  
>
> * s/until token expiration/until token deletion, due to e.g. expiration
>
> or revocation
>
>  
>
> FP: thanks for this comment. I did only keep expiration as example,
>
>  
>
> * s/the same or different/the same or a different one
>
>  
>
> FP: Ok, fixed.
>
>  
>
> * Figure 1 can also show the achievement of mutual authentication,
>
> following the OSCORE exchange at the end
>
>  
>
> FP: Good point, added.
>
>  
>
>  
>
> Section 3.1
>
>  
>
> * s/object. kid field carrying/object, with the kid field carrying
>
>  
>
> FP: Ok, fixed.
>
>  
>
> Section 3.2
>
>  
>
> * "... profile negotiation can be omitted" - I think "profile signaling"
>
> better reflects what may happen here, see also the beginning of the
>
> paragraph.
>
>  
>
> FP: Ok, fixed.
>
>  
>
> * s/in the the/in the
>
>  
>
> FP: Ok, fixed.
>
>  
>
> * s/in the 'cnf' parameter of the token/in the 'cnf' claim of the token
>
>  
>
> FP: Ok, fixed.
>
>  
>
> Section 3.2.1
>
>  
>
> * In the text entries following Table 1, the CBOR integer labels need to
>
> be aligned with the CDDL summary at the end of the section.
>
>  
>
> FP: I think it was? Now I moved id to index 0, so I switched the order
> there too.
>
>  
>
> * s/This parameter identifies the OSCORE_Input_Material/This parameter
>
> identifies the OSCORE_Input_Material object
>
>  
>
> FP: I will let the RFC editors decide on that one :) Don't want to
> become too verbose if it's not needed.
>
>  
>
> * s/the "id" type is byte string/the "id" type is bstr
>
>  
>
> FP: ah, good point. I actually changed all the description to extend
> the type (so byte string instead of bstr, etc), in order not to use
> CDDL in text.
>
>  
>
> * This version -13 has removed 

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Carsten Bormann]

On 2020-12-09, at 14:28, Christian Amsüss  wrote:
>
> follow CoRE best practices

Indeed; for instance, we “RESTified” documents in ACE before (and they not just 
became ideologically correct, but also plain better).

Grüße, Carsten



signature.asc
Description: Message signed with OpenPGP
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Proposed charter for ACE (EAP over CoAP?)

[Christian Amsüss]

Hello ACE,

On Thu, Dec 03, 2020 at 01:20:08PM +, Daniel Migault wrote:
> It seems ACE to me that ACE could be home for such a document. I am
> wondering if emu core or any other WG believe there is a better place
> for it.

If nothing else, I'd be curious to see EAP-over-CoAP this sketched out;
interactions with NOOB. (The "film a blinking LED to get mutual
authentication" sounds particularly promising).

Care would need to be taken to follow CoRE best practices (not that we'd
have a good set of standard recommendations, but at least on concrete
points we usually manage consensus), both because anything built on CoAP
coming from the IETF will be seen as something of a reference example,
and also to leverage its full optimization potential. CCs to core when
this is put on the agenda for ACE interims might be a good idea.

Go for it :-)

Christian

-- 
Es ist nicht deine Schuld, dass die Welt ist, wie sie ist -- es wär' nur
deine Schuld, wenn sie so bleibt.
(You are not to blame for the state of the world, but you would be if
that state persisted.)
  -- Die Ärzte


signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Alexander Pelov]

Dear all,

I support the inclusion of EAP-over-CoAP to the charter.

We've done work on this particular item in the past, and we've identified
the need for it in many places.. but unfortunately the draft didn't have a
proper "home" and things never advanced much. Use-cases we've seen include
places where EAP is a MUST, there is support for CoAP, but no support for
the specific FOO technology.

I am confident that it will bring value to the IOT ecosystem and that ACE
is the right home for this draft.

Cheers,
Alexander


On Wed, Dec 9, 2020 at 12:46 PM Dan Garcia  wrote:

>  Hi Michael,
>
> EAP can be used in the context of IoT for authentication. To transport EAP
> from the IoT device we need a light EAP lower-layer. This would be CoAP.
> Morover, according to EAP key management framework, keys are exported to
> protect the link and the EAP lower-layer itself. So yes, OSCORE could be
> used for that kind of protection.
>
>  Another aspect, it is that the use case we consider is the case where an
> IoT device is trying to access a security domain under the control of a
> “controller” that is connected to a backend AAA infrastructure, which acts
> as EAP authenticator.
>
>  Best Regards.
> El 07/12/2020 a las 23:09, Michael Richardson escribió:
>
> Could someone point to a use case for "EAP over CoAP" please?
> Is the goal to key an OSCORE context, or what?
>
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
>
>
>
> ___
> Ace mailing listAce@ietf.orghttps://www.ietf.org/mailman/listinfo/ace
>
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Dan Garcia]

 Hi Michael,

EAP can be used in the context of IoT for authentication. To transport 
EAP from the IoT device we need a light EAP lower-layer. This would be 
CoAP. Morover, according to EAP key management framework, keys are 
exported to protect the link and the EAP lower-layer itself. So yes, 
OSCORE could be used for that kind of protection.


 Another aspect, it is that the use case we consider is the case where 
an IoT device is trying to access a security domain under the control of 
a “controller” that is connected to a backend AAA infrastructure, which 
acts as EAP authenticator.


 Best Regards.

El 07/12/2020 a las 23:09, Michael Richardson escribió:

Could someone point to a use case for "EAP over CoAP" please?
Is the goal to key an OSCORE context, or what?

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [Emu] [core] Proposed charter for ACE (EAP over CoAP?)

[Dan Garcia]

Hi Josh,

Thanks for the support.

At first sight, I would say that, from the perspective of a very 
constrained devices and networks, it would be better to directly design 
an EAP lower-layer based on CoAP without introducing any intermediate 
layer.



Best Regards,
Dan.

On 7/12/20 16:50, josh.howl...@gmail.com wrote:


I support this; although I am curious in Dan’s opinion as to whether 
GSS on top of CoAP is also worth considering, as a way of leveraging 
the GSS EAP and other mechanisms (such as Kerberos).


Josh

*From:*Emu  *On Behalf Of *Göran Selander
*Sent:* 07 December 2020 14:08
*To:* Laurent Toutain ; Daniel 
Migault 
*Cc:* EMU WG ; c...@ietf.org WG (c...@ietf.org) 
; ace@ietf.org
*Subject:* Re: [Emu] [core] [Ace] Proposed charter for ACE (EAP over 
CoAP?)


+1.

(The recently updated ACE charter should cover this work.)

Göran

On 2020-12-03, 20:03, "core" > wrote:


Hi,

I think it is important to have EAP on top of CoAP, as Dan said it fit 
well with the last charter item.


Laurent

On Thu, Dec 3, 2020 at 2:20 PM Daniel Migault 
> wrote:


CCing emu, core

It seems ACE to me that ACE could be home for such a document. I am 
wondering if emu core or any other WG believe there is a better place 
for it.


Regarding ACE I am wondering what is the WG opinion about adding this 
item to the ACE charter.


Yours,

Daniel



From: Ace mailto:ace-boun...@ietf.org>> on 
behalf of Dan Garcia mailto:dan.gar...@um.es>>


Sent: Thursday, December 3, 2020 6:10 AM

To: ace@ietf.org  >


Subject: [Ace] Proposed charter for ACE (EAP over CoAP?)

Dear all:

Regarding the new charter, since ACE is considering the definition of 
CoAP transport for CMPv2 
(https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00 
), 
we were wondering whethere it could also consider specifying EAP 
(Extensible Authentication Protocol) over CoAP.


In this sense, we proposed this some time ago and we have 
implementations about this.


https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06 



https://www.mdpi.com/1424-8220/16/3/358 



https://www.mdpi.com/1424-8220/17/11/2646 



The usage of CoAP can provide a very light and link-layer independent 
(we even tested in LoRa networks) EAP lower-layer (transport for EAP) 
suitable for IoT enviroment. We believe this would be really useful 
since EAP provides flexibility for the authentication and it is a 
well-known protocol.


Therefore, we would like to propose the following modification to the 
charter:


"The Working Group will examine how to use Constrained Application 
Protocol (CoAP) as a transport medium for certificate enrollment 
protocols, such as EST and CMPv2, as well as a transport for 
authentication protocols such as EAP, and standardize them as needed."


This modification does not necessarily mean the adoption of our draft. 
After all, we completely understand that this would happen only if 
there is an interest in the WG. Nevertheless, we would like to avoid 
that the charter is a barrier later if there is interest in the WG to 
work in this transport of EAP over CoAP:


Any opinion about this?

Best Regards.

El 18/11/2020 a las 8:08, Daniel Migault escribió:

Hi,

Please find the proposed charter we agreed on during the interim 
meeting. If you would like to propose any change, please use the 
following URL by November 25:


https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing 
 
>


Yours,

Daniel

The Authentication and Authorization for Constrained Environments 
(ace) WG has defined a standardized solution framework for 
authentication and authorization to enable authorized access to 
resources identified by a URI and hosted on a resource server in 
constrained environments.


The access to the resource is mediated by an authorization server, 
which is not considered to be constrained.


Profiles of this framework for application to security protocols 
commonly used in constrained environments, including CoAP+DTLS