[Ace] Constrained Node/Network Cluster @ IETF96: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF96. Remember that there is still quite some potential for changes. Apart from COSE on PLUS (ouch), and the maybe more personal conflicts of ACE on QUIC and 6LO on ARTAREA, I'm not seeing a lot of hurt this time. Moves

Re: [Ace] Asymmetric signature performance

There is nothing in IP that makes solving this problem particularly hard, so I have no idea where this argument is coming from. Meeting your favorite security objective is hard in the systems we are talking about. Where the system does not actually have this security objective, we can go ahead

Re: [Ace] I-D Action: draft-ietf-ace-actors-04.txt

As you can see, the work on the actors draft has resumed. We were driven to submit an intermediate version (that addresses mostly comments by Michael Richardson) to keep the draft from expiring. A version that addresses all the outstanding comments will follow. Grüße, Carsten > A diff from the

Re: [Ace] where are we with draft-somarju-ace-multicast?

On 22 Dec 2016, at 09:42, Eliot Lear wrote: > > I would like to see this draft adopted by the working group, an > appropriate applicability statement added, and see it shipped. +1 (Everything has been said already that needs to be said about the issue.) Grüße, Carsten

[Ace] SWORN: Secure Wake on Radio Nudging

I just submitted draft-bormann-t2trg-sworn-00.txt, which describes a secure way for applications to wake sleepy nodes. For 6lo, it may be of interest as a way to expose a MAC layer feature to the application layer in a secure way. For CoRE, it shows an unusual way to use the CoAP protocol.

Re: [Ace] CWT and PoP Tokens

On Apr 21, 2017, at 09:56, Hannes Tschofenig wrote: > > * the CWT spec maps some of the JWT claims to CBOR but does not contain > anything regarding PoP tokens. > * the ACE framework provides the PoP-related components (see >

[Ace] Constrained Node/Network Cluster @ IETF98: FINAL AGENDA

Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF98. Remember that agenda definitions are never really "FINAL"... "While this is considered the final agenda for printing, changes may be made to the agenda up until and during the meeting. Updates will be reflected on

Re: [Ace] I-D Action: draft-ietf-ace-actors-05.txt

tle : An architecture for authorization in constrained > environments >Authors : Stefanie Gerdes > Ludwig Seitz > Goeran Selander > Carsten Bormann > Filename: draft-ietf-ace-actors

Re: [Ace] Call for adoption for draft-somaraju-ace-multicast-02

On 7 Mar 2017, at 02:55, Jim Schaad wrote: > > After thinking about this for a long time, I will reluctantly state a > position. > > I do not believe that the WG should adopt this document at least until such a > time as a version has been released which does a

Re: [Ace] [core] IKEA uses CoAP and DTLS for their smart lights

On Apr 28, 2017, at 15:31, Ludwig Seitz wrote: > > FYI > > > https://mjg59.dreamwidth.org/47803.html Yes. There has been a flurry of activity in the tinydtls and libcoap projects in the last weeks, as these seem to be the implementations of choice to talk to the devices

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

On May 16, 2017, at 00:16, Mike Jones wrote: > > I disagree with the suggestion (tracked in > https://github.com/erwah/ietf/issues/37) about claims that must be > understood. We shouldn’t force implementations to understand claims not used > by their application.

[Ace] Constrained Node/Network Cluster @ IETF99: "FINAL" AGENDA

Here is my usual eclectic condensed agenda, now based on the "FINAL" AGENDA for IETF99. Compared to the last week's draft agenda, dnssd and acme were moved. (It is likely that there still will be some more changes after this "FINAL" agenda.) ACE people are going to miss DISPATCH (ARTAREA) again

[Ace] Constrained Node/Network Cluster @ IETF99: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF99. Remember that there is still quite some potential for changes. ACE people are going to miss DISPATCH (ARTAREA) again -- not sure if there would have been be any discussions relevant to Constrained Nodes/Networks in

Re: [Ace] [ace] WGLC on draft-ietf-ace-cbor-web-token

Review of draft-ietf-ace-cbor-web-token-04.txt Reviewer: Carsten Bormann Review result: A few technical issues; could use an editorial round This specification sets out to translate JWT (RFC 7519) from JSON to the CBOR world. As such, it is relatively straightforward, and there are only a few

Re: [Ace] draft-ietf-ace-actors

On Sep 15, 2017, at 12:40, Ludwig Seitz wrote: > > I'm happy to help progressing the document, but since I'm not the editor I > don't want to unilaterally make changes to the document. > > @Carsten: please feel free to task me with work that needs to be done to > progress

[Ace] FIXED: Constrained Node/Network Cluster @ IETF100: DRAFT AGENDA

(Sorry for the resend; the previous version missed out on all meetings in the room "VIP A", and I didn't see those conflicts either.) Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF100. Remember that there is still quite some potential for changes. The CBOR/SUIT

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

Hi Ludwig, > I'm not sure what the RFC editors prefer as affiliation > (I've seen both): > > -- > E. Wahlstroem > > -- OR > E. Wahlstroem > (no affiliation) > — I don’t know what the RFC editor prefers her, but I find “no affiliation” jarring — leaving the space open is much better. > === >

Re: [Ace] Relaxing OAuth-ACE profiles

On Dec 18, 2017, at 14:01, Hannes Tschofenig wrote: > > Hence, I created a pull request that relaxes the OAuth-ACE profiles in the > following way: > * It allows profiles to specify what protocols and encodings they use on the > client to AS interface (in addition to

[Ace] Fwd: New Version Notification for draft-ietf-ace-actors-06.txt

e...@ri.se <mailto:ludwig.se...@ri.se>>, "Carsten > Bormann" <c...@tzi.org <mailto:c...@tzi.org>>, "Goeran Selander" > <goran.selan...@ericsson.com <mailto:goran.selan...@ericsson.com>>, "Stefanie > Gerdes" <ger...@tzi.org <m

Re: [Ace] Questions about draft-ietf-ace-oauth-authz

> On Nov 14, 2017, at 17:59, Ludwig Seitz wrote: > > Hello ACE, > > during the IETF 100 session there were a number of questions on > draft-ietf-ace-oauth-authz that I would like to bring to the list for > feedback: > > 1.) Currently the framework requires the use of

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token

Just wondering: Are you aware that this is a second WGLC? You didn’t mention that. (And do we really need four weeks for a second WGLC? Even factoring in the IETF week?) Grüße, Carsten > On Nov 1, 2017, at 18:24, Benjamin Kaduk wrote: > > This message begins a working group

Re: [Ace] WGLC on draft-ietf-ace-cbor-web-token (ends 29 November)

On Dec 11, 2017, at 12:02, Esko Dijk wrote: > > given that a CBOR decoder would normally ignore tags If you are talking about CBOR tags (I’ve lost the context of the current discussion): A generic CBOR decoder would normally present those to the application. Simply

[Ace] Constrained Node/Network Cluster @ IETF100: FINAL AGENDA

Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF100. Remember that "FINAL" means this will be the basis for printed agenda sheets, there is still some potential for changes after that. The CBOR/SUIT conflict has been fixed, but now there is overlap between 6TISCH

Re: [Ace] Early media-type registration for EST over CoAP

On May 15, 2018, at 10:56, Hannes Tschofenig wrote: > > I am curious whether it would be possible to ask for early media-type > registration of at least these two types: > - application/pkcs7-mime > - application/pkcs10 There already are registered. I think you are

Re: [Ace] Early media-type registration for EST over CoAP

sten, > > Yes, I am talking about the Content-Format numbers for them. > Would rt="ace.est" be the parameter you are talking about? > > Ciao > Hannes > > -Original Message- > From: Carsten Bormann [mailto:c...@tzi.org] > Sent: 15 May 2018 11:45

Re: [Ace] Early media-type registration for EST over CoAP

: make a proposal and raise this on core-paramet...@ietf.org so we get the needed input from the designated expert. Grüße, Carsten > > Ciao > Hannes > > From: Carsten Bormann [mailto:c...@tzi.org] > Sent: 16 May 2018 12:30 > To: Hannes Tschofenig > Cc: ace@ietf.org; core

Re: [Ace] How to specify DTLS MTI in COAP-EST

On Jun 7, 2018, at 18:30, Hannes Tschofenig wrote: > > why don't you just reference https://tools.ietf.org/html/rfc7925? That describes the status of mid-2016. Can we do something forward-looking? Grüße, Carsten ___ Ace mailing list Ace@ietf.org

[Ace] Constrained Node/Network Cluster @ IETF102: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF102. Remember that there is still quite some potential for changes. ACE vs. DISPATCH seems to become a common occurrance; at this rate, I'll probably never see a DISPATCH meeting again. CBOR vs. 6LO is maybe just a

Re: [Ace] [core] Early media-type registration for EST over CoAP

On Jun 19, 2018, at 16:33, Michael Richardson wrote: > > We have already had some round trips and document changes thanks to Klaus > Hartke. Yes, but the IANA considerations section currently still has multict in it — that might confuse IANA. Grüße, Carsten

Re: [Ace] How to specify DTLS MTI in COAP-EST

We had that discussion at the SUIT hackathon earlier this week, as well. To get actual interoperability there, of course, every test pair needs to decide between P-256 and 25519 (and, maybe, use hash-based instead; but that is more appropriate for firmware update than for other uses). The

[Ace] New Version of draft-fossati-core-multipart-ct-04.txt

In https://github.com/SanKumar2015/EST-coaps/pull/50, Klaus has proposed to introduce a media type for efficiently combining multiple representations, along with the Content-Format numbers of their media types, into a single representation. I believe we have needed such a media type in other

Re: [Ace] How to specify DTLS MTI in COAP-EST

Hi Michael, On Jun 7, 2018, at 01:32, Michael Richardson wrote: > > We think that we'd like to use SHOULD+ for Curve25519 and MUST- for > secp256r1, Sounds good to me. > but we aren't sure that the WG will like us to use so many > words as IPsec to say so. Can we just reference those words?

[Ace] Constrained Node/Network Cluster @ IETF102: FINAL AGENDA

I forgot to send the update of my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF102. Remember that "FINAL" means this will be the basis for printed agenda sheets, there is still some potential for changes after that. The only change from the previous draft agenda (apart

Re: [Ace] draft-ietf-ace-cbor-web-token-08 - CWT CBOR Tag

On Oct 19, 2017, at 18:41, Jim Schaad wrote: > > • I already know that this is going to be a CWT so I save a byte. > • I don’t know so I waste a tag byte in that case. Right. In REST protocols, we usually have a media type, so we don’t need the CBOR Tag.

Re: [Ace] shepherd review of draft-ietf-ace-cbor-web-token-11

On Feb 2, 2018, at 23:24, Benjamin Kaduk wrote: > > Finally, in the acknowledgments, we can ask the RFC Editor to use > the non-ASCII "Gőran" if he so desires. (Last I heard the tooling > isn't there to use non-ASCII for internet drafts yet, though.) We have the same issue in

Re: [Ace] CBOR Web Token (CWT) draft addressing shepherd review comments

» Depending upon the values being requested, registration requests are evaluated on a Standards Track Required, Specification Required, Expert Review, or Private Use basis [RFC8126] « This might give the impression that IANA registrations can be made on a “Private Use” basis. RFC

Re: [Ace] Removal of the Client Token from ACE-OAuth draft

On Feb 5, 2018, at 08:01, Ludwig Seitz wrote: > > I agree that interest for this use case has been lukewarm at most in the WG. Well, IoT is a vast field and we cannot expect all areas of it to be represented equally well in the WG yet. > I will remove that feature from the

[Ace] Constrained Node/Network Cluster @ IETF101: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF101. Remember that there is still quite some potential for changes. The painful ones (not necessarily fixable) this time include: DINRG vs. ACE, CBOR vs. TEEP, ROLL vs. SUIT vs. OCF/WoT; also CORE vs. ANIMA, CORE vs.

Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

On Feb 20, 2018, at 08:43, Hannes Tschofenig wrote: > > IMHO the biggest problem with "onboarding" is that people create new terms > without specifying what they actually mean and thereby fail to see the > relationship with existing work. Right. I have no idea what

[Ace] Constrained Node/Network Cluster @ IETF101: "FINAL" AGENDA

Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF101. Remember that "FINAL" means this will be the basis for printed agenda sheets, there is still some potential for changes after that. SUIT is now on top of CORE (!??). (Also, ICE has moved.) The painful ones this

Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark

On Feb 18, 2018, at 08:35, Hannes Tschofenig wrote: > > Hi Carsten, > > We should maybe add that this information is provisioned either during > manufacturing, via a commissioning tool or some other mechanisms. Not sure > whether this will indeed add more but it

Re: [Ace] [core] Early media-type registration for EST over CoAP

On Jun 19, 2018, at 14:11, Carsten Bormann wrote: > > Since the registry that we are registering into does not fulfill the > preconditions of RFC 7120 Section 2 point (a), (Sorry, wasn’t awake enough. If we go for the 256- space, of course it does. And we probably do.) So w

Re: [Ace] [core] Early media-type registration for EST over CoAP

; Sent: 24 May 2018 15:55 > To: Carsten Bormann > Cc: Hannes Tschofenig; core; ace@ietf.org > Subject: Re: [core] [Ace] Early media-type registration for EST over CoAP > > Ok, I will raise the experts to-morrow. > > Peter > > Carsten Bormann schreef op 2018-05-2

Re: [Ace] Review Comments on -03

Hi Jim, > On Jul 15, 2018, at 20:48, Jim Schaad wrote: > > * It is too bad that we don't have the generic coap schemas defined yet so > that we can use that as part of the URL returned with an access denied > response. Can you expand on that? What should we have defined? Grüße, Carsten

Re: [Ace] Review Comments on -03

On Jul 16, 2018, at 08:26, Jim Schaad wrote: > > In the event of an unauthorized, the RS has the ability to return a URL to > the AS it knows about. If it returns coaps://AS/token, then this might be > thought of implying that one needs to use dtls to talk to the AS rather than > using

Re: [Ace] [core] Early media-type registration for EST over CoAP

Hi Michael, On Jun 20, 2018, at 21:39, Michael Richardson wrote: > > The multipart response is only need for systems where the private key will be > generated on the EST server: and a number of implementers are keen *not* to > do that, so the multipart is not urgent to as many people. That is

[Ace] Updating draft-ietf-ace-actors for Bangkok

During processing the framework and profiles drafts, it became clear that we do need the architectural considerations written up in draft-ietf-ace-actors. While we had to put all energy into the solutions documents so far, we now have an opportunity to fix the informational document as well.

Re: [Ace] Updating draft-ietf-ace-actors for Bangkok

Done: Htmlized: https://tools.ietf.org/html/draft-ietf-ace-actors-07 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-07 Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] FW: New Version Notification for draft-schaad-cnf-cwt-id-00.txt

On Oct 22, 2018, at 20:49, Jim Schaad wrote: > > I did not like the idea of using key identifiers when linking together CWTs > for authorization purposes. Right, they are not very useful as they don’t say anything about the authorization information that is attached to that key in a

[Ace] Constrained Node/Network Cluster @ IETF103: "FINAL" AGENDA

Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF103. A few changes from the DRAFT AGENDA. I waited a bit with sending this as a few more side meetings have become known, as well. Of course, "FINAL" doesn't mean final. cbor/teep and 6tisch/ace (was suit) are

Re: [Ace] WGLC for draft-ietf-ace-authz

+1 for making all the CWT-like structures into real CWTs. Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC for draft-ietf-ace-authz

ote: > > Carsten Bormann writes: > >> +1 for making all the CWT-like structures into real CWTs. > > Not every key/value-pair encoded as CBOR is automatically a CWT. What > happens here is that we are trying to force every protocol element that > is required to solve an appli

Re: [Ace] WGLC for draft-ietf-ace-authz

On Oct 25, 2018, at 19:41, Michael Richardson wrote: > > OAuth claim statements too confusing Indeed, there is a problem there (as with many things inherited from OAuth). We might want to fix those issues for the purposes ACE, even if it wasn’t in the domain for the ANIMA work. Grüße, Carsten

Re: [Ace] Idnits on draft-ietf-ace-cwt-proof-of-possession-05

On Nov 30, 2018, at 17:50, Roman Danyliw wrote: > > /protected header / h’A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/, You may want to switch to the << … >> form: > /protected header / << { /alg/ 1: 10 /AES-CCM-16-64-128/ } >>, Grüße, Carsten ___

[Ace] draft-bormann-core-ace-aif-06 - An Authorization Information Format (AIF) for ACE

As requested during the IETF104 meeting, I resubmitted > > https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ > Maybe this would be a good time to consider whether ACE can make use of this? Grüße, Carsten

[Ace] Constrained Node/Network Cluster @ IETF104: FINAL AGENDA

Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF104. Remember that, even though this will now go to the printers, there is still some potential for changes. The somewhat annoying coflicts cose/teep and lpwan/t2trg remain. I also don't like that I'll have to miss the

[Ace] To Panos

Panos: Please give me an email address for you that I can reach. (Sorry for multicasting this.) Grüße, Carsten - The following addresses had permanent fatal errors - (reason: 550 Connections from mailhost.informatik.uni-bremen.de (2001:638:708:30c9::12) are being rejected

Re: [Ace] [T2TRG] Constrained Node/Network Cluster @ IETF104: DRAFT AGENDA

On Feb 23, 2019, at 05:59, Carsten Bormann wrote: > > > Here is my usual eclectic condensed agenda based on the DRAFT AGENDA > for IETF104. Remember that there is still quite some potential for > changes. And how could I forget: FRIDAY, March 22, 2019 — Fri 0930–1800 T2T

Re: [Ace] Embedded Content Types

On Feb 21, 2019, at 23:31, Jim Schaad wrote: > > I am thinking of two different URLs, that is not do the difference by a query > parameter but by changing the URI. Note that the query parameters are part of the URI, so fundamentally there is no difference between putting the info there or in

Re: [Ace] Embedded Content Types

On Feb 20, 2019, at 22:33, Panos Kampanakis (pkampana) wrote: > > If we broke the requests to different URIs, it means that a client needs to > keep track of his transactions and on top of it he needs to correlate the key > and the cert he receives at a later time. I think this is just a

Re: [Ace] [core] Pub Sub and multicast

I’m certainly interested. Not sure I understand “ • Additionally, the Subscriber must be authorized to subscribe, otherwise an attacker could DoS external nodes that do not want to receive the publications”. Whether the attacker is authorized to subscribe and whether the actual notification

Re: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21

> On Feb 18, 2019, at 15:59, Sebastian Echeverria > wrote: > > Hello, > > I have a short comment about error responses from an RS in > draft-ietf-ace-oauth-authz-21. More specifically, my question is about > section 5.8.2. In the second paragraph, it states “The response code MUST be >

[Ace] Constrained Node/Network Cluster @ IETF105: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF105. Remember that there is still quite some potential for changes. Conflicts that meet the eye: COSE/TEEP again! ROLL/SUIT/DINRG and 6TISCH/ACE are maybe slightly less annoying. (The poor TEEP people get to both start

[Ace] Constrained Node/Network Cluster @ IETF105: FINAL AGENDA

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

[Ace] Constrained Node/Network Cluster @ IETF105: FINAL AGENDA

Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF105. Remember that, even though this will now go to the printers, there is still some potential for changes. Conflicts that meet the eye: COSE/TEEP stays; ROLL/SUIT/DINRG and 6TISCH/ACE are maybe slightly less

Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

On Aug 12, 2019, at 14:08, Ludwig Seitz wrote: > > As far as I gather from the comments (especially from Carsten), we'd solve > this by referencing section 6 of RFC 7049. I will consult with my co-authors, > but I think this is the right solution. That is not what I said. Grüße, Carsten

Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

On Jul 30, 2019, at 19:10, Jim Schaad wrote: > From: Benjamin Kaduk > > We should be consistent across examples about whether the use of CBOR > diagnostic notation also requires a disclaimer about "with linebreaks for > readability". > > [JLS] I don't believe that this disclaimer needs to be

Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON

There is no strong interdependency between Web transfer protocol (HTTPS/CoAPS) and data format. COSE works great over HTTPS, and if it must be, you can ship JOSE over CoAPS. Grüße, Carsten > On Oct 2, 2019, at 14:00, Cigdem Sengul wrote: > > Hello all, > > I am trying to implement this

[Ace] Constrained Node/Network Cluster @ IETF106: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF106. Remember that there is still quite some potential for changes. Conflicts that meet the eye: LAKE/SUIT (already noted by Russ), BOF on top (thing security): TMRID. ACE/RATS are also both security technologies that

[Ace] Constrained Node/Network Cluster @ IETF106: FINAL AGENDA

Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF106. Remember that, occasionally, futher agenda changes do happen. Quite a bit has been moved around from the draft agenda. LAKE no longer conflicts with SUIT, TMRID is now on top of ROLL and TEEP which is maybe a bit

Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON

On Oct 3, 2019, at 08:42, Hannes Tschofenig wrote: > > but for HTTP we decided to do the work on OAuth, where it got stuck because > the IoT-interested people are not there and the Web folks want something else. …so should we organize a mass-walkin of the ACE people at the OAuth meeting in

Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

On Dec 20, 2019, at 01:47, Benjamin Kaduk wrote: > >> The statement above >> >> When omitted, they are logically >> assumed to be the transport protocol destination address and port >> respectively. Explicit Uri-Host and Uri-Port Options are >> typically used when an

Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

On Dec 20, 2019, at 17:34, Klaus Hartke wrote: > > I would prefer if draft-ietf-ace-coap-est didn't say anything here, > since the Uri-Host and Uri-Port options and whether they should be > omitted or not is entirely specified by CoAP [RFC7252].* Klaus has an important point here. We need to

Re: [Ace] [EXTERNAL] RE: Access token question

On 2020-02-24, at 18:04, Jim Schaad wrote: > > • The proposal from Carsten that has not get adopted anywhere yet. Well, not adopted in the literal sense, but it has been used as a blueprint both in research works and in standardization. The main question that is holding this back from

[Ace] Constrained Node/Network Cluster @ IETF107: FINAL AGENDA

Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF107. Remember that, occasionally, futher agenda changes do happen. Not much change from the DRAFT AGENDA. SUIT has moved to Friday, now on top of 6lo. The other security/not-so-much-security conflicts in the IoT space

Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

On 2020-03-04, at 23:33, Henk Birkholz wrote: > > Option 1.) is "out of the question" as a reply from a COSE WG chair. Option 1.) is "out of the question" as a reply from the author of the COSE specification. (And at least one other WG member agrees.) FTFY… Grüße, Carsten

Re: [Ace] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

On 2020-03-04, at 19:40, Henk Birkholz wrote: > > 1.) go to COSE and ask for a "null signature", https://en.wikipedia.org/wiki/Just_Say_No > 2.) go to ACE and ask for an "unsigned token" option, or > 3.) go to CBOR and ask for a tag for "naked" CWT Claim Sets (i.e., that are > not signed). I

[Ace] Constrained Node/Network Cluster @ IETF107: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF107. Remember that there is still quite some potential for changes. Conflicts that meet the eye: ROLL vs. COSE/TEEP, LPWAN vs. RATS, and LAKE vs. RATS, WPACK vs. ACE. The latter two might be a bigger problem, while

Re: [Ace] [Rats] [Cbor] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

Hi Ned, What I was trying to say is that the Unprotected CWT Claims Set (UCCS) is not a CWT, but an UCCS. So I wouldn’t call it a token (which implies some form of protection to me). But it is still a useful data structure to carry around. > On 2020-03-06, at 20:59, Smith, Ned wrote: > >

Re: [Ace] [Cbor] [Rats] RATS Entity Attestation Tokens (EAT) - to be a CWT or not to be a CWT?

Hi Jim, > On 2020-03-06, at 20:13, Jim Schaad wrote: > > There is a very high chance that making this change is going to lead one into > a situation where they are going to need to change their because people are > going to start using this tag all of the time and not just when the claims >

Re: [Ace] draft-ietf-ace-oauth-authz

On 2020-05-04, at 08:42, Seitz Ludwig wrote: > > For the sake of getting the document finished before I die of old age ;-) > would it be possible to specify this in a separate document? I think there may be multiple of these RT registrations, because the fact that a resource is part of an AS

Re: [Ace] draft-ietf-ace-oauth-authz

On 2020-05-05, at 06:54, Jim Schaad wrote: > > I have much the same problem. While a client could find an AS which would > authenticate the client, I don't know how the client would establish any > degree of trust in the AS which is going to give it tokens. Hence the four-corner model [1].

Re: [Ace] [ace] Fwd: New Version Notification for draft-tiloca-ace-revoked-token-notification-01.txt

> > Comments are very welcome. (1) I can’t parse the binary representation of the String value of ENCODED_TOKEN, which would depend on the used charset. What charset? JSON does not have a charset. (I’m probably misreading this.) What *is* the “String value of

Re: [Ace] draft-ietf-ace-oauth-authz

urity domain, instead of having to do the bootstrapping again and again for each server that device needs to access. Grüße, Carsten > > Jim > > > -Original Message- > From: Carsten Bormann > Sent: Monday, May 4, 2020 10:38 PM > To: Jim Schaad > Cc: Benjam

Re: [Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT

On 2020-05-18, at 17:21, Carsten Bormann wrote: > > [1]: https://tools.ietf.org/html/draft-bormann-core-ace-aif Benjamin reminds me that this has -core- as the crucial third word of the draft name. I hope that doesn’t get in the way if we decide to pick this up as an (informationa

[Ace] AIF as a suggestion in key-groupcomm; AIF in MQTT

As I said today, the role of AIF [1] in ACE documents can only be as a suggestion, or as a starting point, because it assumes that the (resource) names are static, and something application-specific has to be added for more dynamic names. The current MQTT proposal [2] is different in three

[Ace] Constrained Node/Network Cluster @ IETF109: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF109. Remember that there is still quite some potential for changes. The conflicts that meet the eye this time seem to impact generalists only. Great scheduling job! All times *on my agenda* are in UTC (the default page

Re: [Ace] "default value" for authz-info endpoint

On 2020-06-01, at 11:13, Seitz Ludwig wrote: > > Hi Ben, > > I had a look at the well-known URI list at IANA and it seems that for vanilla > OAuth 2.0 endpoints (authorization, token, introspect) there are no > well-known URI:s either. What exists is an URI used by the authorization > server

[Ace] Constrained Node/Network Cluster @ IETF109: "FINAL" AGENDA

Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF109. Remember that further agenda changes can still happen. Very little has changed with respect to the draft agenda. WEBTRANS does meet, and CFRG and IRTFOPEN have been moved around (CFRG now on top of CORE,

Re: [Ace] Extended REST model comment

On 2020-06-30, at 16:43, Jim Schaad wrote: > > In trying to formalize a policy for the RD testing, I ended up with > something that I think needs to be noted in this section. There is a > difference between the following statements: > > Access is granted to resources created by the client. >

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

On 2020-06-30, at 12:19, Olaf Bergmann wrote: > > NEW: > > All CBOR data types are encoded in canonical CBOR as defined in > Section 3.9 of {{RFC7049}}. This implies in particular that the > `type` and `L` components use the minimum length encoding Note that 7049bis, which has been

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

>> >> I would generally prefer to avoid the need for deterministic/canonical >> encoding — is there really a need to re-encode the token? > > There is no need to re-encode the token, and I do not expect that this > would happen if the authorization server has used a finite length. So would we

[Ace] Constrained Node/Network Cluster @ IETF108: FINAL AGENDA

Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF108. Remember that, occasionally, further agenda changes do happen. There has been no change from the DRAFT AGENDA in the Conflicts I noted: LAKE/SUIT (!). ACE/RATS. (I think 6LO/COSE can be ignored.) The only

[Ace] AIF as discussed today (Re: I-D Action: draft-bormann-core-ace-aif-08.txt)

mation Format (AIF) for ACE > Author : Carsten Bormann > Filename: draft-bormann-core-ace-aif-08.txt > Pages : 9 > Date: 2020-06-22 > > Abstract: > Constrained Devices as they are used in the "Internet

[Ace] Constrained Node/Network Cluster @ IETF108: DRAFT AGENDA

Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF108. Remember that there is still quite some potential for changes. Conflicts that meet the eye: LAKE/SUIT (!). ACE/RATS. (I think 6LO/COSE can be ignored.) HACKATHON is on top of CORE, but I don't know what that

[Ace] AIF-09 (Re: AIF as discussed today (Re: I-D Action: draft-bormann-core-ace-aif-08.txt))

Instead of working on the (great) comments in the reviews, I went ahead and added permissions for dynamic resources. Enjoy: Html: https://www.ietf.org/id/draft-bormann-core-ace-aif-09.html Htmlized: https://tools.ietf.org/html/draft-bormann-core-ace-aif-09 Diff:

[Ace] IANA considerations for authz-info RT

Marco and I still have to do the bike shedding on the actual name (“ace.ai” below), but we can look at my proposed text already anyway: 8. IANA Considerations 8.NN. CoRE Resource Type registry IANA is requested to register a new Resource Type (rt=) Link Target Attribute in the "Resource

Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif

On 2020-07-15, at 22:51, Jim Schaad wrote: > > I had been holding off doing an adoption call waiting for a formal request > to adopt it. Sorry about that — I was still thinking we should finish the discussion about the new dynamic permissions. But I realize now that these have been around

Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif

On 2020-07-18, at 00:21, Benjamin Kaduk wrote: > > Refreshing my memory of the WG charter, it seems like this can be in scope, > but we should be sure to consider what analogues already exist in > non-constrained systems, and whether we are in fact creating something > generally new and broadly

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

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

  1   2   >