[kitten] CB data characteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02

Related questions about channel binding data...

CB data is prefixed with the channel binding scheme name and a colon, is there BNF or a definition for what the rest of that looks like?  Do I need to base64 it to make it safe to move in an HTML context?

Also, how big will it end up?  I suppose an SSL certificate can be a few k in the extreme case.

Thanks,

-bill

________________________________
From: Nico Williams <nico@cryptonector.com>
To: "Cantor, Scott E." <cantor.2@osu.edu>
Cc: "kitten@ietf.org" <kitten@ietf.org>; Simon Josefsson <simon@josefsson.org>; Tim Showalter <timshow@yahoo-inc.com>; Sam Hartman <hartmans-ietf@mit.edu>
Sent: Friday, April 8, 2011 12:35 PM
Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02

On Fri, Apr 8, 2011 at 2:27 PM, Cantor, Scott E. <cantor.2@osu.edu> wrote:
>> Unless I'm missing something (wouldn't be the first time) I think 1 and
>> 2 are sufficient for a non-HTTP use case.
>
> It's sufficient for a persistent connection. I think you answered the other case by mentioning cookies. Normally that has a fairly perjorative connotation, but since the client here isn't a browser (read browser as "security sinkhole"), such a cookie isn't a cookie in the "anybody can probably steal it" sense.

HTTP, by its nature, only really allows you to use cookies to tie all
the requests (and responses) that make up an application "session".
Ideally there'd be a little more to it.  For example, the application
could use TLS session IDs to map HTTPS requests and responses to
application sessions, but this is complicated (there could be many TLS
sessions mapping onto one application session, with new TLS sessions
added at any time) and not actually done in practice.  Or the client
and server could share an established GSS security context and place a
MIC in the request/response headers -- a MIC of the request/response
body, and maybe some security-sensitive headers.  But that's not the
HTTP that we have.  HTTP as it is and as we use it allows us only the
use of cookies for this purpose.

Fortunately we also have HTTPS, and we're talking about doing CB.  So
setting a secure-only cookie has been, is, and will continue to be a
reasonable thing to do to solve this particular problem.

Nico
--
_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten