[Ace] draft-moskowitz-ecdsa-pki-10

Hi Henk, Frank, Michael, Bob, thanks for this document. I have a question regarding the IEEE 802.1AR-based of the description. Here is what I understand for use of certificates from 802.1AR (with my wording because RFC 2119 language is often missing in the 1AR spec): * The DevID certificate su

[Ace] Hackathon#112 Participation

Hi all, I just checked the IETF hackathon wiki and noticed a low participation from IoT groups. At the IETF#11 hackathon several folks worked together (see summary presentation at https://github.com/IETF-Hackathon/ietf111-project-presentations/blob/main/hackathon-lwm2m.pdf) and we made some p

[Ace] Correction

Hi all, I noticed room for a correction in Appendix E, which currently says: o Access token retention -- in OAuth 2.0, the access token is sent with each request to the RS. In this framework, the RS must be able to store these tokens for later use. See Section 5.10.1

Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

To: Cigdem Sengul ; Francesca Palombini ; Hannes Tschofenig Cc: Seitz Ludwig ; The IESG ; ace-cha...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org; ace@ietf.org; sec-...@ietf.org Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and

Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

Hi all, what is the motivation for re-opening the discussion about this aspect? This was discussed in the working group before and we reached a conclusion about what we want to support. The use of HTTP/JSON is extremely useful. Ciao Hannes -Original Message- From: Cigdem Sengul Sent:

Re: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

: 'Seitz Ludwig' ; 'Mike Jones' ; 'Chuck Mortimore' ; Hannes Tschofenig Cc: chuck.mortim...@visa.com; cwt-reg-rev...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org; drafts-expert-rev...@iana.org; ace@ietf.org Subject: RE: [Ace] [Cwt-reg-review] [IANA #1158953] Requested re

Re: [Ace] Using OAuth and ACE-OAuth with MQTT

Ludwig, you are right. I missed that. I was incorrectly looking at draft-ietf-ace-oauth-params-12 where all the parameters are. I will delete my PR. Ciao Hannes -Original Message- From: Seitz Ludwig Sent: Tuesday, March 17, 2020 12:41 PM To: Hannes Tschofenig ; Jim Schaad Cc: 'C

Re: [Ace] Using OAuth and ACE-OAuth with MQTT

I used "Bearer". Ciao Hannes -Original Message- From: Hannes Tschofenig Sent: Wednesday, March 11, 2020 8:34 AM To: Jim Schaad Cc: 'Cigdem Sengul' ; 'Ace Wg' Subject: RE: Using OAuth and ACE-OAuth with MQTT Hi Jim, I believe you are right that the function

Re: [Ace] Using OAuth and ACE-OAuth with MQTT

not sure whether the authentication mechanisms defined in draft-ietf-ace-mqtt-tls-profile are actually sound. Maybe I should do a formal analysis. -Original Message- From: Jim Schaad Sent: Wednesday, March 11, 2020 12:10 AM To: Hannes Tschofenig Cc: 'Cigdem Sengul' ; 'Ace Wg&#

Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03

Hi Cigdem, Following the OAuth virtual interim meeting call today I wonder whether it makes sense to describe how the key transport with the PoP token using the communication between the client and the authorization server over the HTTP interface works. Ciao Hannes From: Hannes Tschofenig

Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03

* I plan to join. I have been aware of the issue, but could not follow how it was planned to be resolved. * I was looking at this: draft-ietf-oauth-pop-key-distribution Yes, that’s what the group wanted to do. Now, new ideas showed up on the radar that are incompatible with that approac

Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03

e OAuth group should probably be of interest to you. Ciao Hannes From: Cigdem Sengul Sent: Tuesday, February 25, 2020 3:10 PM To: Hannes Tschofenig Cc: ace@ietf.org Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03 Hello Hannes, We used broker as it is a widely accepted term in th

[Ace] FW: Virtual Interim Meeting for the PoP Discussion

focuses on the HTTP-based transport. From: OAuth On Behalf Of Hannes Tschofenig Sent: Wednesday, February 26, 2020 6:22 PM To: oauth Subject: [OAUTH-WG] Virtual Interim Meeting for the PoP Discussion Hi all, Here are the details for the virtual interim meeting to discuss the proof-of

[Ace] draft-ietf-ace-mqtt-tls-profile-03

Hi Cigdem, Hi Anthony, Hi Paul, Why are you using the term MQTT broker? My understanding of the MQTT spec is that there are only clients and servers - nothing more. Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT v3.1.1 client talk to a MQTT v5 client via a server that su

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

I believe the current approach is for the server to provide the symmetric key (rather than the client). I have no idea when this topic gets resolved because folks keep changing their mind so quickly. From: Cigdem Sengul Sent: Donnerstag, 3. Oktober 2019 12:37 To: Hannes Tschofenig Cc

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

There is unfortunately a problem. With proof-of-possession keys there is more than just conveying the CWT/JWT over another transport. In the PK-case, the client has to provide the public key to the server and get it bound to the PoP token. In the symmetric key case, the server has to provide the

Re: [Ace] EST over CoAP: Randomness

Hi Mike, A few remarks inline. On 5/14/2019 7:29 PM, Hannes Tschofenig wrote: > Hi Paul, > > My understanding from reading the draft text was that the "cost" was actually > talking about "energy cost" rather than "monetary cost". > The monetary cost

Re: [Ace] EST over CoAP: Randomness

) cost and price of an MCU are different aspects. Ciao Hannes -Original Message- From: Paul Duffy Sent: Dienstag, 14. Mai 2019 15:08 To: Hannes Tschofenig ; ace@ietf.org Subject: Re: [Ace] EST over CoAP: Randomness On 5/9/2019 10:42 AM, Hannes Tschofenig wrote: > I believe we should encoura

Re: [Ace] EST over CoAP: Randomness

Esko, your line of thought makes sense to me. I leave it to Panos to enhance the text. Ciao Hannes From: Esko Dijk Sent: Dienstag, 14. Mai 2019 11:57 To: Hannes Tschofenig ; Panos Kampanakis (pkampana) ; ace@ietf.org Subject: RE: [Ace] EST over CoAP: Randomness Hi Hannes, Agree. The draft

Re: [Ace] EST over CoAP: Randomness

Hi Esko, good to hear from you. * Another reason for server-side keygen can be that an IT department/manager wants it that way. There could be a policy that the keypairs for all domain certificates must be created by the systems under direct control of the IT department. (E.g. to comply w

Re: [Ace] EST over CoAP: Randomness

Your text updates look good to me, Panos. Thanks. Hannes From: Panos Kampanakis (pkampana) Sent: Freitag, 10. Mai 2019 13:06 To: Hannes Tschofenig ; ace@ietf.org Subject: RE: [Ace] EST over CoAP: Randomness Hi Hannes, > Hence, I believe it would be better to first shorten the follow

Re: [Ace] EST over CoAP: Randomness

he IoT space that there is no point in dealing with RSA these days. -Original Message- From: Panos Kampanakis (pkampana) Sent: Freitag, 10. Mai 2019 04:53 To: Hannes Tschofenig ; ace@ietf.org Subject: RE: [Ace] EST over CoAP: Randomness Thanks Hannes. Before I try to address it, can

[Ace] EST over CoAP: Randomness

Hi all, I am still a bit unhappy about this paragraph: " Constrained devices sometimes do not have the necessary hardware to generate statistically random numbers for private keys and DTLS ephemeral keys. Past experience has also shown that low-resource endpoints sometimes generate n

[Ace] FW: Joint IETF/IRTF - OMA SpecWorks Meeting

FYI: I am forwarding the meeting announcement also to ACE and CORE because there maybe interested parties in these groups as well. Everyone is welcome to join! From: T2TRG On Behalf Of Hannes Tschofenig Sent: Dienstag, 7. Mai 2019 14:39 To: t2...@irtf.org Cc: Ari Keränen Subject: [T2TRG] Joint

Re: [Ace] EDHOC standardization

ant. Ciao Hannes -Original Message- From: John Mattsson Sent: Freitag, 22. Februar 2019 10:08 To: Hannes Tschofenig ; ace@ietf.org; l...@ietf.org; secdispa...@ietf.org Cc: Benjamin Kaduk ; salvador@um.es Subject: Re: [Ace] EDHOC standardization Hi Hannes, No wonder that ECDHE-

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

will make your life easier (and the code faster). Ciao Hannes -Original Message- From: Göran Selander Sent: Montag, 4. Februar 2019 18:41 To: Hannes Tschofenig ; secdispa...@ietf.org; ace@ietf.org Subject: Re: [Secdispatch] FW: [secdir] EDHOC and Transports Hi Hannes, secdispatch, an

Re: [Ace] Resource, Audience, and req_aud

Hi Jim, Hi Ludwig, > Do the chairs think that this would unduly delay the progress of > draft-ietf- ace-oauth-params? [Hannes] Do you think it was inappropriate to point out this inconsistency? > It looks like the are about the same point as we are. So no I don't think it > would slow things d

Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

may feel quite unnatural. It must have felt unnatural already to the group when working on the token exchange spec… Ciao Hannes From: George Fletcher Sent: Donnerstag, 7. Februar 2019 17:06 To: Hannes Tschofenig ; Ludwig Seitz ; ace@ietf.org; oa...@ietf.org Subject: Re: [Ace] [OAUTH-WG

Re: [Ace] Resource, Audience, and req_aud

Hi Ludwig, > What I understood from the feed-back is that using a parameter called "aud" > in a request to the token endpoint would be interpreted as a restriction on > the audience of authorization servers that are addressed by this request. I am not talking about a parameter called 'aud'. Tak

Re: [Ace] [OAUTH-WG] Resource, Audience, and req_aud

token exchange spec)”? From: Filip Skokan Sent: Donnerstag, 7. Februar 2019 16:38 To: Hannes Tschofenig Cc: ace@ietf.org; oa...@ietf.org Subject: Re: [OAUTH-WG] Resource, Audience, and req_aud To add to that, 3. If a device uses HTTP Token Exchange it can use both resource and audience

Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

protocol the information is exchanged. Which route is better? I don't care. Ciao Hannes -Original Message- From: Ludwig Seitz Sent: Donnerstag, 7. Februar 2019 16:29 To: Hannes Tschofenig ; ace@ietf.org; oa...@ietf.org Subject: Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-

[Ace] Resource, Audience, and req_aud

Hi all, after re-reading token exchange, the resource indicator, and the ace-oauth-params drafts I am wondering whether it is really necessary to have different functionality in ACE vs. in OAuth for basic parameters. Imagine I use an Authorization Server and I support devices that use CoAP and

Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

Hi George, * I believe that since the latest draft of the resource indicators spec [1] allows for abstract identifiers, and since a URN is also a URI, you could easily use a URN syntax to accomplish the use case outlined in your email. After re-reading the token exchange draft I realized t

Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

Hi Ludwig, > My interpretation of this is that "resource" refers to a single resource No. Here is the text from token exchange (see last sentence): resource OPTIONAL. Indicates the location of the target service or resource where the client intends to use the requested security

[Ace] FW: [OAUTH-WG] OAuth Security Workshop Call for Proposals

This workshop may be of interest to you, particularly if you work on ACE-Oauth specification. From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf Of Torsten Lodderstedt Sent: Freitag, 11. Januar 2019 21:32 To: oa...@ietf.org Subject: [OAUTH-WG] OAuth Security Workshop Ca

Re: [Ace] ACE Implementation for Disadvantaged Environments

mechanism? Ciao Hannes From: Sebastian Echeverria Sent: Montag, 28. Januar 2019 16:06 To: Hannes Tschofenig Cc: Grace A Lewis ; ace@ietf.org; Dan Klinedinst Subject: Re: ACE Implementation for Disadvantaged Environments Hello, Here is some more information about it: * We used Contiki as the

Re: [Ace] ACE Implementation for Disadvantaged Environments

Congrats to the work. Could you say a little bit the (constrained) resource server implementation? Ciao Hannes From: Ace On Behalf Of Grace A Lewis Sent: Mittwoch, 23. Januar 2019 19:12 To: ace@ietf.org Subject: [Ace] ACE Implementation for Disadvantaged Environments Hello, I just wanted to m

Re: [Ace] Security of the Communication Between C and RS

Hi Ludwig, Hi Jim A few remarks below: -Original Message- From: Ludwig Seitz Sent: Donnerstag, 20. Dezember 2018 08:40 To: Jim Schaad ; Hannes Tschofenig ; 'Stefanie Gerdes' ; ace@ietf.org Subject: Re: [Ace] Security of the Communication Between C and RS On 19/12/2018

Re: [Ace] Security of the Communication Between C and RS

Thanks, Ludwig. The list of steps below help me to understand the concern. 1.) C obtains token and pop-key from AS 2.) C transmits token to RS and sets up secure communication (e.g. DTLS-PSK) using the pop-key 3.) C sends secure requests to the RS 4.) token expires, an attacker manages to g

Re: [Ace] Security of the Communication Between C and RS

presents a token? Ciao Hannes -Original Message- From: Stefanie Gerdes Sent: Mittwoch, 19. Dezember 2018 12:26 To: Hannes Tschofenig ; Ludwig Seitz ; Jim Schaad ; ace@ietf.org Subject: Re: [Ace] Security of the Communication Between C and RS Hi Hannes, On 12/18/2018 04:26 PM, Hannes

Re: [Ace] Security of the Communication Between C and RS

Hi Steffi, >> I also think that the client must be able to assume that RS' RPK that C >> receives from AS is also valid as long as the token, unless C has additional >> information. > > I would think that it is rather unlikely that the RS will change its > public/private key pair so quickly. Ri

Re: [Ace] Security of the Communication Between C and RS

Hi Steffi, > In OAuth, the expires_in field is usually used to inform the client how long > the access token is valid. If the client uses the access token in a request > after the token expired, the RS will reject the request, which usually is not > a big problem for the client. > In ACE, AS p

Re: [Ace] Security of the Communication Between C and RS

Hi Steffi, Hi Ludwig, ~snip~ >> The access information optionally can contain an expires_in field. >> It would help to prevent security breaches under the following >> conditions: > 1. the keying material is valid as long as the ticket, 2. the > expires_in field is present in the access informati

Re: [Ace] Security of the Communication Between C and RS

Hi Ludwig, A few remarks inline: -Original Message- From: Ludwig Seitz Sent: Dienstag, 18. Dezember 2018 09:27 To: Hannes Tschofenig ; Stefanie Gerdes ; Jim Schaad ; ace@ietf.org Subject: Re: [Ace] Security of the Communication Between C and RS On 15/12/2018 16:04, Hannes Tschofenig

Re: [Ace] Security of the Communication Between C and RS (was: Re: Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt)

Hi Steffi, ~snip~ > I really think you should point out that symmetric keying material that the > AS provides to the client is valid as long as the token. I think that's a useful recommendation. I do, however, believe that we are not making the same assumption for an asymmetric key bound to th

Re: [Ace] Token (In)Security

- From: Ace On Behalf Of Hannes Tschofenig Sent: Freitag, 14. Dezember 2018 17:18 To: Stefanie Gerdes ; Ludwig Seitz ; Jim Schaad ; ace@ietf.org Subject: Re: [Ace] Token (In)Security Hi Steffi, I anticipate that the use of tokens with IoT devices works similar to OAuth deployments today. As such

Re: [Ace] Token (In)Security

Hi Steffi, I anticipate that the use of tokens with IoT devices works similar to OAuth deployments today. As such, if you distribute self-contained tokens then you sign or mac them. We have registered the necessary claims already, which includes the expiry. As such, I expect it to be used as we

Re: [Ace] est-coaps clarification on /att and /crts

Hi Panos, Hi Michael, > We want all our clients to be authenticated by DTLS before they start loading > up our RF network. > I'm not suggesting that the DTLS be skipped, I'm suggesting that the client > certificate presented might be meaningless to the EST server. I am curious what security mod

Re: [Ace] IPR Conformance check for draft-ietf-ace-cwt-proof-of-possession

I am not aware of any IPRs regarding draft-ietf-ace-cwt-proof-of-possession From: Ace On Behalf Of Samuel Erdtman Sent: Thursday, November 29, 2018 6:49 AM To: Roman Danyliw Cc: ace Subject: Re: [Ace] IPR Conformance check for draft-ietf-ace-cwt-proof-of-possession As a co-author, I don't hol

Re: [Ace] EDHOC standardization

John, could you also add the detailed data for EDHOC as well? (And thanks for the details regarding the DTLS numbers.) Ciao Hannes -Original Message- From: Ace On Behalf Of John Mattsson Sent: Wednesday, November 21, 2018 4:03 PM To: ace@ietf.org; l...@ietf.org Cc: Benjamin Kaduk ; salva

Re: [Ace] EDHOC standardization

Hi John, From our experience neither PSK+ECDHE nor RPK usage is common in IoT deployments among the bigger IoT providers. Today, most companies use certificate-based authentication in almost all cases. In some cases plain PSK is used for those cases where devices are particularly constraint. C

Re: [Ace] Minimizing overhead of certificates in constrained IoT

Hi John, I see CWT as a combination of Kerberos ticket (for the use of symmetric key) and a certificate format (for the asymmetric key usage) encoded in CBOR. The claims in the CWT are essentially the attributes you carry in a certificate. Ciao Hannes -Original Message- From: Ace On Be

[Ace] FW: draft-ietf-oauth-pop-key-distribution-04

I submitted an update of the PoP key distribution document to get it in sync with what is happening with the ACE OAuth framework. Ciao Hannes From: Hannes Tschofenig Sent: Tuesday, October 23, 2018 2:19 PM To: oauth Subject: draft-ietf-oauth-pop-key-distribution-04 Hi all, I refreshed the

[Ace] Review of draft-ietf-ace-oauth-params-00

Hi all, I read through draft-ietf-ace-oauth-params-00 and have a few comments. 1) I believe the document should explain in more detail about how it fits into the rest of the OAuth PoP token work. The story essentially is that we have the HTTP-based transport in the OAuth WG and we have the CoAP

[Ace] Progressing the HTTP parameter encoding for OAuth PoP Key Distribution

Hi all, after several discussions we believe that we now have a proposal for moving forward on this topic. We plan to update the expired draft and (1) remove the audience parameter and replace it with a separately-specified resource parameter, (2) remove the alg parameter, (3) update the proce

[Ace] ACE - OAuth Synchronization

Hi Ben, Hi Ekr, We tried to find an agreement of which group defines parameters needed for ACE to support the PoP token functionality. Unfortunately, we didn't manage to find an agreement in which group the work should be done. The ACE working group wants to start a working group last call on

[Ace] FW: EAT Bar BOF Meeting Room -- Square Dorchester

-mandyam-eat-00. The meeting will take place later today, as described below, in the Square Dorchester room. Ciao Hannes From: Hannes Tschofenig Sent: 14 July 2018 17:09 To: e...@ietf.org Subject: EAT Bar BOF Meeting Room -- Square Dorchester Hi all, the meeting room for our Bar BOF, which

[Ace] RNG functionality

Hi all, As mentioned at the ACE meeting today in the context of "can IoT devices generate random number" I promised to send a pointer to a recent webinar about the use of hardware-based RNG functionality. The webinar recording can be found at http://www2.keil.com/mbed/mbedtls (look for part 3).

[Ace] FW: PoP Key Distribution

