[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

[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

[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

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 COMME

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

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

To: '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 review for IANA registration

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: 'Cigdem

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

ed "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 functionality is supported. In re

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

am 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' Subject: Using

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

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

th 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 the

[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

[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

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] 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

d (d) 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

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

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

T 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 y

[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

[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

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-PSK

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, and ace

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

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'.

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

the 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

on the 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-oauth

[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

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

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

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

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 21:22, Jim

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

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

and 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.

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

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

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

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

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

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

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

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.

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

[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

[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

[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] 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

to 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

To: 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 random key ids. My worry

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

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] Key IDs ... RE: WGLC

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

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 +, Hannes Tschofenig wrote: > Ben, &g

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 >

[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

[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

[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

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

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

on 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 they're

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 <c...@tzi.

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

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] Early

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

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) <pkamp...@cisco.com<mailto:pkamp...@cisco.com>>; Hannes Tschofenig <hannes.tsc

[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

Re: [Ace] EST over CoAP

curity 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 your hardware > requirements (not the other

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 <hannes.tschofe...@arm.com> wrote: > Thanks for the feedback. >

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

this 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

[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

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

is 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: Hannes Tsc

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] Removal of the Client Token from ACE-OAuth draft

8 12:36 To: Hannes Tschofenig; ace@ietf.org Subject: Re: [Ace] Removal of the Client Token from ACE-OAuth draft Hi Hannes, The paper you are referring to was the only new data point you included when you started this thread. I’m not questioning the correctness of your analysis, just saying tha

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

confidence in the work. Ciao Hannes From: Göran Selander [mailto:goran.selan...@ericsson.com] Sent: 08 February 2018 09:22 To: Hannes Tschofenig; ace@ietf.org Subject: Re: [Ace] Removal of the Client Token from ACE-OAuth draft Hi Hannes, From: Ace <ace-boun...@ietf.org<mailto:ace-boun...@ie

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

Hi Carsten, > > I will remove that feature from the draft in the next update. > Right. But please put it into a separate draft, so we can — develop it > further and make it ready for use, and — ensure that the base framework is > prepared for additional flows like this. Good idea and maybe

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

Hi all, the Client Token is a new mechanism in the ACE-OAuth that aims to solve a scenario where the Client does not have connectivity to the Authorization Server to obtain an access token while the Resource Server does. The solution is therefore for the Client to use the Resource Server to

[Ace] Deadline Extended - Call for Position Papers and Tutorials - Third OAuth Security Workshop (OSW 2018)

We have extended the submission deadline to January 26 for our 3rd OAuth Security workshop, which will take place in March the week before the IETF meeting. More info about the workshop can be found here: https://st.fbk.eu/osw2018 Please consider contributing your experience with OAuth-related

[Ace] Application Transport LAyer Security (ATLAS)

Hi all, Based on the discussion late last year on this mailing list we have created a mailing list for discussions relating to the re-use of TLS handshaking protocols at the application layer for establishing keying material to protect application data. Here is the link to the list:

[Ace] Credential Management for Internet of Things Devices

Hi all, Here is the publication of the IPSO Alliance whitepaper about "Credential Management for Internet of Things Devices": https://www.ipso-alliance.org/blog-credential-management-for-internet-of-things-devices/ It may be of interest to you since it compares ACE-OAuth with LwM2M and OCF.

[Ace] 3rd OAuth Security Workshop (OSW 2018)

irs - Roberto Carbone (Security & Trust, Fondazione Bruno Kessler) - Hannes Tschofenig (IETF OAuth Working Group Co-Chair) Members - Michael Jones (Microsoft) - Ralf Kuesters (University of Stuttgart) - Torsten Lodderstedt (YES Europe AG) - Chris Mitchell (Royal Holloway, University of

Re: [Ace] Independent I-D for new TLS authentication (triple-ECDH)

Hi Tony, If I understand your idea correctly then you have just re-invented the raw public key concept defined in https://tools.ietf.org/html/rfc7250 Ciao Hannes From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Tony Putman Sent: 06 December 2017 14:42 To: ace@ietf.org Subject: [Ace]

Re: [Ace] Application Layer TLS

To me it sounds like we have multiple groups who have seen a problem and have been willing to spend the time to work on the solutions. I believe we should put a BOF proposal for the London IETF meeting together. How does that sound? Ciao Hannes -Original Message- From: Ace

Re: [Ace] Application Layer TLS

-Original Message- From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Ludwig Seitz Sent: 21 November 2017 11:07 To: ace@ietf.org Subject: Re: [Ace] Application Layer TLS On 2017-11-21 10:42, Hannes Tschofenig wrote: > Hi all, > > based on the recent email discussion about the DTL

[Ace] Application Layer TLS

Hi all, based on the recent email discussion about the DTLS proxy I thought it might be useful that there was some thinking about how to run TLS/DTLS at the application layer. There are essentially two drafts that have been submitted at the same time for IETF#100, namely

Re: [Ace] Early warning: Rewrite of vanderstok-ace-coap-est

, very much in spirit of the original spec EST spec Ciao Hannes From: Panos Kampanakis (pkampana) [mailto:pkamp...@cisco.com] Sent: 13 November 2017 12:14 To: Hannes Tschofenig; ace@ietf.org Subject: RE: Early warning: Rewrite of vanderstok-ace-coap-est Hi Hannes, I think the current draft offers

  1   2   >