Subject: [Ietf-krb-wg] tls and channel binding

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Nov 2007 16:33:53 -0500

Hi.
I think I said this a while back but Jeff suggested I say so again.

I believe that if we're going to advance the tls document either as
informational or standards track it should have channel binding
between the Kerberos PDUs and the TLS channel.

This is my opinion as an individual bordering on AD.  I.E. it might
well be a blocking comment but if the WG indicated they disagreed I'd
have to consider carefully before blocking.

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Nov 2007 15:50:26 -0600

> have to consider carefully before blocking.

I agree with what Sam says.  Wherever we separate authentication and
transport protection by introducing a secure channel, and we are able to
do channel binding, then we should do channel binding.

We should require compelling reasons to do otherwise.

In this particular case we gain a lot from being able to do channel
binding (e.g., the ability to learn a realm's KDC certs without
out-of-band, secure trust anchor distribution, and even the ability to
do without server certificates).

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 28 Nov 2007 10:39:11 -0800

How does this affect SSPI compatibility?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Nov 2007 12:51:38 -0600

> How does this affect SSPI compatibility?

You must mean: can this be implemented using SSPI, or <pick your
favorite TLS API>?

The short answer is: not my problem.  If some TLS API lacks a way to
obtain the channel binding of a TLS connection, then pick another API/
implementation or file an RFE with the implementor.

This may sound harsh, but keep in mind that: a) FAST + PKINIT is the
primary solution in this space (i.e., we have consensus for that), while
StartTLS is the secondary solution, b) I don't believe you'll be
implementing a KDC on Windows from scratch, or even at all, though I
might believe that you'd port the MIT krb5 KDC to Windows, in which case
you're not likely to be using the SSPI at all and, in any case, you'd
end up implementing FAST + PKINIT based on MIT krb5 KDC support for it.
Also, c) there's already a KDC on Windows, and that's likely to support
FAST + PKINIT only, but if you really want StartTLS, you might be able
to convince Microsoft to add support for it.

The folks we know want to implement StartTLS know how to get TLS API
support for getting channel bindings, so asking that they do is not
asking all that much.

Nico

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 29 Nov 2007 11:19:05 +0100

> between the Kerberos PDUs and the TLS channel.

I agree, and this has been an open issue for a while, pending the
finalization of RFC 5056.

I propose to solve this by adding a new 'pa-channel-binding'
pre-authentication data type.  A diff with my proposed changes can be
found at:

http://josefsson.org/krb5starttls/draft-josefsson-kerberos5-starttls-from--02.diff.html

The relevant new text is included below for easy citing.

The entire updated document can be found at:

http://josefsson.org/krb5starttls/draft-josefsson-kerberos5-starttls.txt

Do people think this is a good approach?  Are there any details that is
missing to make this work?  Let me know what you think.

May I request that a padata-type value is assigned as documented by RFC
4120?  Then I can implement this and test it in practice.

   Additional preauthentication data type values, as defined in section
   7.5.2, will be assigned subject to review by the Kerberos working
   group or other expert review.

Thanks,
/Simon

However, to conform with this specification, any KDC-REQ (AS-REQ or
TGS-REQ) message MUST contain the "pa-channel-binding"
pre-authentication data.

3. Channel Binding Pre-Authentication Data

The pre-authentication structure is defined in RFC 4120 as:

   PA-DATA ::= SEQUENCE {
     -- NOTE: first tag is [1], not [0]
     padata-type [1] Int32,
     padata-value [2] OCTET STRING -- might be encoded AP-REQ
   }

Here we define a new pre-authentication data, called "pa-channel-
binding". It has a padata-type integer value of #TBD. The contents of
the padata-value field is the channel binding data, as discussed in [6].
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg