Subject: KDC StartTLS vs. FAST Armor analysis

From: Nicolas Williams <[email-masked]>
Date: Wed, 18 Apr 2007 10:11:59 -0500

Below is my analysis of KDC StartTLS (Simon's proposal) vs. FAST Armor
(Larry's and Sam' proposal).

Comments?

Points of comparison:

a) KDC authentication options
b) Client principal authentication options
c) Privacy protection for client principal name/realm and what not
d) Privacy protection for service principal name and what not against
   passive attackers
e) PFS
f) Extensibility
g) Round-trip count
h) Channel binding
i) Misc. issues

a) KDC authentication options

   STARTTLS:

    - TLS server cert
    - PSK (like normal Kerberos V, but with PFS)
    - Future TLS options
    - Kerberos pre-auth
       - PA-ENC-TIMESTAMP
       - PKINIT server cert

   Armor:

    - Armored PA-ENC-TIMESTAMP (or replacement) protected by PKINIT w/
      server cert
    - Armored PA-ENC-TIMESTAMP (or replacement) protected by PKINIT w/
      unauthenticated DH

   Conclusion:

    - Neither approach seems better on this score.

b) Client principal authentication options

   STARTTLS

    - TLS client cert (no privacy protection though)
    - PSK (like normal Kerberos V, but with PFS)
    - Future TLS options
    - Kerberos pre-auth
       - PA-ENC-TIMESTAMP
       - PKINIT client cert
       - OTP?

   Armor:

    - PKINIT client cert (not privacy protected)
    - PKINIT client cert (privacy protected, extra round-trips)
    - PA-ENC-TIMESTAMP (privacy protected)
    - OTP? (privacy protected)

   Conclusion:

    - Armor is better here if we care about privacy protection.

c) Privacy protection for client principal name/realm and what not

   STARTTLS:

    - Yes, provided that TLS not used to authenticate client principal
      name in any way
    - But then TLS can't be used for client authentication unless we add
      STARTTLS nesting

   Armor:

    - Yes
    - However, unless armor is extended to support privacy protection
      for the entire KDC-REQ/REP-BODY then STARTTLS provides better
      privacy protection for the KDC exchanges themselves.

   Conclusion:

    - Armor is better on this score.

d) Privacy protection for service principal name and what not against
   passive attackers

   STARTTLS:

    - Yes: use anon DH TLS cipher suites
    - But then TLS can't be used for KDC authentication unless we add
      STARTTLS nesting

   Armor:

    - Yes: use anon PKINIT outside

   Same caveats as in (c).

   Conclusion:

    - Armor is better on this score.

e) PFS

   STARTTLS:

    - Yes, provided that cipher suites that provide PFS are used

   Armor:

    - Yes, provided PKINIT ticket used for armor

f) Extensibility

   STARTTLS:

    - We benefit from all future TLS extensions, but unless any are
      added that include privacy protection for TLS authentication then
      we get privacy protection only when STARTTLS is not used for
      authentication or if we add STARTTLS nesting.

   Armor:

    - We get only Kerberos V extensibility, plenty, that, and we get
      privacy protection for all inner pre-auth, but we have to specify
      as armor-only pre-auth any authentication mechanism that we wish
      to be available in Kerberos V + Armor.

   Conclusion:

    - TLS is probably better on this score, but this seems rather
      subjective.

g) Round-trip count

   STARTTLS:

    - One round-trip for TCP extension negotiation *
    - Two round-trips for TLS hello/handshake/finished messages
    - As many round-trips as needed for inner pre-auth

    * optional

   Armor:

    - One-round-trip for KDC exchange for ticket armor **
    - As many round-trips as needed for inner pre-auth

    ** possibly more, if there are errors in outer exchange or if AS and
       TGS exchanges are used to get the outer ticket, or if
       multi-round-trip pre-auth is used

   Conclusion:

    - Armor is better on this score.

h) Channel binding

   Both STARTTLS and Armor can provide channel bindings for inner
   pre-auth.  Neither is better on this score: both require development
   of inner pre-auth that supports channel binding.

i) Misc. issues

    - Implementation complexity

      Here Armor wins hands down if PKINIT is a required-to-implement
      element of Kerberos V, else STARTTLS wins hands down if
      implementors can use an off-the-shelf TLS implementation.

      In practice the situation is murkier since there are Kerberos V
      implementors who lack a suitable PKINIT implementation, Kerberos V
      implementors who lack a suitable TLS implementation, and
      implementors who lack both.

      We can probably not consider implementation complexity and be fair
      to all participants.

    - Protocol complexity

      PKINIT is probably the more difficult protocol to understand
      simply because it is fairly recent, while TLS is simpler to
      understand in part because of it has been around longer.

      Armor is effectively a simple tunnel protocol.  So is STARTTLS.

      Conclusion: inconclusive :)

Conclusion
----------

Unless I've missed any points of comparison the two options are roughly
equivalent in functionality, and roughly equivalent on all other points,
except that in optimistic cases Armor should require two round-trips
fewer than STARTTLS, but the exact count depends on negotiations, and
specific client requirements for privacy and authentication options.

There are no obvious technical reasons for choosing one proposal over
the other, but overall Armor obtains more features (e.g., privacy
protection) with fewer round-trips.

Personal Opinion
----------------

My own position has been that the KDC messages and pre-authentication
should be decoupled, with the KDC messages protected as in any other
security application.  Both proposed solutions amount to a hackish
version of what I would prefer to see, though only when channel binding
of remaining pre-authentication is added into the mix.  IIRC Sam has
proposed making Armor pre-auth first-class Kerberos V KDC PDUs, which
would come closest to my proposal.

I've not made up my mind yet as to which approach to support.  I would
prefer that we have only one REQUIRED to implement approach but would
not mind both being on the Standards Track (though one approach as
Informational and the other as Standards-Track seems more likely).

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 18 Apr 2007 15:04:37 -0700

The armor scheme does NOT always require PKINIT. PKINIT is required only
when you do not have a host key.

It is straightforward to support IAKERB with the armor scheme. Can you
compile that into your list?

In addition, here are additional benefits for the armor scheme.

1) The armor scheme is a native Kerberos solution. This is important for
vendors who may not be able to ship a TLS implementation together with
the Kerberos implementation. You have touched based on this in your
sections for the misc issues.

2) The armor scheme is work-conservative. When one DC is down, the armor
TGT can be presented to another DC. With the start-TLS approach, the
client is likely to re-establish a new session.

3) The TLS scheme is state-ful, the server need to keep the states for
fast connection resumption. Implementation experience for the new ticket
based TLS is limited.

4) The armor scheme supports the use of RAW asymmetric keys, but TLS
requires x.509 certificates, hence the former is more general.

Furthermore, the armor scheme helps us to bootstrap to support I18N and
extensible messages in Kerberos, while start-TLS is unlikely to help
there.
--larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Wednesday, April 18, 2007 8:12 AM
To: [email-masked]
Subject: KDC StartTLS vs. FAST Armor analysis

Comments?

Points of comparison:

   STARTTLS:

    - TLS server cert

   Armor:

   Conclusion:

   STARTTLS

   Armor:

   Conclusion:

   STARTTLS:

   Armor:

    - Yes

   Conclusion:

   STARTTLS:

   Armor:

   Same caveats as in (c).

   Conclusion:

e) PFS

   STARTTLS:

   Armor:

f) Extensibility

   STARTTLS:

   Armor:

   Conclusion:

g) Round-trip count

   STARTTLS:

    * optional

   Armor:

   Conclusion:

h) Channel binding

i) Misc. issues

    - Protocol complexity

Conclusion
----------

Personal Opinion
----------------

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 18 Apr 2007 17:14:54 -0500

> compile that into your list?

Well, yes, that's true, but since IAKERB is not yet specified I don't
think that's an entirely fair point.

> sections for the misc issues.

I did.

> client is likely to re-establish a new session.

Good point.  Unless one is using anon-anon TGTs, see privacy protection
for client and server (for the latter privacy protection is only against
passive attackers).  But I don't think privacy protection of the server
name is an issue, so you point stands.

> fast connection resumption. Implementation experience for the new ticket

No it doesn't.  Server-side state is optional, and there's an option
for client-side state as well.

> requires x.509 certificates, hence the former is more general.

Again, not so (TLS has a PSK scheme, with and without PSK).

> extensible messages in Kerberos, while start-TLS is unlikely to help

Ah, now *that* is an excellent point.  At first glance I find this
argument sufficiently strong to make me prefer Armor over StartTLS.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 18 Apr 2007 17:19:15 -0500

> Again, not so (TLS has a PSK scheme, with and without PSK).
                                                        ^^^
							PFS

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 18 Apr 2007 17:08:01 -0500

> when you do not have a host key.

Sorry, I didn't mean to imply that.  PKINIT is required in order to have
a fair comparison of Armor to StartTLS, it isn't required per se.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 18 Apr 2007 15:23:07 -0700

It is unclear to me how to raw asymmetric keys are supported via
PSK-TLS.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Wednesday, April 18, 2007 3:19 PM
To: Liqiang(Larry) Zhu; [email-masked]
Subject: Re: KDC StartTLS vs. FAST Armor analysis

                                                        ^^^
							PFS

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 18 Apr 2007 15:25:06 -0700

Once you do not keep the states, the performance will suffer when the
client needs to connect to the KDC more than once.

--larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Wednesday, April 18, 2007 3:15 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: KDC StartTLS vs. FAST Armor analysis

I did.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 18 Apr 2007 17:34:44 -0500

> It is unclear to me how to raw asymmetric keys are supported via

Ugh.  I didn't see that 'a' -- I read 'symmetric'.

Yeah, I don't see how to use public keys for authentication w/o
certificates in TLS, but you can always self-sign a cert.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 18 Apr 2007 18:35:41 -0400

Unfortunately you've missed some common TLS usage.  If you want to use
TLS authentication and provide privacy protection for the client, you
do a TLS exchange with no client info, then you immediately after the
finish messages do another tls handshake and include the client info.
So, with TLS, you can trade more round trips for more privacy.

Looking at this comparison, I'm still a fan of armour.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 18 Apr 2007 17:35:49 -0500

> client needs to connect to the KDC more than once.

StartTLS could require support for client-side state-keeping (RFC4507).

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 18 Apr 2007 15:39:50 -0700

I referred to RFC4507 as the ticket based TLS. I argued in my initial
response that the implementation experience for RFC4507 is limited. In
other words, it is not exactly an off-the shelf solution.

--larry

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 18 Apr 2007 17:50:27 -0500

> So, with TLS, you can trade more round trips for more privacy.

No, I think I included that: "...unless we add STARTTLS nesting"

> Looking at this comparison, I'm still a fan of armour.

Larry makes a very strong argument for it.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 18 Apr 2007 19:21:13 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Apr 18, 2007 at 06:35:41PM -0400, Sam Hartman
    Nicolas> wrote:
    >> Unfortunately you've missed some common TLS usage.  If you want
    >> to use TLS authentication and provide privacy protection for
    >> the client, you do a TLS exchange with no client info, then you
    >> immediately after the finish messages do another tls handshake
    >> and include the client info.  So, with TLS, you can trade more
    >> round trips for more privacy.

    Nicolas> No, I think I included that: "...unless we add STARTTLS
    Nicolas> nesting"

No, you don't need to nest.
You just have a handshake again.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 18 Apr 2007 18:24:12 -0500

> You just have a handshake again.

I see.  Thanks for that clarification.  So StartTLS w/ privacy
protection would be doable with generally no additional
specification/implementation effort, but with more round-trips.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Apr 2007 08:30:21 -0400

So, how do we make forwmard progress on this issue?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 26 Apr 2007 08:55:26 -0500

> So, how do we make forwmard progress on this issue?

First I'd like to know what room there is for having both.  Personally I
think only one should be required (but required by what spec?).

I'm inclined to think that FAST is better for the one reason that Larry
gave that I found convincing (that a native solution is more likely to
get krb5 issues like I18N right).

Nico
--