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

Tokbind Status Pages

Token Binding (Active WG)
Sec Area: Eric Rescorla, Kathleen Moriarty | 2015-Mar-24 —  
Chairs
 
 


IETF-100 tokbind minutes

Session 2017-11-14 1330-1530: VIP A - Audio stream - tokbind chatroom

Minutes

minutes-100-tokbind-00 minutes



          The meeting started at 13:31.  Note Well was shown.
          
          John Bradley reporting on meeting with AD about HTTPS draft.
          Mike Jones: He's requesting clarifications of non-normative parts?
          JB: Yes.
          JB: We're in good shape. Hopefully we can get it through IESG by the
          end of the year.
          
          Leif: More Q about core documents?
          
          
          Nick talking about TB negotiation in TLS 1.3
          (draft-nharper-tokbind-tls13)
          Leif: Where do we take this?
          NH: My suggestion is that the WG adopt this either as-is or merge with
          the (already accepted) 0RTT draft
          MJ: Is it ever meaningful to implement one without the other?
          NH: yes, you can dislike 0RTT.
          Andrei Popov: TB with 1rtt makes sense. TB with 0rtt has weaker security
          properties. Not sure it makes sense. I'd like to keep the drafts separate.
          Humming:
          
              Like the idea of adopting this (strong hum)
          
              Oppose (crickets)
          
              Don't know (crickets)
          
          Will confirm on the list that we want to adopt this.
          
          Brian Campbell on HTTPS TB with Reverse Proxies
          (draft-campbell-tokbind-ttrp-01 - started 13:42)
          TTRP = TLS Terminating Reverse Proxy
          Stefan Santesson: One way of making this fail-safe is to HMAC the data
          between the RP and the backend server with a shared secret. Have you
          considered this?
          BC: There's a wide variety of ways, but it's a broader problem, so there
          should not be a one-off solutiong for this draft.
          Stefan: Seems to me this is the wrong conclusion. You are specifying
          this header, and you have an opportunity to make this safe - to prove
          that it originates from the reverse proxy.
          BC: I'm looking to avoid setting shared secrets between RP and backend
          server. Don't want more key management issues.
          Leif: Some people suggested making a generic mechanism. The consensus
          last time was that we should not make a one-off solution for this
          here. Somebody should make a generic mechanism (but nobody has done
          so yet)
          
          BC: -01 only supports provided and referred binding types. What about
          others?
          MJ: The TB doc and TB-HTTPS doc can communicate for 256 IDs. All but 0
          and 1 are thrown away in this draft.
          BC: You're right. We'll toss any new.
          MJ: That is not a good protocol design
          BC: It's a good design
          MJ: If you have something with known audiences, you're going to need
          different bindings for different audiences.
          BC: I'd like to know if this is an extension that we want to have
          MJ: it's throwing away information. You should not assume they won't
          be used.
          BC: I think it's simplifying
          NH: There are also extensions (over and above the 245 unused code
          points). I think it's acceptable to have a protocol that covers only
          existing use cases...
          MJ: ...today
          NH: Yes, today.
          MJ: I want it to be defined how this additional information is passed.
          Leif: There is a difference between makind a 1:1 representation and making
          a representation for the majority case with a place for extensibility.
          MJ: If the goal of your draft is to enable communication, you need to
          define how you represent additional binding types.
          JB: Since we don't know what they are, are there specific rules for
          how the TTRP needs to extract the data or are they all the same with
          different numbers?
          MJ: Yes
          Vinod: ...
          MJ: I'm fine with whatever syntax you want. We shouldn't be throwing
          away information. That's my request
          Leif: Can you sit together and come up with some lines defining this?
          BC: I'd like to understand the use case.
          MJ: Like the Microsoft graph where things come in at different TLS
          connections.
          JB: Good to document this use case. Who signs what and what does it mean.
          MJ: I may be able to do this with Tony.  I can work on a syntax proposal
          with Brian this week.
          *** MJ and Brian will offer a concrete proposal on the list.
          
          Piotr Sikora: Regarding token binding types: if we want to add new types
          interoperability is not defined
          MJ: not the job of this document.
          Piotr: But interoperability is not (yet) defined.
          Vinod: Our implementation is roughly the same as this except for the
          header names.  Will move to the standard headers
          Andrei Popov: Entirely possible that future docs will define new
          bindings, but they will also define TTRP processing. Then we have issue
          with discovery.
          BC: Depends on processing rules.  If new bindings follow same processing
          rules, no problem. Otherwise...  We will work on it.
          BC: Hoping for broader implementation interest as things progress.
          Leif: Rough timelines? WGLC by London?
          BC: Perhaps around London.
          
          ====
          Leif: same question for 1.3?
          NH: Should be ready in London for regulsr 1.3.  0rtt might take longer.
          ====
          
          (some shuffling of presentation computers around 14:20)
          
          Attested TLS Token Binding
          (draft-mandyam-tokbind-attest - 14:21)
          JB explains: attestations at the token binding layer.
          JB: has anyone looked at this?
          (2 hands come up - Tony and Brian)
          JB: The notion may be useful for web authorization.
          AP: Great interest in some teams at Microsoft. The strength of the key
          depends on the strength of the key storage
          JB: General idea has some support, but need to wait to know if *this*
          is the one.
          JB: Will not call for adoption now.  Will do so if there's general
          positive feedback.
          
          *** Asking for Open Mic issues.
          
          Jeff Hodges: Anything said about the HTTPS draft?
          JB: We've discussed with AD and he wanted to know what constraints. We'll
          add some text for what kind of federated protocols we intend.
          JH: He will push it?
          JB: Yes, because of our agreement.
          JH: I think he should have sent it to the list.
          Leif: He was not sue if his comments were legit.
          JH: Any changes need to be on the list. Also John, Andrey and my comments.
          Leif: Sure. Nothing to hide.
          JH: That's fine. If there are any notes on the discussion, please send
          to the list.
          
          *** And we're done at 14:28
          
          



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