* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ace Status Pages

Authentication and Authorization for Constrained Environments (Active WG)
Sec Area: Eric Rescorla, Benjamin Kaduk | 2014-Jun-16 —  

IETF-103 ace minutes

Session 2018-11-08 1610-1810: Chitlada 1 - Audio stream - ace chatroom


minutes-103-ace-01 minutes

          ACE WG Minutes
          IETF 103
          Thursday, November 8, 2018
          16:10-18:10, Afternoon session II
          Minutes taker: Ivaylo Petrov
          Introduction and Status Update
          presenters: Jim Schaad and Roman Danyliw
          The chairs presented the status of the WG -- recent WGLCs
          (draft-ietf-ace-oscore-profile, draft-ietf-ace-authz,
          draft-ietf-dtl-authorize and draft-ietf-ace-oauth-params); and drafts
          in shepherd review (draft-ietf-ace-cwt-proof-of-possession).
          presenter: Ludwig Seitz
          draft: draft-ietf-ace-oauth-authz
          Ludwig Seitz presented changes made to the framework draft from the -13
          to -17 revisions and led a discussion on open issues.
          Per Slide #3, Discussion Point #1: Use of low-digit abbreviation
          -- no feedback from the WG
          Per Slide #3, Discussion Point #2: Unified registry of CBOR abbreviations
          Comment: Mike Jones (Microsoft): I believe that has been discussed in
          the list and there should be separate numeric spaces for claims and
          Comment: Jim Schaad: The RATS BoF also discussed registering CWT claims.
          We would benefit from a common story.  Likely we should register maps
          then everyone could get their own registry.
          Q: Carsten Bormann: How many media types you have?
          -A: Ludwig Seitz: There is one media type defined.
          -A: Carsten Bormann: How do I know its CWT then?
          -A: Ludwig Seitz: It is sent as a parameter in the message.
          -A: Carsten Bormann: The important thing is that the thing claim received
          should be formed as a CWT
          Per Slide #3, Discussion Point #3: CWT as format for signed protocol
          Comment: Ben Kaduk: Thinking about as CWT as signed claim messages,
          the ACME just started using JWTs for all signed messages.
          Comment: Mike Jones: As discussed on the list, use of JWTs as signed
          protocol messages is being standardized by OpenID Connect and the OAuth
          WG.  Given that ACE is trying to reused as much of OAuth as possible,
          it makes sense to use CWT as signed messages.
          -A: Ludwig Seitz: Isn't there contention in the OAuth WG about whether
          all messages should be JWTs.  Isn't it only for introspection purposes?
          -A: Mike Jones: The OAuth draft is strictly scoped to the authorization
          and responses.  OAuth isn't doing it for introspection at present.
          -A: Ludwig Seitz: My concern is aligning with OAuth could delay
          publication of the ACE framework.
          -A: Mike Jones: You are not going to introduce a normative reference.
          It would be a non-normative reference.
          -A: Jim Schaad: I don't think we even need the informational reference,
          unless we want to document that we are going to carry those messages in
          the framework
          -A: Ludwig Seitz: Do you expect that this would be an additional draft
          that describes the CWT representation?
          -A: Jim Schaad: Right.
          Per Slide #3, Discussion Point #4: Alignment with OAuth
          Comment: Hannes Tschofenig: We try to be more specific in the resource
          identifier it makes the implementation simpler on the resource server
          because there is a standardized way to do the comparison.  Otherwise you
          have to have out-of-band communication in order to describe the semantics.
          The current approach makes the comparison more precise. Do you have a
          use case that needs a more relaxed description?
          -A: Ludwig Seitz: No, I don't have such a use cases.  The challenge I
          was addressing is that the URLs of constrained devices change when they
          travel (move from one network to another).  It makes it tricky to use
          this resource identifier.
          -A: Hannes Tschofenig: I see.  Good question.
          -A: Ludwig Seitz: Let's continue this discussion on the mailing list
          Q: Jim Schaad: Is the confirmation text well aligned?
          -A: Ludwig Seitz: It is.
          Per Slide #4, Discussion Point #5: Multiple tokens for one RS and client
          How should the RS handle it?  Option #1: New token amends; Option #2:
          New token overwrites.
          Comment: Ludwig Seitz: the draft currently implies Option #1, but Option
          #2 would be simpler.  Would anyone have strong feelings with Option #2?
          -A: Jim Schaad: I don't have a strong feeling, but there are two things
          I want to raise. Many times the newer tokens is for a shorter-lifetime,
          so it might be expired sooner. I know there is a draft in oauth WG for
          incremental updates.
          -A: Ludwig Seitz: We should take a look at that.
          Comment: Olaf: +1 for option 2.
          Per Slide #4, Discussion Point #6: Expiration of tokens based on sequence
          numbers for devices with no internal clock
          Comment: Ludwig Seitz: Not very secure and as it is not probable.
          This mechanism seems obsolete and I would recommend to remove that.
          Any opposition?
          -- No concerns raised.
          Per Slide #4, Discussion Point #7: Symmetric cnf keys and multi RS
          Comment: Ludwig Seitz: Might lead to impersonating. Should we recommend
          against using symmetric cnf keys in multi resource servers?
          -A: Jim Schaad: Recommend the text recommend SHOULD NOT and wait for
          use cases to think against about it.
          -A: Ben Kaduk: I would be pretty uncomfortable to allow, so we'd need
          a good use case to proceed.
          -A: Ludwig Seitz: Is SHOULD NOT strong enough?
          -A: Roman Danyliw: Perhaps MUST NOT or NOT RECOMMENDED?
          -A: Ben Kaduk: It would depend on the rest of the text.
          -A: Ludwig Seitz: Let's go to the ML for further discussion.
          NEXT STEPS: (Jim Schaad): When could the next version of the draft be
          -A: Second-half of December 2018
          DTLS Profile for ACE
          presenter: Göran Selander
          draft: draft-ietf-ace-dtls-authorize
          Göran Selander presented updated made in the -05 version of the DTLS
          profile draft and led a discussion around WGLC feedback.
          Per Slide #3 (WGLC #1)
          Q: Hannes Tschofenig: Is the client supposed to send the key ID to the
          AS or the other way around?
          -A: Göran Selander: It is the AS
          -A: Hannes Tschofenig: But the AS can provide that key ID already.
          -A: Göran Selander: This was missing in the text
          -A: Jim Schaad: This issue has been overtaken by events, we should use
          refresh tokens without using the key ID.
          -A: Göran Selander: Do we need a special case for RPKs.  It's the same,
          so no
          Per Slide #4 (WGLC #2)
          Comment: Göran Selander: I'm not sure if I understand the question in
          this WGLC feedback
          -A: Hannes Tschofenig: JWT answer to this is to include an algorithm id.
          -A: Göran Selander: That is easy to address.
          Per Slide #5 (WGLC #3)
          -- No feedback
          Per Slide #6 (WGLC #4)
          Q: Jim Schaad: I don't remember this proposal being in the reviewed
          drafts and don't know what it does.
          -A: Göran Selander: It transport the salt.  Use the key shared between
          AS and RS to derive the key.
          -A: Hannes Tschofenig: Is this a good idea? You are adding another key
          derivation approach that needs to be implemented?  It would be good if
          the JWT and CWT functionality matches.
          -A: Göran Selander: Yes this approach is typical for 6tish where a CWT
          doesn't fit in one segment.  It's the constrained use case.
          -A: Ludwig Seitz: It also has the advantage that an attacker who learns
          the content of the cnf claim can not derive the key.
          -A: Hannes Tschofenig: There is an assumption of confidentiality between
          the client and AS already.
          -A: Göran Selander: This would be encrypted and this wouldn't only have
          to be integrity protected.
          -A: Jim Schaad: Yes, it which will already be encrypted. I am worried
          about possible problems with the keys being protected correctly. You
          are adding a key derivation on a secret that was meant to do something
          to do something else.
          -A: Göran Selander: Agreed.  The intention was to use a derived key.
          I'll check if it is written in the draft.
          Q: Göran Selander: The question is how would the cnf look like (not
          whether the method should be used).
          -A: Hannes Tschofenig: From the JSON version/JWE, there is an unencrypted
          version or not.  Do you want an encrypted and not encrypted version?
          -A: Göran Selander: No, not encrypted, but it could be.
          -A: Hannes Tschofenig: Is it a key container or a JWE.  But then you'd
          need a wrapper.
          -A: Göran Selander: It used to have that in the COSE key container. We
          realized it is not a good idea.
          -A: Jim Schaad: You are missing a layer in your example.
          -A: Göran Selander: Yes, reading your review you made that clear.
          NEXT STEPS: (Roman Danyliw): When could the next version of the draft
          be published?
          -A: December 2018
          OSCORE Profile for ACE
          presenter: Francesca Palombini
          draft: draft-ietf-ace-oscore-profile
          Francesca Palombini summarized changes to the OSCORE profile draft made
          in -05 and led a discussion around WGLC and related open issues.
          Per Slide #3:
          Q: Francesca Palombini: Are there more situation where the client or
          the server needs to discard their security context?
          -- none heard
          -A: Francesca Palombini: If you have ideas, please send them to the
          mailing list
          Per Slide #4:
          Q: Francesca Palombini: IANA registry creation with Expert Review Required
          for parameter registration.  Is there feedback?
          -- none heard
          Per Slide #5-16, the client and the RS can forget the sec ctx and they
          might forget the tokens. The client can get an old, non-expired token
          from AS.   There might be place for an replay attack if the RS loses it's
          security ctx. To solve this, we add a nonce from the RS to the client.
          The usage of nonce is now mandatory.  There are three options.  Option #3
          is preferred but requires a change to the ACE framework (instead of just
          the payload, send a map).
          Comment: Ludwig Seitz: Like proposal 3.  We need to define a new content
          type for sending CWTs directly (ACE+CWT). Profiles that use auth end
          point can use this new content type.
          -A: Francesca Palombini: However, in the ACE framework, the content
          format ACE+CBOR is only defined for client-to-AS and vice versa, but
          not client-to-resource server.
          -A: Ludwig Seitz: That is an oversight. I will create an issue.
          -A: Ben Kaduk: In terms of cryptographic usage, proposal 3 is the best.
          Comment: Carsten Bormann: I am confused as to what just got said about
          media types. There is CWT media type. What do you want to define?
          "+CWT" doesn't exist.
          -A: Francesca Palombini: I said I want to define ACE+CBOR to send a CBOR
          map (of a nonce and CWT).  Ludwig said he will update the framework for
          ACE+CWT to sent just a CWT.
          -A: Carsten Bormann: Let's take that offline.
          Comment: Mike Jones: In the secevent WG, they just finished the security
          token draft which was the first to use a +JWT media suffix (secevent+jwt).
          Hence, it wouldn't be unheard of for such a draft to introduce such
          media type and you can copy the text from the secevents draft.
          -A: Francesca Palombini: Understood.  This still seems related to the
          previous conversation with Ludwig and Carsten on media format.
          Comment: Francesca Palombini: I heard people like option 3, which is
          Per Slide #17:
          Q: Jim Schaad: Is there a problem with using a content type with a
          created response?
          -A: Francesca Palombini: No.
          -A: Ludwig Seitz: I don't see a problem with that.
          -A: Carsten Bormann: I also don’t see a problem.  As long as the media
          types doesn't start to mean something different.
          Q: Francesca Palombini: Nonce is only registered for AS-to-client
          response.  Can it be made more general?
          -A: ?: Yes.
          NEXT STEPS: (Roman Danyliw): When could the next version of the draft
          be published?
          -A: Early December 2018
          PoP Key Semantics for CWTs
          presenter: Mike Jones
          draft: draft-ietf-ace-cwt-proof-of-possession
          Mike Jones presented changes made to the PoP draft based on WGLC feedback
          and identified the outstanding issue.
          NEXT STEPS: (Chairs): When could the next version of the draft be
          -A: in the next few days
          EST over secure CoAP
          presenter: Michael Richardson
          draft: draft-ietf-ace-coap-est
          Michael Richardson presented updates made in the -06 of the EST over
          secure CoAP draft, and feedback from multi-party interop testing.
          Q: Michael Richardson: this draft has applications in particular vertical
          use cases.  There is concern that this draft won't survive IESG review
          without more text on why this approach is secure.  However, detailing
          the use cases may be a rat hole.
          -A: Hannes Tschofenig: Our use cases is for device management for IoT.
          -A: Michael Richardson: Do you think we should include this use case in
          the draft.
          -A: Hannes Tschofenig: We are open about this use case.  This use case
          horizontal across many vendors.
          -A: Michael Richardson: Between vendor and customers; not "internet level"
          interoperable - having different manufacturers, customers, etc.
          -A: Hannes Tschofenig: We provision at device manufacturing
          Comment: Jim Schaad: EST is secure by TLS.
          -A: Michael Richardson: Yes.
          -A: Jim Schaad: You aren't talking about securing in the channel but
          how you get trust in the channel
          -A: Michael Richardson: Correct.
          -A: Jim Schaad: No, I don't think we need to add text.
          -A: Christen: You could describe in certain details how a person buys a
          widget and how it is registered. The concern with this use case is likely
          if that person wants to reset that device and then how the manufacturer
          would support it.
          -A: Michael Richardson: This protocol has none of that. There is no magic,
          only a static list of clients and servers.
          -A: Christen?: ?
          -A: Hannes Tschofenig: I don't worry about future IESG comments on that.
          (Roman Danyliw) Does anyone disagrees that this draft is ready for WGLC?
          -A: Peter van der Stok: Has edits to make.
          NEXT STEPS: (Roman Danyliw): When could the next version of the draft
          be published? and the basis of a WGLC?
          -A: Early December 2018
          New Work Adoption
          The chairs engaged the WG to under the level of interest in adopting
          three draft related to group communication.  Adoption on these drafts
          has been deferred in recent meetings pending progression of the early
          documents to WGLC.
          For each draft three questions were asked:
          ** (as a hum) Is it worthwhile to do -- adoption? should not do? don't
          ** Would you want to review it?
          ** Would you want to implement it?
          Comment: Francesca Palombini: Before we discuss the second draft, as
          an author, I want to make it clear that it hasn't been updated recently
          or prioritized.  It was also delayed due to work in CORE.
          -A: Roman Danyliw: Are you recommending we don't call for adoption?
          -A: Francesca Palombini: Your decision.
          ** adoption hum: considerable humming for adoption, some for not knowing.
          ** reviewers: ~6
          ** implementers: ~3
          Comment: Carsten Bormann: This is a comment on group communication.
          I'm not sure if CORE not making progress should prevent us from moving
          ** adoption hum: loudest on "no idea"
          ** reviewers: ~4
          ** implementers: none
          Comment: Jim Schaad: Most people seem to have no idea. Would anyone who
          hummed no idea want to explain what they would need to make a decision?
          -A: Göran Selander: This is important work.  However, it hasn't been
          prioritized.  Let's visit at a later meeting.
          ** adoption hum: hums heard in favor of adoption and don't know
          ** reviewers: ~5
          ** implementers: ~2-3
          Open Mic
          Comment: Ari Keraenen: I understand that pubsub is of lower priority.
          However, it is planned to be finished, so it will be a pity if the work
          is abandoned.
          -A: Jim Schaad: I have been hearing this for quite some time. I would
          like a substantial updates.
          -A: Ari Keraenen: There is a substantial progress and implementation.
          I hope we will be able to push it through the final line soon.
          Q: Ludwig: There was prior discussion (and a draft) on ACE with MQTT?
          Is there interest?  My impression is MQTT is commonly used.
          -A: Jim Schaad: My understanding from the authors of that draft was that
          they weren't ready to take it to a WG yet.
          Comment: Hannes Tschofenig: It would be nice to see more productions
          implementations of ACE.  What I see is prototype implementations. It is
          one thing to push through documents quickly (or relatively quickly).
          -A: Carsten Bormann: If I had the money to invest in a product, would I
          implement it and hope that in 2-3 years the IESG will accept it? We are
          damaging the reputation of being able to push things through. Pubsub
          is just an example application, but there are other examples as well,
          which would benefit from standardized solutions. Maybe this has been
          represented differently from how it is going to be used. I am not sure
          it will only be used in pubsub.
          -A: Zach Shelby: I disagree with Carsten.  We should build real
          application for real people and get that experience.  We don't need a
          completed drafts for implementations.  I see feature creep in IoT drafts
          -- more at every meeting.
          -A: Hannes Tschofenig: We have been deploying CoAP over TCP for some time
          before it was finished. We had some problems with different versions,
          but it is possible.
          -A: Carsten Bormann: I agree there is a problem with the deploy-ability
          of the ACE stack. We now have something that might be workable. I am
          not sure having a product is requirement for having a standard. We are
          working with other SDOs that are looking to the IETF for building blocks.
          Only some may be successful.  Are we interested in implementing shouldn't
          be the gating function.
          -A: Zach Shelby: I want to see implementations (not necessarily products)
          that are deployed. It has nothing to do with ARM, Ericson, etc. Other
          SDOs should be kept to the same standard - there is also feature creep
          there as well. This is not only ACE thing, but more IoT level problem.
          Comment: Göran Selander: The group communication is not a feature
          creep. People are asking for it - when can we have this? I don't see a
          problem here.
          -A: Gunter: That is why OCF is talking regularly to T2T.
          -A: Göran Selander: I don't see problem with people implementing things
          in advance or after the protocol is specified.
          -A: Hannes Tschofenig: On group communication, we have been working on
          and will release the code.  The draft was unfortunately shutdown by Mike
          St. Jones because of not liking the symmetric keys.
          Comment: Hannes Tschofenig: In LWM2M we have published version 1. We will
          have a plug-fest interop event - even non-members can come. We have been
          using things from the CORE WG.
          -A: Carsten Bormann: Where and when?
          -A: Hannes Tschofenig: I think in April next year in Amsterdam or ... -
          I can send an email to the ML.
          Comment: Carsten Bormann: Maybe in Prague we can have more than 2 days
          for plugtests as 2 days are not enough. We could for example start on
          Wednesday or something.
          Q: Francesca Palombini: When do you think we can have the decisions on
          those works?
          A: Chairs: We will take things to the ML, so maybe a couple of weeks.
          Closing and Summary
          The discussed documents will be updated per the following schedule:
          ** draft-ietf-ace-oauth-authz: Second-half of December 2018
          ** draft-ietf-ace-dtls-authorize: December 2018
          ** draft-ietf-ace-oscore-profile: Early December 2018
          ** draft-ietf-ace-cwt-proof-of-possession: in the next few days
          ** draft-ietf-ace-coap-est: Early December 2018 (and then WGLC)

Generated from PyHt script /wg/ace/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -