Subject: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35)

From: Brian Campbell <[email-masked]>
Date: Mon, 16 May 2016 14:22:28 -0600

It seems like github recently started sending some notifications to the WG
list but it's not clear how reliable that is so I'm gonna double post
anyway. The text from
https://github.com/TokenBinding/Internet-Drafts/issues/35 follows.

As mentioned at IETF 95
<https://datatracker.ietf.org/doc/minutes-95-tokbind/> I propose that the
referred Token Binding be sent via a separate header (say
Sec-Referred-Token-Binding) rather than as part of the Sec-Token-Binding
header.

At the HTTP layer separate headers will make it much more clear what is
going on. Just looking for the presence or absence of the
Sec-Referred-Token-Binding header will indicate if a referred TB was sent,
which is very easy. Rather than having to decode the Sec-Token-Binding
header value and process the binary content, which is possible but much
more involved.

Having a separate header for the referred TB allows the client/user agent
to always send the provided TB via Sec-Token-Binding and not have to build
a new TB message on the redirect request and then go back to the provided
TB on subsequent requests. Also not having the value of Sec-Token-Binding
change (other then a new TLS session with new EKM) should make it nicely
efficient with HTTP/2 header compression.

I also believe it will be easier to covey the concepts in the text of the
spec. Talking about when the Sec-Referred-Token-Binding is sent or not sent
rather than talking about when the referred TB is included as part of the
TB message that is sent with Sec-Token-Binding seems much more
straightforward.

Anecdotally, there's been some discussion about using TB in OpenID Connect
and and in talking about it people often say "the referred token binding
header", which isn't accurate relative to HTTPSTB-03 but belies the fact
that federation folks already think about it as separate header. And I
think that's a natural way think about it so it's not terribly surprising.
I won't name any names but one of the chairs of the WG is among those who
said "the referred token binding header."

I realize this is not an insignificant change but I strongly believe it'd
be a simplification and improvement for HTTPS TB. There's not yet (that I'm
aware of anyway) any profiling of TB for federation like protocols such
OpenID Connect, OAuth or SAML so this would be an opportune time to change
how the referred Token Binding is conveyed.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 17 May 2016 17:21:29 +0000

Hi Brian,

The current format, where all Token Bindings are contained in one Token Binding message, provides useful encapsulation. The HTTP layer does not need to know the details of the Token Binding protocol, which can be implemented in a separate library. If tomorrow we define a new Token Binding type, an existing HTTP implementation can carry it in the Sec-Token-Binding header without modification. Only the Token Binding library would need to be updated.

Ø  At the HTTP layer separate headers will make it much more clear what is going on. Just looking for the presence or absence of the Sec-Referred-Token-Binding header will indicate if a referred TB was sent, which is very easy.
This can be solved by including a TB parser in the protocol analyzer. Which would also provide further useful insights into TB key parameters, etc.

Ø  Having a separate header for the referred TB allows the client/user agent to always send the provided TB via Sec-Token-Binding and not have to build a new TB message on the redirect request and then go back to the provided TB on subsequent requests.
I don’t think there’s an optimization an HTTP stack can do WRT building TB messages that a Token Binding library can’t, and the Token Binding library is where such optimizations belong.

For the above reasons, I would prefer to keep all Token Bindings in one Token Binding message.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Monday, May 16, 2016 1:22 PM
To: IETF Tokbind WG <[email-masked]>
Subject: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35)

It seems like github recently started sending some notifications to the WG list but it's not clear how reliable that is so I'm gonna double post anyway. The text from https://github.com/TokenBinding/Internet-Drafts/issues/35 follows.

As mentioned at IETF 95<https://datatracker.ietf.org/doc/minutes-95-tokbind/> I propose that the referred Token Binding be sent via a separate header (say Sec-Referred-Token-Binding) rather than as part of the Sec-Token-Binding header.

At the HTTP layer separate headers will make it much more clear what is going on. Just looking for the presence or absence of the Sec-Referred-Token-Binding header will indicate if a referred TB was sent, which is very easy. Rather than having to decode the Sec-Token-Binding header value and process the binary content, which is possible but much more involved.

Having a separate header for the referred TB allows the client/user agent to always send the provided TB via Sec-Token-Binding and not have to build a new TB message on the redirect request and then go back to the provided TB on subsequent requests. Also not having the value of Sec-Token-Binding change (other then a new TLS session with new EKM) should make it nicely efficient with HTTP/2 header compression.

I also believe it will be easier to covey the concepts in the text of the spec. Talking about when the Sec-Referred-Token-Binding is sent or not sent rather than talking about when the referred TB is included as part of the TB message that is sent with Sec-Token-Binding seems much more straightforward.

Anecdotally, there's been some discussion about using TB in OpenID Connect and and in talking about it people often say "the referred token binding header", which isn't accurate relative to HTTPSTB-03 but belies the fact that federation folks already think about it as separate header. And I think that's a natural way think about it so it's not terribly surprising. I won't name any names but one of the chairs of the WG is among those who said "the referred token binding header."

I realize this is not an insignificant change but I strongly believe it'd be a simplification and improvement for HTTPS TB. There's not yet (that I'm aware of anyway) any profiling of TB for federation like protocols such OpenID Connect, OAuth or SAML so this would be an opportune time to change how the referred Token Binding is conveyed.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 17 May 2016 14:57:29 -0600

Despite my lack of agreement, Andrei, I appreciate the reply. My replies
inline below...

On Tue, May 17, 2016 at 11:21 AM, Andrei Popov <[email-masked]>
wrote:

> Hi Brian,
>
>
>
> The current format, where all Token Bindings are contained in one Token
> Binding message, provides useful encapsulation. The HTTP layer does not
> need to know the details of the Token Binding protocol, which can be
> implemented in a separate library. If tomorrow we define a new Token
> Binding type, an existing HTTP implementation can carry it in the
> Sec-Token-Binding header without modification. Only the Token Binding
> library would need to be updated.
>

The HTTP layer does need to know about TB for TB to be of any value -
that's where the signature(s) get verified and where cookies and other
tokens are actually bound.  If a new Token Binding type is defined (which
honestly seems unlikely), yes it could be carried in the current format but
the HTTP layer would also need to be updated to do anything useful with it.
I don't see the benefit of this encapsulation.

Ø  At the HTTP layer separate headers will make it much more clear what is
> which is very easy.
> This can be solved by including a TB parser in the protocol analyzer.
> Which would also provide further useful insights into TB key parameters,
> etc.
>
>
But my point isn't that it can't be done. It's that it's really useful to
be able to look at HTTP and tell whats going on without having to use a
protocol analyzer or TB parser.

> Ø  Having a separate header for the referred TB allows the client/user
> agent to always send the provided TB via Sec-Token-Binding and not have to
> build a new TB message on the redirect request and then go back to the
> provided TB on subsequent requests.
>
> I don’t think there’s an optimization an HTTP stack can do WRT building TB
> messages that a Token Binding library can’t, and the Token Binding library
> is where such optimizations belong.
>

It's not an optimization but rather just a simplification where the
provided TB is always sent the same way no matter what and the
referrer/referred is processed independently. To my eye, that's better
cohesion and less coupling.

HTTP/2 header compression, however, is an optimization in the HTTP layer
that would be helped by having the provided TB header not change.

> For the above reasons, I would prefer to keep all Token Bindings in one

I got a pretty good idea of your preference when I first mentioned separate
headers in BA :) My preference is obviously different and I wanted to voice
that on the list/github. But I guess ultimately it's an aesthetics or eye
of the beholder kind of thing. I won't fight about it too hard. And I'm
just a guy, not an editor. But I was looking the share the viewpoint of
what seems simpler at the HTTP layer from someone who works primarily at
the HTTP layer. I hope that viewpoint can be considered even though two
headers is different than what's already done.

I'd also be interested in knowing if others in the WG have opinions here or
if I'm the outlier?

> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Brian
> Campbell
> *Sent:* Monday, May 16, 2016 1:22 PM
> *To:* IETF Tokbind WG <[email-masked]>
> *Subject:* [Unbearable] HTTPSTB: distinct header for the referred Token
> Binding (issue #35)
>
>
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 17 May 2016 21:46:37 +0000

On 5/17/16, 3:57 PM, "Unbearable on behalf of Brian Campbell" <[email-masked] on behalf of [email-masked]> wrote:

>
>I'd also be interested in knowing if others in the WG have opinions here or if I'm the outlier?

I'm still assessing, but I think as a general rule the world has demonstrated that where the web is concerned, traditional views of library separation of concerns are not valued, so even if one person thought having a separate library for this made sense, the twenty scripters in the next room wouldn't.

My concerns are more the issues around integration with the TLS layer, which I am still unconvinced are going to be tractable any time soon. I don't see any way to implement this on top of Java right now, for example, no matter what layer you're in. If you think that's possible, I'd be very interested in an offline discussion on that.

On the SAML side, there's already an extension that's reasonably situated to carry the necessary information at that layer, but it doesn't do much good if there's nothing to put in it. In the same way I can't support tls-unique channel bindings in Java, I don't think I can support this either. Or possibly on top of OpenSSL, but that's less clear at this point.

-- Scott

---

From: John Bradley <[email-masked]>
Date: Tue, 17 May 2016 18:58:08 -0300

This did come up at IETF 95.  

I haven’t seen strong sentiment in favour of this proposed change. 

I have in conversations used the term “referred token binding header” to refer to the Sec-Token-Binding header containing a TokenBinding with TokenBindingType referred_token_binding in addition to a TokenBinding structure with TokenBindingType provided_token_binding. 

It is just easier to say to get the higher level federation point across.  Perhaps I need to be more specific with some people:)

If people have strong feeling s about this it will soon be too late to do major surgery as we would like to get to the testing and interop phase ASAP to get this puppy out ad doing some good in the world soon.

John B.

> On May 17, 2016, at 2:21 PM, Andrei Popov <[email-masked]> wrote:
> 
> Hi Brian,
>  
> It seems like github recently started sending some notifications to the WG list but it's not clear how reliable that is so I'm gonna double post anyway. The text from https://github.com/TokenBinding/Internet-Drafts/issues/35follows. 
> 
> 
> As mentioned at IETF 95 I propose that the referred Token Binding be sent via a separate header (say Sec-Referred-Token-Binding) rather than as part of the Sec-Token-Binding header.
> 
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable

---

From: John Bradley <[email-masked]>
Date: Tue, 17 May 2016 19:06:20 -0300

Good point Scott.

We do have commitment from the browser venders, but that doesn’t help much on the server side.

There is a python test server as part of Chromium but that is based on libs not commonly supported.   Roland Headburg is looking at how Python support can be added.

There are people looking at what the best approach fro Java will be (Including Brian)

We will also need coverage of other platforms and support in reverse proxies.   I understand that this is not going to be an overnight thing. 

The sooner we lock down the spec and get the tooling going the better.

PS there are also iOS and Android libs available for native apps, as well as win 10 needing a update to support the current version.

John B.
> On May 17, 2016, at 6:46 PM, Cantor, Scott <[email-masked]> wrote:
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 17 May 2016 22:15:43 +0000

>We do have commitment from the browser venders, but that doesn’t help much on the server side.

Yes, sorry, I should have acknowledged that. Takes two to tango though.

>There are people looking at what the best approach fro Java will be (Including Brian)

I was unsubtly trying to elicit that information.

Separately, has anybody reviewed whether this *is* actually sufficiently the same as GSS channel binding such that it should be defined as a CB type? I have not been able to identify a meaningful difference that would preclude doing so, and if this is going to get implemented, then it should replace tls-unique, which has not been implemented (significantly).

