Subject: [kitten] channel binding?

From: William Mills <[email-masked]>
Date: Mon, 14 May 2012 17:02:37 -0700 (PDT)

What's the prevailing wisdom on channel binding, is it still the case that we SHOULD define SASL mechanisms that support channel binding along with non-bound ones?

Thanks,

-bill

---

From: Nico Williams <[email-masked]>
Date: Mon, 14 May 2012 21:04:28 -0500

On Mon, May 14, 2012 at 7:02 PM, William Mills <[email-masked]> wrote:
> What's the prevailing wisdom on channel binding, is it still the case that
> we SHOULD define SASL mechanisms that support channel binding along with
> non-bound ones?

Very much so, yes.  But that doesn't mean that you can't create new
SASL mechanisms that can't do channel binding.  The key is that if a
mechanism could support it given its fundamentals, then it must
support it.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 May 2012 15:57:40 +0200

> mechanism could support it given its fundamentals, then it must

+1

What hasn't been clear to me if there is any way to achieve channel
binding with OAuth.  Possibly it is in a similar situation as SAML which
resulted in the two SASL mechanisms SAML20 and SAML20EC, namely, that
the traditional and most common deployment of the protocol does not
easily support it, but it may be possible to use some extension to
achieve channel bindings.  If this is the case, I think it would be nice
if both variants could be achieved within the same SASL mechanism.
Unless that becomes very ugly.  If it becomes ugly, it may be simpler to
have two SASL mechanisms that each become less complex.

/Simon

---

From: William Mills <[email-masked]>
Date: Tue, 15 May 2012 08:53:52 -0700 (PDT)

I'd prefer to go with two mechanisms.  It makes the logic MUCH simpler.  Policy is then implemented by the mechanism you advertise.

-bill

>________________________________
> From: Simon Josefsson <[email-masked]>
>To: Nico Williams <[email-masked]> 
>Cc: William Mills <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, May 15, 2012 6:57 AM
>Subject: Re: channel binding?
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 May 2012 10:12:42 -0600

On 5/15/12 7:57 AM, Simon Josefsson wrote:
> achieve channel bindings. 

I think that's right for the OAuth case.

> If this is the case, I think it would be nice

No strong preference here.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 May 2012 21:55:25 +0200

William Mills <[email-masked]> writes:

> I'd prefer to go with two mechanisms.  It makes the logic MUCH
> simpler.  Policy is then implemented by the mechanism you advertise.

Thinking about how SAML20 and SAML20EC could be collapsed into one
mechanism (it would become quite complex), I am inclined to agree.  I
guess it depends on the underlying protocol, for SCRAM it makes sense to
have both variants in the same document, but for complex environments
like SAML and OAuth it might not make sense.

/Simon

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 May 2012 16:24:04 +0100

> simpler.  Policy is then implemented by the mechanism you advertise.
If the only difference is to say "I don't want to use/don't have access 
to channel binding data", then I think 2 variants of 1 mechanism are 
actually simpler to implement overall.
>
> -bill
>
>     ------------------------------------------------------------------------
>     *From:* Simon Josefsson <[email-masked]>
>     *To:* Nico Williams <[email-masked]>
>     *Cc:* William Mills <[email-masked]>; "[email-masked]"
>     <[email-masked]>
>     *Sent:* Tuesday, May 15, 2012 6:57 AM
>     *Subject:* Re: channel binding?
>
>     Nico Williams <[email-masked]
>     <mailto:[email-masked]>> writes:
>
>     > On Mon, May 14, 2012 at 7:02 PM, William Mills
>     <[email-masked] <mailto:[email-masked]>> wrote: