[Security] channel bindings

Dirk Meyer dmeyer at tzi.de
Thu Feb 12 08:03:16 CST 2009


Dave Cridland wrote:
> On Wed Feb 11 15:06:44 2009, Eric Rescorla wrote:
>> It's worth observing that if you're really going to standardize on
>> one
>> news  password
>> based mechanism, it would be more efficient to simply use TLS-PSK or
>> TLS-SRP. The
>> rationale for channel bindings is to retain some existing
>> application level auth
>> infrastructure.
>
> I suspect that disagreeing with Ekr isn't going to be good for my
> health, but...

Now I'm between you two, that can't be a good idea either. :)

> I'm not sure SRP or PSK makes as much sense to us, from a
> deployment/marketing perspective mostly, although with some weak
> technical arguments too.

IMHO they are similar. Both have advantages over the other. While
starting to write down the idea in a XEP and reading XEP-0250 again, I'm
not sure which one is better. The first draft will ignore password
authentication.

> The idea is that the channel binding is actually used one-time to
> verify self-signed certificates, which are subsequently used as-is
> for authentication.

TLS-SRP is used the same way. After you used SRP for the first contact,
you can exchange public keys with XEP-0189 and use X.509-based TLS after
that.

> So you'd use the channel binding process typically once per pair of
> endpoints, whereas the self-signed certificates would be used many
> times - indeed, I'm thinking that the XMPP basis for secure identity
> becomes those X.509 certificates.

Yes. That works for both ideas.

> a) The perceived risk of IPR is such that SRP in particular appears
> to have reduced deployment, and I have concerns that it'd impact
> availability.

Right. That is my major problem. Searching for 'SRP and patent issues' I
see many posts from 200[234] but nothing from today. What is the status?
Eric, do you have some information about that. On the other hand, SCRAM
may have similar problems. You can not know that until someone claims
you are violating a patent.

> d) I'm frankly not sure I've grasped how the SRP/PSK-to-X.509 dance
> works, and at the risk of sounding really arrogant, I'm worried that
> might mean few people within the XMPP community grasp it either.

Well, with SRP we need to know if we need it. Once we started
certificate based TLS, it is too late to switch to SRP when the clients
do not recognize the certificates. What XEP-0250 does is exchange some
information what certificates the clients will use to detect if SRP is
needed or not. That's all. We need something similar for SASL: after TLS
is complete we need to figure out if one client wants to play SASL. In
fact, I have no idea how to do that. Does it only work for e2e chat
messages because it is XML? Is it possible to use a file transfer as
first Jingle application and still use SASL?

> Is there anything I'm missing that rules out using a channel binding
> method for proving the endpoints own a particular certificate?

Look at SCRAM I see one interesting part:

   c: [..] Whether this attribute is included, and the meaning and
   contents of the channel-binding data depends on the external security
   layer in use. This is necessary to detect a man-in-the-middle attack
   on the security layer.

So what is the channel-binding data in our use case?
http://tools.ietf.org/html/draft-altman-tls-channel-bindings-03

   The channel bindings for TLS connections consist of one, the other or
   both of the initial client or server "finished" TLS messages section
   7.4.9 [RFC4346] (note: the unencrypted messages).

That may be a problem. How to get the finished messages? It does not
help if TLS libraries can not provide the data needed for channel
binding. There seems to be gnutls_session_set_finished_function in
gnutls for that reason. I have no idea about other TLS stacks. On other
hand, SRP also requires special TLS stacks.

So it is up to SRP vs. channel-binding.


Dirk

-- 
There are two ways to write error-free programs. Only the third one
works.


More information about the Security mailing list