Subject: [Ietf-krb-wg] starttls

From: Sam Hartman <[email-masked]>
Date: Tue, 16 Jun 2009 16:50:12 -0400

I've reviewed the starttls draft again.  I support publication of the
current version of the draft on the informational or experimental
track.

I would prefer that the pre-authentication framework and FAST be the
IETF's recommended approach for securing Kerberos going forward.  I'm
not sure that we need two alternatives for this problem space and I
think that FAST provides a better solution than starttls.  So, I do
not prefer to publish starttls on the standards track--don't count me
as a supporter.

However I understand that my preference is a engineering preference.
Simon is using a different design esthetic in starttls and I can
easily understand why someone might prefer that esthetic.  Starttls
is definitely a simpler document than the pre-authentication framework.

I object to publishing the current version of starttls on the
standards track because of the certificate validation strategy.  There
is no mandatory-to-implement certificate type.  Rules are provided if
X.509 certificates are used, but clients and KDCs are not required to
implement support for X.509 certificates and these rules.  I fully
understand that some deployments do not lend themselves to certificate
validation.  However I think at least KDCs need to have a mandatory to
implement certificate type and clients need to have a
mandatory-to-implement validation rule if they support validation at
all.

If that were fixed, I'd be neutral on starttls on the standards track.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Jun 2009 16:12:49 -0500

> is definitely a simpler document than the pre-authentication framework.

I, for example, prefer the starttls approach from an aesthetic point of
view, and also, perhaps from a security analysis point of view (it's
simpler to analyze Kerberos V pre-auth with channel binding to TLS +
starttls than it is to analyze FAST, though conceptually the two are the
same -- FAST just has more details to consider).  However, I also prefer
the FAST approach from a practical engineering point of view.

> If that were fixed, I'd be neutral on starttls on the standards track.

I agree with this too.

Nico
--

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 16 Jun 2009 15:26:04 -0700

> is definitely a simpler document than the pre-authentication  

STARTTLS have properties that that makes it better then FAST.

No clear text kerberos bits.

This make it harder to push though in enviroments when no clear text  
data is allowed even though its safe. See resent SHA1 vs HMAC-SHA1  
discussion.

Love

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Jun 2009 17:33:02 -0500

> No clear text kerberos bits.

FAST has that too, actually.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Jun 2009 07:02:02 -0400

>>>>> "Love" == Love Hörnquist Åstrand <[email-masked]> writes:

    Love> 16 jun 2009 kl. 13:50 skrev Sam Hartman:

    >> However I understand that my preference is a engineering
    >> preference.  Simon is using a different design esthetic in
    >> starttls and I can easily understand why someone might prefer
    >> that esthetic.  Starttls is definitely a simpler document than
    >> the pre-authentication framework.

    Love> STARTTLS have properties that that makes it better then
    Love> FAST.
I'm not really sure this is true.  I think the only remaining
clear-text Kerberos bit with hide client names enabled is the ticket
server in the reply.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 17 Jun 2009 11:14:35 -0400

> clear-text Kerberos bit with hide client names enabled is the ticket

I think Love's point is that even though all of the _meaningful_ data is 
hidden inside FAST, you still end up seeing Kerberos protocool bits on the 
wire.  With STARTTLS all of that is hidden inside a TLS tunnel, and for 
some reason some people think TLS is magical.  That's silly, of course, but 
there are lots of silly policies out there.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 17 Jun 2009 11:24:47 -0500

> there are lots of silly policies out there.

I agree that it's silly.  I agree that there are silly policies out
there.  I don't agree that because it might some day happen that some
silly person, unable to grasp the point, in some position of power to
make hay of this non-issue, might do just that, that we should choose
STARTTLS over FAST.  Nay, I refuse to do that, as I don't have a crystal
ball that tells me what such sillinesses will or will not arise.

What can be done to help prevent such silliness is to add a security
considerations sub-section that makes it absolutely clear that FAST has
this property that none of the inner data need be visible outside its
tunnel.  Moreover, we could even make it a MUST (if it isn't already)
that the data in the outer request must bear no relationship to the data
in the inner request.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 17 Jun 2009 09:47:22 -0700

> that the data in the outer request must bear no relationship to the  

Like not sending it, but that was rejected.

Love

---

From: Larry Zhu <[email-masked]>
Date: Wed, 17 Jun 2009 19:08:23 +0000

Not a sending it will cause extra significant implementation costs for implementers who have the hand-coded ANS.1 encoders/decoders. The current draft allows us to achieve the same spirit but we can make it clear as what Nico suggested here.

--Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Love Hörnquist Åstrand
Sent: Wednesday, June 17, 2009 9:47 AM
To: Nicolas Williams
Cc: [email-masked]; Sam Hartman; Jeffrey Hutzelman
Subject: Re: [Ietf-krb-wg] starttls

Love

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 17 Jun 2009 15:05:45 -0500

> clear-text Kerberos bit with hide client names enabled is the ticket

Oh, hmmm, that's annoying.  Not terribly so, but enough that we should
consider ways to fix that.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Jun 2009 16:26:03 -0400

Love> 17 jun 2009 kl. 09:24 skrev Nicolas Williams:

    >> What can be done to help prevent such silliness is to add a
    >> security considerations sub-section that makes it absolutely
    >> clear that FAST has this property that none of the inner data
    >> need be visible outside its tunnel.  Moreover, we could even
    >> make it a MUST (if it isn't already) that the data in the outer
    >> request must bear no relationship to the data in the inner
    >> request.

    Love> Like not sending it, but that was rejected.

I think we all agree with you that hiding the exchange is a good idea.

I was against not sending it exactly because it increased my
implementation complexity and didn't buy anything that I could see.
So, yes, I view this exactly like not sending it only better:-).

Now, if I'm missing something please tell me.  I've definitely issed a
lot through this process.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Jun 2009 16:55:43 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
    >> clear-text Kerberos bit with hide client names enabled is the
    >> ticket server in the reply.

    Nicolas> Oh, hmmm, that's annoying.  Not terribly so, but enough
    Nicolas> that we should consider ways to fix that.

Create a fast factor to include the server name, remove it from the
ticket after any ticket extensions are computed and have the client
re-add it.

However it's kind of pointless to do this given that the same server
name is in every ap-req unencrypted.  Modern MIT and all windows
implementations do not use that server name in the normal rd-req path.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 17 Jun 2009 14:47:54 -0700

> implementations do not use that server name in the normal rd-req path.

Having the server perform key identification faster then iteration  
over try all keys would be a good thing. I know of places where there  
are 100+ keys in the keytab.

Love

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 17 Jun 2009 16:51:27 -0500

> >implementations do not use that server name in the normal rd-req path.

You're right, though if the AP exchange happens over some other
channel...  But yes, it's mostly pointless to hide the server name.

> are 100+ keys in the keytab.

Note that STARTTLS doesn't protect the server name either in the AP-REQ,
for the obvious and simple reason that STARTTLS is not used in AP
exchanges.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Martin Rex <[email-masked]>
Date: Thu, 18 Jun 2009 01:32:20 +0200 (MEST)

> for the obvious and simple reason that STARTTLS is not used in AP

If the server name was hidden on AP-REQ, then the server would not be
able to give a useful hint "wrong server name in request" for
fairly-easy-to-commit configuration errors.

For the majority of kerberos clients, which blindly derive the
server name from the network endpoint address, such hiding would
not buy you much anyway...

-Martin