Re: [Ace] EDHOC standardization
Salvador Pérez wrote: > we have implemented a previous version of EDHOC > (draft-selander-ace-cose-ecdhe) and want to share some experiences. That's very cool. Some questions for you! > Our work so far has focused on implementation and evaluation of version > -08 of EDHOC over CoAP using real IoT hardware. The obtained results > show a significant performance improvement compared to other key > establishment protocols, such as DTLS handshake (version 1.2), > especially with respect to length and number of exchanged messages. What did you use for authentication? RSA? ECDSA? EDDSA? PSK? Were they raw public keys, or was it in a certificate? Did you try a certificate in one direction and a raw public key in the other? Did you offer more than 1 algorithm when you negotiated? > We have reviewed version -10 and noted the reduction of message > length. Based on our experience, we propose that also removing the > overhead due to security parameter negotiation could be an important > optimization, and relevant in many use cases where these parameters are > available through an out-of-band process. If the list of valid algorithms is available securely by out-of-band processes, then couldn't use this mechanism to do key agreement instead, saving 100% of the bytes on the wire? :-) We need to do security parameter negotiation in order to be agile against future algorithm attacks, and there will be algorithm attacks in the 20 to 40 year lifespans that we expect... and we need to leave space for replacing the DH process with some QMDH process. The CBOR encoding is really really very nice for this, and I wish we had CBOR when we did IKEv2. > Accordingly and taking into account that EDHOC provides a basic > security functionality for any context where security needs to be > enabled, we are currently considering the application of this protocol > in different IoT deployments, such as LoRaWAN networks, OSCORE-enabled > scenarios or its integration with capabilities. We therefore would like > to see the progress of EDHOC in standardization. I don't see how LORaWAN has enough bytes available for even EDHOC. I think that LoRaWAN needs a key agreement protocol that can be run once while the sensor is attached to the installer's smartphone. The important thing is that one is able to use the key agrement protocol over IPs A<->B, in order to setup a context that can be used between IPs C<-->D. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] EDHOC standardization
Hi Rene
Just to mention that I worked with Salvador and that the work he mention
it is part of a more general analysis we are doing with different
compression approaches for IoT deployment considering different networks
in EU projects like ANASTACIA and IoTCrawler and als for our spin-off
www.odins.es
Indeed your suggestion it is quite relevant as we are also interested on
these aspects and testing
regards
El 31/10/2018 a las 19:52, Rene Struik escribió:
Hi Salvador:
It would be interesting to explore what the impact is of lossless
compression (with side information, in terms of maintained state by
either protocol party) on sizes of message flows.
This could shed some light on the question as to how much, e.g.,
TLS1.3 message flows (or any other flows) can be squeezed and
un-squeezed "over the wire", thereby allowing a comparison of the
degree to which performance metrics are mainly due to formatting
schemes, such as [1]. I can imagine a breakdown as to how presumably
more favorable average compression ratio contribute to the mix vs.
different crypto schemes and security attributes. This would be a
useful exercise.
Rene
[1] RFC 8152 - CBOR Object Signing and Encryption (COSE)(July 2017)
On 10/31/2018 2:27 PM, Salvador Pérez wrote:
Hi Benjamin,
our results are included in a paper, which is under review for its
publication.
Regarding the comparison between EDHOC and DTLS, we have employed the
tinydtls library [1] since it is widely used to deploy DTLS in
different IoT scenarios. Note that, at the moment in which the paper
was written, such library did not offer support for version 1.3.
Anyway, DTLS 1.3 is essentially using the same handshake as TLS 1.3
("DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows” [2]).
Moreover, authors of EDHOC state that the message overhead of TLS 1.3
is much higher than EDHOC ("Compared to the TLS 1.3 handshake with
ECDH, the number of bytes in EDHOC is less than 1/3 when PSK
authentication is used and less than 1/2 when RPK authentication is
used, see Appendix E” [3-4]). Accordingly, we can claim that it is
expected that DTLS 1.3 performs worse than EDHOC (at least, regarding
message overhead) for the type of constrained implementations we are
looking at.
[1] https://projects.eclipse.org/projects/iot.tinydtls
[2] https://tools.ietf.org/html/draft-ietf-tls-dtls13-29#section-5
[3]
https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#section-1
[4]
https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#appendix-E.4
Kind regards,
Salvador Pérez
PhD student in "Future Internet Networks: Infrastructure and Security”
Faculty of Computer Science - University of Murcia
Email: salvador@um.es
Skype: salva.pf
On 31 Oct 2018, at 16:43, Benjamin Kaduk > wrote:
Hi Salvador,
On Wed, Oct 31, 2018 at 10:12:54AM +0100, Salvador Pérez wrote:
Hello authors of EDHOC,
we have implemented a previous version of EDHOC
(draft-selander-ace-cose-ecdhe) and want to share some experiences.
Our work so far has focused on implementation and evaluation of
version -08 of EDHOC over CoAP using real IoT hardware. The
obtained results show a significant performance improvement
compared to other key establishment protocols, such as DTLS
handshake (version 1.2), especially with respect to length and
number of exchanged messages.
Are your results written up anywhere? It would be great to see more
details of the comparison and the actual numbers.
Unfortunately, I don't think that DTLS 1.2 is the best comparison --
DTLS
1.3 should be seen as the current "state of the art" for DTLS, and is
expected to itself be leaner than DTLS 1.2, which might wash out some of
the results you've seen here.
Thanks,
Ben
We have reviewed version -10 and noted the reduction of message
length. Based on our experience, we propose that also removing the
overhead due to security parameter negotiation could be an
important optimization, and relevant in many use cases where these
parameters are available through an out-of-band process.
Accordingly and taking into account that EDHOC provides a basic
security functionality for any context where security needs to be
enabled, we are currently considering the application of this
protocol in different IoT deployments, such as LoRaWAN networks,
OSCORE-enabled scenarios or its integration with capabilities. We
therefore would like to see the progress of EDHOC in standardization.
Kind regards,
Salvador Pérez
PhD student in "Future Internet Networks: Infrastructure and Security”
Faculty of Computer Science - University of Murcia
Email: salvador@um.es
Skype: salva.pf
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
___
Ace mailin
Re: [Ace] EDHOC standardization
Hi Salvador:
It would be interesting to explore what the impact is of lossless
compression (with side information, in terms of maintained state by
either protocol party) on sizes of message flows.
This could shed some light on the question as to how much, e.g., TLS1.3
message flows (or any other flows) can be squeezed and un-squeezed "over
the wire", thereby allowing a comparison of the degree to which
performance metrics are mainly due to formatting schemes, such as [1]. I
can imagine a breakdown as to how presumably more favorable average
compression ratio contribute to the mix vs. different crypto schemes and
security attributes. This would be a useful exercise.
Rene
[1] RFC 8152 - CBOR Object Signing and Encryption (COSE)(July 2017)
On 10/31/2018 2:27 PM, Salvador Pérez wrote:
Hi Benjamin,
our results are included in a paper, which is under review for its
publication.
Regarding the comparison between EDHOC and DTLS, we have employed the
tinydtls library [1] since it is widely used to deploy DTLS in
different IoT scenarios. Note that, at the moment in which the paper
was written, such library did not offer support for version 1.3.
Anyway, DTLS 1.3 is essentially using the same handshake as TLS 1.3
("DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows” [2]).
Moreover, authors of EDHOC state that the message overhead of TLS 1.3
is much higher than EDHOC ("Compared to the TLS 1.3 handshake with
ECDH, the number of bytes in EDHOC is less than 1/3 when PSK
authentication is used and less than 1/2 when RPK authentication is
used, see Appendix E” [3-4]). Accordingly, we can claim that it is
expected that DTLS 1.3 performs worse than EDHOC (at least, regarding
message overhead) for the type of constrained implementations we are
looking at.
[1] https://projects.eclipse.org/projects/iot.tinydtls
[2] https://tools.ietf.org/html/draft-ietf-tls-dtls13-29#section-5
[3] https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#section-1
[4]
https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#appendix-E.4
Kind regards,
Salvador Pérez
PhD student in "Future Internet Networks: Infrastructure and Security”
Faculty of Computer Science - University of Murcia
Email: salvador@um.es
Skype: salva.pf
On 31 Oct 2018, at 16:43, Benjamin Kaduk > wrote:
Hi Salvador,
On Wed, Oct 31, 2018 at 10:12:54AM +0100, Salvador Pérez wrote:
Hello authors of EDHOC,
we have implemented a previous version of EDHOC
(draft-selander-ace-cose-ecdhe) and want to share some experiences.
Our work so far has focused on implementation and evaluation of
version -08 of EDHOC over CoAP using real IoT hardware. The obtained
results show a significant performance improvement compared to other
key establishment protocols, such as DTLS handshake (version 1.2),
especially with respect to length and number of exchanged messages.
Are your results written up anywhere? It would be great to see more
details of the comparison and the actual numbers.
Unfortunately, I don't think that DTLS 1.2 is the best comparison -- DTLS
1.3 should be seen as the current "state of the art" for DTLS, and is
expected to itself be leaner than DTLS 1.2, which might wash out some of
the results you've seen here.
Thanks,
Ben
We have reviewed version -10 and noted the reduction of message
length. Based on our experience, we propose that also removing the
overhead due to security parameter negotiation could be an important
optimization, and relevant in many use cases where these parameters
are available through an out-of-band process.
Accordingly and taking into account that EDHOC provides a basic
security functionality for any context where security needs to be
enabled, we are currently considering the application of this
protocol in different IoT deployments, such as LoRaWAN networks,
OSCORE-enabled scenarios or its integration with capabilities. We
therefore would like to see the progress of EDHOC in standardization.
Kind regards,
Salvador Pérez
PhD student in "Future Internet Networks: Infrastructure and Security”
Faculty of Computer Science - University of Murcia
Email: salvador@um.es
Skype: salva.pf
___
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
--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] EDHOC standardization
Hi Benjamin,
our results are included in a paper, which is under review for its
publication.
Regarding the comparison between EDHOC and DTLS, we have employed the tinydtls
library [1] since it is widely used to deploy DTLS in different IoT scenarios.
Note that, at the moment in which the paper was written, such library did not
offer support for version 1.3. Anyway, DTLS 1.3 is essentially using the same
handshake as TLS 1.3 ("DTLS 1.3 re-uses the TLS 1.3 handshake messages and
flows” [2]). Moreover, authors of EDHOC state that the message overhead of TLS
1.3 is much higher than EDHOC ("Compared to the TLS 1.3 handshake with ECDH,
the number of bytes in EDHOC is less than 1/3 when PSK authentication is used
and less than 1/2 when RPK authentication is used, see Appendix E” [3-4]).
Accordingly, we can claim that it is expected that DTLS 1.3 performs worse than
EDHOC (at least, regarding message overhead) for the type of constrained
implementations we are looking at.
[1] https://projects.eclipse.org/projects/iot.tinydtls
[2] https://tools.ietf.org/html/draft-ietf-tls-dtls13-29#section-5
[3] https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#section-1
[4] https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#appendix-E.4
Kind regards,
Salvador Pérez
PhD student in "Future Internet Networks: Infrastructure and Security”
Faculty of Computer Science - University of Murcia
Email: salvador@um.es
Skype: salva.pf
> On 31 Oct 2018, at 16:43, Benjamin Kaduk wrote:
>
> Hi Salvador,
>
> On Wed, Oct 31, 2018 at 10:12:54AM +0100, Salvador Pérez wrote:
>> Hello authors of EDHOC,
>>
>> we have implemented a previous version of EDHOC
>> (draft-selander-ace-cose-ecdhe) and want to share some experiences.
>>
>> Our work so far has focused on implementation and evaluation of version -08
>> of EDHOC over CoAP using real IoT hardware. The obtained results show a
>> significant performance improvement compared to other key establishment
>> protocols, such as DTLS handshake (version 1.2), especially with respect to
>> length and number of exchanged messages.
>
> Are your results written up anywhere? It would be great to see more
> details of the comparison and the actual numbers.
> Unfortunately, I don't think that DTLS 1.2 is the best comparison -- DTLS
> 1.3 should be seen as the current "state of the art" for DTLS, and is
> expected to itself be leaner than DTLS 1.2, which might wash out some of
> the results you've seen here.
>
> Thanks,
>
> Ben
>
>> We have reviewed version -10 and noted the reduction of message length.
>> Based on our experience, we propose that also removing the overhead due to
>> security parameter negotiation could be an important optimization, and
>> relevant in many use cases where these parameters are available through an
>> out-of-band process.
>>
>> Accordingly and taking into account that EDHOC provides a basic security
>> functionality for any context where security needs to be enabled, we are
>> currently considering the application of this protocol in different IoT
>> deployments, such as LoRaWAN networks, OSCORE-enabled scenarios or its
>> integration with capabilities. We therefore would like to see the progress
>> of EDHOC in standardization.
>>
>> Kind regards,
>>
>>
>> Salvador Pérez
>> PhD student in "Future Internet Networks: Infrastructure and Security”
>> Faculty of Computer Science - University of Murcia
>> Email: salvador@um.es
>> Skype: salva.pf
>>
>
>> ___
>> 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] WGLC for draft-ietf-ace-authz
This sounds like a good solution, Ludwig. Thanks for the productive conversation. -- Mike -Original Message- From: Ludwig Seitz Sent: Wednesday, October 31, 2018 2:08 AM To: Mike Jones ; ace@ietf.org Subject: Re: [Ace] WGLC for draft-ietf-ace-authz On 30/10/2018 19:52, Mike Jones wrote: > Thanks for your responses, Ludwig. > > > I could live with "access_token" having a single-byte representation, > since as you point out, it is needed for every ACE OAuth interaction. > An "error" value is only needed when something goes wrong, so that > doesn't seem like a case that needs to be optimized for space. A > two-byte "error" representation will only be used when errors have > occurred, so shouldn't be a problem. > > -- Mike > > -Original Message- From: Ace On Behalf Thank you for the quick and comprehensive answer Mike! I conclude the following: We are in agreement about giving "profile", "error", "token_type" and "grant_type" two-byte abbreviations in CBOR. "scope" and "access_token" will get a one-byte abbreviation aligned with the unused numbers from CWT claims. At IETF 103 I will propose the solution of registering all parameter abbreviations in the CWT claim registry in order to align abbreviations and avoid duplicate assignments. If a signed request (and response) format is needed I am all for using CWT in the context of ACE access token requests, responses and introspection requests and responses. I will take up that discussion at IETF 103. I will propose to make "token_type" and "grant_type" OPTIONAL, deviating from the OAuth 2.0 specs and defining the default token type to be "PoP" and the default grant_type to be "client_credentials". This will avoid having to send grant_type with every access token request and token_type with every successful access token response. Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] EDHOC standardization
Hi Salvador, On Wed, Oct 31, 2018 at 10:12:54AM +0100, Salvador Pérez wrote: > Hello authors of EDHOC, > > we have implemented a previous version of EDHOC > (draft-selander-ace-cose-ecdhe) and want to share some experiences. > > Our work so far has focused on implementation and evaluation of version -08 > of EDHOC over CoAP using real IoT hardware. The obtained results show a > significant performance improvement compared to other key establishment > protocols, such as DTLS handshake (version 1.2), especially with respect to > length and number of exchanged messages. Are your results written up anywhere? It would be great to see more details of the comparison and the actual numbers. Unfortunately, I don't think that DTLS 1.2 is the best comparison -- DTLS 1.3 should be seen as the current "state of the art" for DTLS, and is expected to itself be leaner than DTLS 1.2, which might wash out some of the results you've seen here. Thanks, Ben > We have reviewed version -10 and noted the reduction of message length. Based > on our experience, we propose that also removing the overhead due to security > parameter negotiation could be an important optimization, and relevant in > many use cases where these parameters are available through an out-of-band > process. > > Accordingly and taking into account that EDHOC provides a basic security > functionality for any context where security needs to be enabled, we are > currently considering the application of this protocol in different IoT > deployments, such as LoRaWAN networks, OSCORE-enabled scenarios or its > integration with capabilities. We therefore would like to see the progress of > EDHOC in standardization. > > Kind regards, > > > Salvador Pérez > PhD student in "Future Internet Networks: Infrastructure and Security” > Faculty of Computer Science - University of Murcia > Email: salvador@um.es > Skype: salva.pf > > ___ > 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] WGLC for draft-ietf-ace-authz
> -Original Message- > From: Ludwig Seitz > Sent: Tuesday, October 30, 2018 3:20 AM > To: Jim Schaad ; draft-ietf-ace-oauth- > au...@ietf.org > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz > > On 22/10/2018 21:09, Jim Schaad wrote: > > > > > * Registries - I am wondering if we should think about re-writing a > > couple of the registries. As things stand it appears that the > > application/ace+cbor content type is being used in 5 or 6 places. It > > might make more sense to have a registry for all of the CBOR > > abbreviations that are being used in a single table and have multiple > > columns for each of the different places were the content format is > > being used. This would make it easier to keep everything constant and can > make re-use of integer values easier to see. > > > > Yes in the light of the ensuing discussion with Mike, Carsten and Olaf it is > clear that the whole registry process needs a second (third, n-th) go-over. > > I'd very much like to have all abbreviations in a single table, however some > of > them are in the new draft-ietf-ace-oauth-params, so I'm not sure on where > to do the table, since I'd like to have the parameters from there in it. While it has some "goodness" to have all of the abbreviations in a single table, in the end that single table is going to be a registry that is maintained by IANA. This allows multiple documents to create the abbreviations and not have any overlap. I would just leave the items in oauth-params there and let them be registered on their own. Jim \> > > /Ludwig > > > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
> -Original Message-
> From: Ace On Behalf Of Ludwig Seitz
> Sent: Tuesday, October 30, 2018 5:13 AM
> To: ace@ietf.org
> Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
>
> On 25/10/2018 02:58, Mike Jones wrote:
> > IT CAN'T BE A COINCIDENCE: There's clearly a relationship between
> > many of the CBOR numeric values used in this this specification and
> > corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the
> > relationship is currently unspecified and the goals behind it are
> > undefined. The spec should be augmented to make the nature and goals
> > of this relationship explicit. I infer that there's such a
> > relationship because the Mapping Parameters to CBOR in Section 5.6.5
> > apparently carefully do not overlap with the values registered in the
> > IANA CWT Claims registry at
> > https://www.iana.org/assignments/cwt/cwt.xhtml. The Introspection
> > mappings in Section 5.7.4 apparently carefully use the same values as
> > CWT for the same things, but then adds additional values. And some of
> > these values are the same as values proposed for the CWT Claims
> > registry in 8.13. This has to be more than a coincidence but the spec
> > doesn't currently say why.
>
> For example in "5.6.5 Mapping Parameters to CBOR" there is this:
>
> "Note that we have aligned these abbreviations with the claim
> abbreviations defined in [RFC8392]."
>
> I can add some text to explain that this makes it easier to manage the
> abbreviations in code (no need to handle complex namespace issues, when
> you just use one abbreviation space). Would that address the "to make the
> nature and goals of this relationship explicit." part of your comment?
I think that this should be lost as a requirement in the document. I don't
think it makes it any easier to deal with things by having the abbreviations
from two different things line up to be the same. They need to be dealt
with on their own in code anyway.
>
> >
> > Per my earlier reviews of the ace-authz spec, I believe that the ACE
> > OAuth parameters should all be registered in the CWT Claims registry
> > because of the possibility of them being used in signed requests in a
> > manner analogous to
> > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17. The
> > parameters need to be registered to avoid future claim number
> > conflicts. While conflicts have clearly been carefully avoided to
> > date, they will inevitably occur in the future unless the values are
> > actually registered. Please do so.
> >
>
> I have avoided doing this so far, since there was no precedent from
> OAuth on doing so (registering OAuth req/resp parameters as JWT claims)
> and I was trying to align with OAuth in that respect.
> For example draft-ietf-oauth-jwsreq-17 doesn't seem to register any of
> the classical OAuth req/resp parameters as JWT claims ("This
> specification requests no actions by IANA.")
>
> How is the position of the OAuth WG on this?
>
> > DON'T SQUAT ON NUMERIC REGISTRY VALUES: Please change all
> instances
> > of numbers to be assigned by designated experts in existing
> > registries from specific values to "TBD". For instance, all the
> > values for the CWT Claims Registry in Section 8.13 (currently 12, 16,
> > and 17) should be changed to TBD. Our chair, Jim Schaad has been a
> > vigorous advocate of not squatting in my past interactions with him
> > as a Designated Expert and I believe would support this request.
> > Likewise, the "19" in the CoAP Content-Format Registration in Section
> > 8.15 should become TBD.
> >
> I get your point.
>
> Any hints on how one usually do that while still providing provisory
> numbers for interop tests?
Generally this is done by assigning temp numbers from a private number space
that are then changed at the time of registration. Additionally one can ask
for early registrations to occur. This is done at the discretion of the
chairs.
>
> > req_aud: Several examples use the "req_aud" parameter without
> > defining it. Doesn't this duplicate the "resource" parameter defined
> > by
> > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01?
> > If so, please delete this parameter and use "resource". If not, say
> > how it is different and why the differences are necessary.
> >
> > rs_cnf: There isn't a clear normative definition of this parameter.
> > It's mentioned obliquely but its purpose, syntax, and semantics
> > should be plainly stated (as with each other newly defined
> > parameter).
> >
>
> This is probably heritage from the document split.
> Note however that the framework (draft-ietf-ace-oauth-authz) defines
> some of these a CWT claims, while the params draft
> (draft-ietf-ace-oauth-params) only defines request/response parameters
> (which happen to have the same name, abbreviation and semantics).
>
> I'll go over those sections and see if there are artifacts left that
> need to be adjusted.
>
>
> > The proposed numbers in Figures 12 and 16 contain
Re: [Ace] WGLC for draft-ietf-ace-authz
Mike, Writing a document to do this is easy. I am not clear that there is anybody that is going to implement this. Are industries such as banking going to abandon JWT for CWT? Jim > -Original Message- > From: Ace On Behalf Of Mike Jones > Sent: Tuesday, October 30, 2018 11:52 AM > To: Ludwig Seitz ; ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz > > Thanks for your responses, Ludwig. > > Responding to your point about "Note that we have aligned these > abbreviations with the claim abbreviations defined in [RFC8392]." The point > of the alignment was to enable signed requests to be expressed as CWTs - > just as OAuth signed requests are expressed as JWTs. But given the high > likelihood of numeric CWT claim collisions with unregistered OAuth request > number values assigned by the spec, this won't actually work in the long term > unless the request parameters are registered as CWT claims. Collision-free > alignment without IANA registration is a fleeting situation. Please make the > alignment permanent by registering the needed claims. > > I get Jim's point that there are other ways to do signed requests. If this > working group wants to define a different signed request syntax for ACE > OAuth requests than CWTs, that's fine, but if so, please do so before this > draft finishes. If a different signed request format is used, I'll note that > there's no need for claim alignment with CWT [RFC8392] - in which case the > draft should probably abandon it up front. I'll note that abandoning the > current alignment is more work and would be more confusing to > implementers than simply using CWTs but multiple choices are possible. The > most important thing is to pick one now. Industries such as banking are > REQUIRING signed requests. > > Since you asked about signed responses, those are also in the works for > OAuth, for the same reasons - including requirements from the banking > industry. See https://openid.net/specs/openid-financial-api-jarm.html. (Just > as the OpenID Foundation standardized signed requests in 2014 in > https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests in > 2014 and then an IETF version was created, signed responses are currently > on a similar trajectory.) > > Per your question about values in IANA registries to be assigned by > designated experts being TBD, the normal way of providing short-term > values for interop purposes is to say "TBD (maybe ). For > instance, you'll see that usage at https://tools.ietf.org/html/draft-ietf-ace- > cwt-proof-of-possession-03#section-7.1.1. > > I could live with "access_token" having a single-byte representation, since as > you point out, it is needed for every ACE OAuth interaction. An "error" value > is only needed when something goes wrong, so that doesn't seem like a case > that needs to be optimized for space. A two-byte "error" representation will > only be used when errors have occurred, so shouldn't be a problem. > > -- Mike > > -Original Message- > From: Ace On Behalf Of Ludwig Seitz > Sent: Tuesday, October 30, 2018 5:13 AM > To: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz > > On 25/10/2018 02:58, Mike Jones wrote: > > IT CAN'T BE A COINCIDENCE: There's clearly a relationship between > > many of the CBOR numeric values used in this this specification and > > corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the > > relationship is currently unspecified and the goals behind it are > > undefined. The spec should be augmented to make the nature and goals > > of this relationship explicit. I infer that there's such a > > relationship because the Mapping Parameters to CBOR in Section 5.6.5 > > apparently carefully do not overlap with the values registered in the > > IANA CWT Claims registry at > > https://www.iana.org/assignments/cwt/cwt.xhtml. The Introspection > > mappings in Section 5.7.4 apparently carefully use the same values as > > CWT for the same things, but then adds additional values. And some of > > these values are the same as values proposed for the CWT Claims > > registry in 8.13. This has to be more than a coincidence but the spec > > doesn't currently say why. > > For example in "5.6.5 Mapping Parameters to CBOR" there is this: > > "Note that we have aligned these abbreviations with the claim > abbreviations defined in [RFC8392]." > > I can add some text to explain that this makes it easier to manage the > abbreviations in code (no need to handle complex namespace issues, when > you just use one abbreviation space). Would that address the "to make the > nature and goals of this relationship explicit." part of your comment? > > > > > Per my earlier reviews of the ace-authz spec, I believe that the ACE > > OAuth parameters should all be registered in the CWT Claims registry > > because of the possibility of them being used in signed requests in a > > manner analogous to > > https://
[Ace] EDHOC standardization
Hello authors of EDHOC, we have implemented a previous version of EDHOC (draft-selander-ace-cose-ecdhe) and want to share some experiences. Our work so far has focused on implementation and evaluation of version -08 of EDHOC over CoAP using real IoT hardware. The obtained results show a significant performance improvement compared to other key establishment protocols, such as DTLS handshake (version 1.2), especially with respect to length and number of exchanged messages. We have reviewed version -10 and noted the reduction of message length. Based on our experience, we propose that also removing the overhead due to security parameter negotiation could be an important optimization, and relevant in many use cases where these parameters are available through an out-of-band process. Accordingly and taking into account that EDHOC provides a basic security functionality for any context where security needs to be enabled, we are currently considering the application of this protocol in different IoT deployments, such as LoRaWAN networks, OSCORE-enabled scenarios or its integration with capabilities. We therefore would like to see the progress of EDHOC in standardization. Kind regards, Salvador Pérez PhD student in "Future Internet Networks: Infrastructure and Security” Faculty of Computer Science - University of Murcia Email: salvador@um.es Skype: salva.pf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
On 30/10/2018 19:52, Mike Jones wrote: Thanks for your responses, Ludwig. I could live with "access_token" having a single-byte representation, since as you point out, it is needed for every ACE OAuth interaction. An "error" value is only needed when something goes wrong, so that doesn't seem like a case that needs to be optimized for space. A two-byte "error" representation will only be used when errors have occurred, so shouldn't be a problem. -- Mike -Original Message- From: Ace On Behalf Thank you for the quick and comprehensive answer Mike! I conclude the following: We are in agreement about giving "profile", "error", "token_type" and "grant_type" two-byte abbreviations in CBOR. "scope" and "access_token" will get a one-byte abbreviation aligned with the unused numbers from CWT claims. At IETF 103 I will propose the solution of registering all parameter abbreviations in the CWT claim registry in order to align abbreviations and avoid duplicate assignments. If a signed request (and response) format is needed I am all for using CWT in the context of ACE access token requests, responses and introspection requests and responses. I will take up that discussion at IETF 103. I will propose to make "token_type" and "grant_type" OPTIONAL, deviating from the OAuth 2.0 specs and defining the default token type to be "PoP" and the default grant_type to be "client_credentials". This will avoid having to send grant_type with every access token request and token_type with every successful access token response. Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