Selfishly, that makes it more trivial for me to do less work since CB was already profiled for use in SAML.

Thx,
-- Scott

---

From: John Bradley <[email-masked]>
Date: Tue, 17 May 2016 19:30:32 -0300

TLS unique is insecure.  That caused some changes to token binding to require the key to sign over the EKM instead.

The token binding ID is a public key that signs over a EKM (formerly tls unique ) and is placed in a header to give the readers digest version.

GSS-API is not HTTP so we would need a way to replace the HTTP header carrying the token binding message.

This may be relevant for OAuth over SASL RFC 7628 where you want to token bind a OAuth AT over SASL from say a mail client.  
I suspect there are issues that would need to be addressed as I don’t think that it is a drop in replacement at the federation level. 
That might be the place to put it after everything else is sorted.

John B.

> On May 17, 2016, at 7:15 PM, Cantor, Scott <[email-masked]> wrote:
>

---

From: Andrei Popov <[email-masked]>
Date: Tue, 17 May 2016 22:35:46 +0000

Ø  The HTTP layer does need to know about TB for TB to be of any value - that's where the signature(s) get verified and where cookies and other tokens are actually bound.
With the current TB message structure, the HTTP layer can simply pass the contents of the header to the TB library, get back verified bindings and act on the ones that the HTTP layer understands. And I like the fact that currently the TB library gets all available TB information at one time and in one piece.

Ø  But my point isn't that it can't be done. It's that it's really useful to be able to look at HTTP and tell whats going on without having to use a protocol analyzer or TB parser.
Understood. I’m merely pointing out that e.g. when debugging an issue, it’s usually not enough to see what types of bindings were sent, so generally one can’t avoid parsing TokenBinding messages anyway, and parsing tools will likely become available.

Ø  It's not an optimization but rather just a simplification where the provided TB is always sent the same way no matter what and the referrer/referred is processed independently
Provided and referred bindings can’t be processed entirely independently: e.g. referred binding cannot be used if the provided one fails verification. A TB library can only ensure this if it has access to all available bindings.

Ø  But I was looking the share the viewpoint of what seems simpler at the HTTP layer from someone who works primarily at the HTTP layer.
To be clear, I highly value your viewpoint, although I disagree with it. Bringing it up on the mailing list is certainly the right thing to do.

Cheers,

Andrei

From: Brian Campbell [mailto:[email-masked]]
Sent: Tuesday, May 17, 2016 1:57 PM
To: Andrei Popov <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35)

Despite my lack of agreement, Andrei, I appreciate the reply. My replies inline below...

On Tue, May 17, 2016 at 11:21 AM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian,

The HTTP layer does need to know about TB for TB to be of any value - that's where the signature(s) get verified and where cookies and other tokens are actually bound.  If a new Token Binding type is defined (which honestly seems unlikely), yes it could be carried in the current format but the HTTP layer would also need to be updated to do anything useful with it. I don't see the benefit of this encapsulation.

>  At the HTTP layer separate headers will make it much more clear what is going on. Just looking for the presence or absence of the Sec-Referred-Token-Binding header will indicate if a referred TB was sent, which is very easy.

But my point isn't that it can't be done. It's that it's really useful to be able to look at HTTP and tell whats going on without having to use a protocol analyzer or TB parser.

>  Having a separate header for the referred TB allows the client/user agent to always send the provided TB via Sec-Token-Binding and not have to build a new TB message on the redirect request and then go back to the provided TB on subsequent requests.

It's not an optimization but rather just a simplification where the provided TB is always sent the same way no matter what and the referrer/referred is processed independently. To my eye, that's better cohesion and less coupling.

HTTP/2 header compression, however, is an optimization in the HTTP layer that would be helped by having the provided TB header not change.

I got a pretty good idea of your preference when I first mentioned separate headers in BA :) My preference is obviously different and I wanted to voice that on the list/github. But I guess ultimately it's an aesthetics or eye of the beholder kind of thing. I won't fight about it too hard. And I'm just a guy, not an editor. But I was looking the share the viewpoint of what seems simpler at the HTTP layer from someone who works primarily at the HTTP layer. I hope that viewpoint can be considered even though two headers is different than what's already done.
I'd also be interested in knowing if others in the WG have opinions here or if I'm the outlier?

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Campbell
Sent: Monday, May 16, 2016 1:22 PM
To: IETF Tokbind WG <[email-masked]<mailto:[email-masked]>>
Subject: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35)

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 17 May 2016 22:37:32 +0000

>TLS unique is insecure.  That caused some changes to token binding to require the key to sign over the EKM instead.

Insecure when used for CB? I'm not suggesting tls-unique is somehow usable *here*.

I'm not suggesting this is the same as CB, I'm basically asking if this particular derivation of the TLS session could also be used as a CB type within GSS.

>This may be relevant for OAuth over SASL RFC 7628 where you want to token bind a OAuth AT over SASL from say a mail client.

Right.

-- Scott

---

From: John Bradley <[email-masked]>
Date: Tue, 17 May 2016 19:54:20 -0300

The TLS unique is vulnerable to the 3 way handshake attack https://mitls.org/pages/attacks/3SHAKE at-least for HTTP over TLS.  
I am guessing that the same would apply to other protocols over TLS, but don’t take my work for it.

EKM  RFC 5705 is what Token binding is using instead of TLS Unique.  

John B.

> On May 17, 2016, at 7:37 PM, Cantor, Scott <[email-masked]> wrote:
>

---

From: Andrei Popov <[email-masked]>
Date: Tue, 17 May 2016 23:12:54 +0000

Triple handshake attack allows MITM to synchronize TLS master secrets of the client-to-MITM TLS session and the MITM-to-server TLS session.
This defeats all bindings that are based on a product of the TLS master secret, including those based on TLS-UNIQUE and keying material exporters.
For this reason, Token Binding MUST NOT be used when Extended Master Secret (EMS) is not negotiated. 

Separately, TLS-UNIQUE is weak, regardless of whether the triple handshake attack is mitigated. Therefore, we updated the TB drafts to use keying material exporters.

Cheers,

Andrei

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Tuesday, May 17, 2016 3:54 PM
To: Scott Cantor <[email-masked]>
Cc: Andrei Popov <[email-masked]>; Brian Campbell <[email-masked]>; IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35)

John B.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 18 May 2016 00:41:18 -0400 (EDT)

On Tue, 17 May 2016, Cantor, Scott wrote:

> I'm not suggesting this is the same as CB, I'm basically asking if this
> particular derivation of the TLS session could also be used as a CB type
> within GSS.

I am not promising to do the research into the interactions between the
token binding EKM material and GSS channel bindings, but the "normal"
thing to do if one wants to bind a given TLS connection to a GSS-API
security context exchanging messages over that TLS connection would be to
define a new EKM for TLS that is used solely for that purpose.  (Reusing
crypto secrets is generally something to be avoided.)  I don't think
anyone has written up a draft for that yet, though...

-Ben

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 18 May 2016 15:58:47 +0000

On 5/17/16, 11:41 PM, "Benjamin Kaduk" <[email-masked]> wrote:

>define a new EKM for TLS that is used solely for that purpose.

If you mean that a new CB type is needed, probably so. If you mean rather that CB as a mechanism should not be used with TLS at present with GSS, I think that probably should be stated somewhere...

But this is more of a kitten conversation, I only raise it here in light of the common problem between both that the lack of support in TLS stacks for exposing the necessary bits makes implementing either difficult at present.

-- Scott

---

From: John Bradley <[email-masked]>
Date: Wed, 18 May 2016 12:10:29 -0400

If you are trying to do OAuth GSSAPI you may not want to have to refresh the AT every time the EKM changes.   
If the Token binding ID were used that could persist over multiple TLS sessions. 

Unfortunately I don’t know off hand what would beed to be done on the GSS side to make that possible.

It might be that using EKM directly and refreshing the AT with a token bound refresh token might be the practical thing to avoid complicated re-plumbing of GSSAPI.

To use Token binding directly the GSS layer would need to validate the TB message and pass the validated token binding id up the stack for the application to validate the access token, or you would need to pass the TB EKM plus the token binding message up the stack for the app to do all of the token binding validation itself.

I agree that getting support in the stacks for access to EKM export is one of the first steps for deployment.

John B.

> On May 18, 2016, at 11:58 AM, Cantor, Scott <[email-masked]> wrote:
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 18 May 2016 12:23:06 -0600

> There are people looking at what the best approach fro Java will be
Yes, I plan to dig into it and see what can be done server side in Java
and/or what the major obstacles are. I do expect it'll be rather
challenging/painful though so I've been biding my time before jumping in by
doing some review and feedback on the current drafts.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 18 May 2016 12:29:53 -0600

Arguing on the internet is usually about this effective in swaying one
viewpoint or the other.

I appreciate the discourse though and, short of a mad rush of support, I
concede on the proposal.

On Tue, May 17, 2016 at 4:35 PM, Andrei Popov <[email-masked]>
wrote:

> Ø  The HTTP layer does need to know about TB for TB to be of any value -
> tokens are actually bound.
>
> With the current TB message structure, the HTTP layer can simply pass the
> contents of the header to the TB library, get back verified bindings and
> act on the ones that the HTTP layer understands. And I like the fact that
> currently the TB library gets all available TB information at one time and
> in one piece.
>
>
>
> Ø  But my point isn't that it can't be done. It's that it's really useful
> to be able to look at HTTP and tell whats going on without having to use a
> Understood. I’m merely pointing out that e.g. when debugging an issue,
> it’s usually not enough to see what types of bindings were sent, so
> generally one can’t avoid parsing TokenBinding messages anyway, and parsing
> tools will likely become available.
>
>
>
> Ø  It's not an optimization but rather just a simplification where the
> referrer/referred is processed independently
>
> Provided and referred bindings can’t be processed entirely independently:
> e.g. referred binding cannot be used if the provided one fails
> verification. A TB library can only ensure this if it has access to all
> available bindings.
>
>
>
> Ø  But I was looking the share the viewpoint of what seems simpler at the
> HTTP layer from someone who works primarily at the HTTP layer.
>
> To be clear, I highly value your viewpoint, although I disagree with it.
> Bringing it up on the mailing list is certainly the right thing to do.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Tuesday, May 17, 2016 1:57 PM
> *To:* Andrei Popov <[email-masked]>
> *Cc:* IETF Tokbind WG <[email-masked]>
> *Subject:* Re: [Unbearable] HTTPSTB: distinct header for the referred
> Token Binding (issue #35)
>
>
>
> Ø  At the HTTP layer separate headers will make it much more clear what
> is going on. Just looking for the presence or absence of the
> I got a pretty good idea of your preference when I first mentioned
> separate headers in BA :) My preference is obviously different and I wanted
> to voice that on the list/github. But I guess ultimately it's an aesthetics
> or eye of the beholder kind of thing. I won't fight about it too hard. And
> I'm just a guy, not an editor. But I was looking the share the viewpoint of

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 18 May 2016 19:15:44 +0000

The change to Java (JSSE) is straight forward, but getting that change made and out into the various versions/implementations of JSSE is a different story 

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, May 18, 2016 9:10 AM
To: Scott Cantor <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>; Andrei Popov <[email-masked]>; Brian Campbell <[email-masked]>; Benjamin Kaduk <[email-masked]>
Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35)

John B.

>> I am not promising to do the research into the interactions between 
>> the token binding EKM material and GSS channel bindings, but the "normal"
>> security context exchanging messages over that TLS connection would 
>> be to define a new EKM for TLS that is used solely for that purpose.
> 

_______________________________________________
Unbearable mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&data=01%7c01%7ctonynad%40microsoft.com%7c005cd47b18f247ad46e808d37f36f4e3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=IdNim2IWUJJgktum0PsQvyAETf%2fBnYd%2bVavRwEi030I%3d

---

From: John Bradley <[email-masked]>
Date: Wed, 18 May 2016 15:25:59 -0400

Sorry I din’t mean to underestimate the amount of political work required for Java.

John B.
> On May 18, 2016, at 3:15 PM, Anthony Nadalin <[email-masked]> wrote:
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 18 May 2016 19:57:33 +0000

>Yes, I plan to dig into it and see what can be done server side in Java and/or what the
> major obstacles are. I do expect it'll be rather challenging/painful though so I've been
> biding my time before jumping in by doing some review and feedback on the current
> drafts.  

If it's not out of line to ask to be in the loop on that, or if I can help with that, I'd appreciate it. I think it will be a somewhat short analysis at present.

-- Scott

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 18 May 2016 22:12:40 +0200

No politics at all. It is just a case of convincing java folks people want it. Normally they would wait for the rfc, but I explained why now is much preferred.  

I am pushing hard for java 9 and then may be retrofit for java 8. 

Still we have to he realistic with platform tech. It will take time to move up the stack into app servers and gateways for example. 

For those that want to voice support please email me and I will send you the team contact. 

I was told we are very late in the java 9 cycle...so be enthusiastic in your support. 

Thanks to those who have already written in. 

Ciao,

Phil

> On May 18, 2016, at 21:25, John Bradley <[email-masked]> wrote:
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 18 May 2016 15:29:02 -0600

Sure, not out of line at all. I'm probably naively hoping to hack/fight
though the reasons you expect it to be a short analysis. But that might be
overly optimistic.

On Wed, May 18, 2016 at 1:57 PM, Cantor, Scott <[email-masked]> wrote:

> and/or what the
> If it's not out of line to ask to be in the loop on that, or if I can help
> with that, I'd appreciate it. I think it will be a somewhat short analysis
> at present.
>
> -- Scott
>
>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 18 May 2016 15:34:53 -0600

I understand the reluctance to put something in before RFC. What's really
needed though isn't support for a draft of TB. What's needed at this point
is the appropriate hooks to implement simple(ish) TLS extensions and get at
the EKM. And that stuff is in RFCs.

Please do send that contact info, Phil.

On Wed, May 18, 2016 at 2:12 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

> No politics at all. It is just a case of convincing java folks people want
> it. Normally they would wait for the rfc, but I explained why now is much
> preferred.
>
> Still we have to he realistic with platform tech. It will take time to
> move up the stack into app servers and gateways for example.
>
> >> The change to Java (JSSE) is straight forward, but getting that change
> made and out into the various versions/implementations of JSSE is a
> different story
> >>
> >> Cc: IETF Tokbind WG <[email-masked]>; Andrei Popov <
> [email-masked]>; Brian Campbell <[email-masked]>;
> Benjamin Kaduk <[email-masked]>
> >> If you are trying to do OAuth GSSAPI you may not want to have to
> refresh the AT every time the EKM changes.
> >> It might be that using EKM directly and refreshing the AT with a token
> bound refresh token might be the practical thing to avoid complicated
> re-plumbing of GSSAPI.
> >>
> >> To use Token binding directly the GSS layer would need to validate the
> TB message and pass the validated token binding id up the stack for the
> application to validate the access token, or you would need to pass the TB
> EKM plus the token binding message up the stack for the app to do all of
> the token binding validation itself.
> >>
> >>> If you mean that a new CB type is needed, probably so. If you mean
> rather that CB as a mechanism should not be used with TLS at present with
> GSS, I think that probably should be stated somewhere...
> >>>
> >>> But this is more of a kitten conversation, I only raise it here in
> light of the common problem between both that the lack of support in TLS
> stacks for exposing the necessary bits makes implementing either difficult
> at present.
> >>>
> >>> -- Scott
> >>