Note that I posted a mail to the OAuth list about the PoP key distribution, which also relates to the work on ACE-OAuth. If you are interested in this topic please feel free to join the discussion on the OAuth mailing list. From: Hannes Tschofenig Sent: 03 July 2018 21:46 To: oa...@ietf.org

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

obtain the identified key using the Key ID. “ From: Samuel Erdtman [mailto:erdt...@spotify.com] Sent: 27 June 2018 08:18 To: Jim Schaad Cc: Hannes Tschofenig; Benjamin Kaduk; Mike Jones; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org Subject: Re: [Ace] Key IDs ... RE: WGLC on draft

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

: Hannes Tschofenig; 'Benjamin Kaduk'; 'Mike Jones' Cc: draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org Subject: RE: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 Hannes, My worry is not about implementers getting this correct and picking rando

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

: Benjamin Kaduk [mailto:ka...@mit.edu] Sent: 26 June 2018 17:14 To: Hannes Tschofenig Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 I thought we were worried about

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

e for me nevertheless. Ciao Hannes -Original Message- From: Jim Schaad [mailto:i...@augustcellars.com] Sent: 24 June 2018 10:15 To: 'Benjamin Kaduk'; 'Mike Jones' Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org Subject: RE: [Ace

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

June 2018 17:00 To: Hannes Tschofenig Cc: Mike Jones; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02 On Tue, Jun 26, 2018 at 08:53:57AM +0000, Hannes Tschofenig wrote: > Ben, &

Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

discussion. Are we aware of key collision in Kerberos? Ciao Hannes -Original Message- From: Benjamin Kaduk [mailto:ka...@mit.edu] Sent: 23 June 2018 23:30 To: Mike Jones Cc: Hannes Tschofenig; Jim Schaad; draft-ietf-ace-cwt-proof-of-possess...@ietf.org; ace@ietf.org Subject: Re: [Ace] Key IDs

[Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02

Hi Jim, I would like to comment on this issue. - > > 14. I have real problems w/ the use of a KID for POP identification. It may > identify the wrong key or, if used for granting access, may have problems w/ > identity collisions. These need to be spelt out someplace to help people > track

[Ace] "sub" and "iss" ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02

Hi Roman, this is also a good question: > (3) (Editorial) Page 4, Section 3.0, I read to the end of this section by > which point there has been discussion of "sub" or "iss". I was left > wondering about how to interpret the case where both are present and none are. Here is the text from the

[Ace] Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02

Hi Roman, Thanks for your review. As I was re-reading the reviews I spotted this comment: > (14) (Editorial) Page 8, Section 4, Per "Replay can also be avoided if a > sub-key is derived from a shared secret that is specific to the instance of > the PoP demonstration." PoP is spelled out eve

[Ace] Standardizing Attestation Tokens

Hi all, I would like to make you aware of work that will be discussed on attestation on the EAT mailing list. Here is the link to the list: https://www.ietf.org/mailman/listinfo/eat Here is a document describing the idea: https://tools.ietf.org/html/draft-mandyam-eat-00 The work is relevant for

[Ace] CWT-PoP & Multiple PoP keys

Hi Jim, I had a chat with Mike about relaxing the CWT-PoP spec to allow multiple PoP keys in a single CWT token. He is concerned about the departure from RFC 7800 and, after giving it a bit more thoughts, I believe there is an issue. Initially, when we started the work our promise was that thi

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

Peter, Did this registration attempt got concluded? Ciao Hannes -Original Message- From: peter van der Stok [mailto:stokc...@xs4all.nl] 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

Re: [Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02

Hi Jim, I have made changes to the draft based on your review and the updated version of the document can be found at https://github.com/cwt-cnf/i-d/pull/13 However, I am not sure we have consensus on the changes. Ciao Hannes -Original Message- From: Jim Schaad [mailto:i...@augustcellar

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

implementations of crypto algorithms for IoT devices. Ciao Hannes From: Eric Rescorla [mailto:e...@rtfm.com] Sent: 07 June 2018 22:21 To: Michael Richardson Cc: Hannes Tschofenig; ace@ietf.org Subject: Re: [Ace] How to specify DTLS MTI in COAP-EST TBH, I'm not a fan of SHOULD+, etc., and th

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

In products crypto does not change that fast given the lifetime of IoT devices and the hardware support for it. Our customers are asking for NIST certified crypto. Ciao Hannes -Original Message- From: Carsten Bormann [mailto:c...@tzi.org] Sent: 07 June 2018 18:40 To: Hannes Tschofenig

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

Hi Russ, Hi Michael, why don't you just reference https://tools.ietf.org/html/rfc7925? I am not a big fan of making all sorts of different crypto recommendations in our specs that differ slightly. Ciao Hannes PS: Next time someone suggests the use of a new crypto algorithm I will demand that

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

: 16 May 2018 12:30 To: Hannes Tschofenig Cc: ace@ietf.org; core Subject: Re: [Ace] Early media-type registration for EST over CoAP Forgot to add another example: the content-format numbers for COSE have parameters. Sent from mobile On 16. May 2018, at 12:26, Carsten Bormann mailto:c...@tzi.org

Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

Hi Jim, A few remarks below. -Original Message- From: Jim Schaad [mailto:i...@augustcellars.com] Sent: 09 May 2018 05:51 To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org Cc: ace@ietf.org Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 I'll pull out the list of com

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

I don't have a strong opinion about option #2 appears to be slightly better. I guess hard-cording URLs will not work -Original Message- From: Michael Richardson [mailto:mcr+i...@sandelman.ca] Sent: 16 May 2018 14:16 To: Hannes Tschofenig Cc: ace@ietf.org Subject: Re: [Ace]

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

> Hannes: do you have any opinion about the necessity of going through > /.well-known/core to get the short URL, vs just using a /.well-known/est URL? (RTT for the lookup vs extra bytes in the URL) Are you asking me about these two options: Option #1 - going through /.well-known/core REQ:

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

Hi Carsten, 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 To: Hannes Tschofenig Cc: ace@ietf.org; core S

Re: [Ace] EST over CoAP

Ø But I don't think we can tell endpoints that they are on their own unless they get the right hardware or they comply with the ACE-OAuth model, or DOXS. [This is probably an issue unrelated to EST topic but worthwhile to talk about nevertheless.] How do you expect companies to come up with re

Re: [Ace] EST over CoAP

transaction does not incur significant workload to the endpoint itself. Rgs, Panos From: Mohit Sethi [mailto:mohit.m.se...@ericsson.com] Sent: Tuesday, May 15, 2018 1:37 AM To: Panos Kampanakis (pkampana) mailto:pkamp...@cisco.com>>; Hannes Tschofenig mailto:hannes.tschofe...@arm.com>>;

[Ace] EST over CoAP: Introduction

Here is a proposal to change the introduction to the relevant parts only and to avoid repetition. (The current document still keeps talking about IEEE 802.15.4 when there are so many other radio technologies as well. There is nothing in this spec that makes this 15.4 specific. I understand that

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

I get the impression that the EST over CoAP spec will not completed as soon as I had hoped. 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 Ciao Hannes IMPORTANT NOTICE: The contents o

Re: [Ace] EST over CoAP

ice by not explaining what the minimum capable security services were for each of the classes. Mike On 5/14/2018 2:49 PM, Hannes Tschofenig wrote: > Here is my personal take on this: you have to do your threat assessment to > find out what attacks you care about. This will determine you

Re: [Ace] EST over CoAP

since you don't have to expose the private key. If your design suddenly still requires this then you are losing some of the good properties of public key crypto systems. Ciao Hannes From: Panos Kampanakis (pkampana) [mailto:pkamp...@cisco.com] Sent: 14 May 2018 21:24 To: Hannes Tschofenig

Re: [Ace] EST over CoAP

over CoAP Hannes Tschofenig wrote: > Regarding the randomness requirement and the energy consumption. We > have been a bit advocate for adding hardware-based random numbers to > devices since randomness is a basic requirement for most security > protocols. I think

Re: [Ace] EST over CoAP

Hi Michael, -Original Message- From: Michael Richardson [mailto:mcr+i...@sandelman.ca] Sent: 14 May 2018 16:46 To: Hannes Tschofenig Cc: ace@ietf.org Subject: Re: [Ace] EST over CoAP Hannes Tschofenig wrote: > Thanks for the feedback. > Why do you think it takes so l

Re: [Ace] EST over CoAP

(pkampana) [mailto:pkamp...@cisco.com] Sent: 14 May 2018 15:58 To: Hannes Tschofenig; ace@ietf.org Subject: RE: EST over CoAP Hi Hannes, To address your question about server-side key gen, below is the explanation we have put in the draft already and will be in the next iteration

Re: [Ace] EST over CoAP

accomplished but the question for me is whether this functionality should go into this version of the spec or rather a companion document. -Original Message- From: Michael Richardson [mailto:mcr+i...@sandelman.ca] Sent: 14 May 2018 12:39 To: Hannes Tschofenig Cc: ace@ietf.org Subject: Re: [Ace] EST

[Ace] EST over CoAP

Hi all, At IETF#101 Peter presented a list of open issues with the EST over CoAP draft, see https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00 - Operational parameter values - Server side key generation using simple multipart encoding -

[Ace] Security and privacy for small memory microprocessor based IoT devices are still being invented

Here is the article mentioned during the ACE meeting today: https://www.networkworld.com/article/3223952/internet-of-things/5-reasons-why-device-makers-cannot-secure-the-iot-platform.html As you can see that there are some misconceptions about our IETF work. It is easy to conclude that "Security

Re: [Ace] Coordinated effort to produce updated profiles for the use of crypto algorithms in IoT

Here is a relevant document: https://tools.ietf.org/html/draft-tschofenig-uta-tls13-profile-00 From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of John Mattsson Sent: 19 March 2018 11:11 To: ace@ietf.org Subject: [Ace] Coordinated effort to produce updated profiles for the use of crypto algori

[Ace] ACE-OAuth implementation

As mentioned at the working group meeting today we, Arm, released a product feature with the name "Secure Device Access" for our Mbed Cloud product. It implements functionality of the ACE-OAuth framework. I talked about it during the OAuth security workshop last week, see http://st.fbk.eu/sites

[Ace] Client Token Analysis

Hi all, as mentioned during the ACE working group meeting today the paper with the analysis of the Client Token functionality can be found at the paper published for the OAuth Security Workshop. Here is the link to the paper http://st.fbk.eu/sites/st.fbk.eu/files/osw2018-ace.pdf There are also

[Ace] FW: [Atlas] ATLS side meeting

FYI: Here is the info for the lunch meeting today to discuss application layer TLS. Feel free to join us. From: Atlas [mailto:atlas-boun...@ietf.org] On Behalf Of Richard Barnes Sent: 14 March 2018 16:04 To: at...@ietf.org Subject: [Atlas] ATLS side meeting Hey all, FYI, we have a room booked f

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

;t this sometimes called "network access authentication"? In any case, I agree with you that we should add some text about what information is assumed to be present. Ciao Hannes -Original Message- From: Carsten Bormann [mailto:c...@tzi.org] Sent: 20 February 2018 19:05 To: Hanne

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

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. -Original Message- From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Michael Richardson Sent: 19 February

Re: [Ace] Working group adoption of draft-vanderstok-ace-est

I support the adoption of this document. My concerns with earlier versions of the document have been addressed with the recent draft updates. I have read the latest version of the draft and I believe it is even ready for a working group last call once adopted. Ciao Hannes PS: Sorry for my late

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

] Sent: 18 February 2018 18:15 To: Hannes Tschofenig Cc: ace Subject: Re: [Ace] draft-ietf-ace-oauth-authz-10.txt: Leaving implementers in the dark On Feb 18, 2018, at 08:52, Hannes Tschofenig wrote: > > Hi Carsten, > > The challenge is that there is not a single way used in deployme

  1   2   >