Subject: Re: [Ietf-krb-wg] start-tls status

From: Simon Josefsson <[email-masked]>
Date: Mon, 02 Mar 2009 12:38:45 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> --On Thursday, December 04, 2008 11:23:15 PM -0500 Jeffrey Hutzelman 
> <[email-masked]> wrote:
>
>> --On Thursday, December 04, 2008 01:11:55 PM -0600 Nicolas Williams
>> <[email-masked]> wrote:
>>
>>> On Thu, Dec 04, 2008 at 11:58:31AM -0500, Jeffrey Hutzelman wrote:
>>>> --On Wednesday, November 19, 2008 02:03:47 AM +0100 Simon Josefsson
>>>> <[email-masked]> wrote:
>>>> > Nicolas Williams <[email-masked]> writes:
>>>> >> I've not looked at STARTTLS in a while, but I'd like to see:
>>>> >>
>>>> >> 1) channel binding from pre-auth to the TLS channel;
>>>> >
>>>> > What's missing from section 3 below?
>>>> >
>>>> > http://tools.ietf.org/html/draft-josefsson-kerberos5-starttls-03#secti
>>>> > on-3
>>>>
>>>> Nico, can you answer this?
>>>
>>> Sorry I'd missed that reply.
>>>
>>>> Do you believe that section 3 is complete and sufficient?
>>>
>>> It's not complete, and possibly unnecessary.
>>
>> In fact, having looked at that section myself, I believe it is rather
>> underspecified.  It defines a padata type for carrying a channel binding,
>> but says nothing explicit about what channel should be described, or what
>> semantics should be applied.  It requires that every  TGS-REQ include
>> pa-channel-binding data, but does not specify what the KDC should do with
>> that data or how it should behave if the channel bindings do not match.
>> It  provides no way for a client to discover whether channel bindings
>> were  correct.
>>
>> It is possible to make seemingly reasonable guesses about much of that,
>> however, doing so would likely lead one to believe that some security is
>> gained by requiring clients to send pa-channel-binding with bindings to
>> the  TLS session and requiring KDC's to verify these bindings and return
>> an  error if they do not match.  That belief would be incorrect -- since
>> PA-DATA is not authenticated or bound to the rest of the KDC exchange in
>> any way, the channel binding data is essentially sent unprotected inside
>> the very channel it describes, and there is nothing to prevent an MITM
>> attacker from replacing this padata in transit with a value reflecting
>> the  channel he shares with the KDC.
>>
>> To be effective, channel bindings must be authenticated in some fashion.
>> For example, the preauth data might be signed or MAC'd in some fashion.
>>
>> Alternately, one might strengthen the reply key with key material derived
>> from the TLS session, as described in my last message.  However, I would
>> suggest examining this approach very carefully before deciding to use it,
>> as my recollection is that the TLS master secret does _not_ constitute a
>> unique channel binding and so using material derived from it to
>> strengthen  the reply key might not provide the desired protection.  It
>> would be  helpful if someone who's thought about this more carefully
>> would speak up.
>
>
> I've seen no movement in the last month on this, which I believe to be the 
> last outstanding issue before STARTTLS can move forward.  Can I have some 
> comments/discussion on this, please?

Having thought some more about this, I don't understand how a channel
binding would work in krb5starttls.  I may be missing something, so I
would appreciate if you or someone could try to explain the actual
problem before suggesting solutions.

The essential question seems to me be whether all user+server
authentication schemes provided by TLS (e.g., X509, OpenPGP, PSK, SRP)
are inherently tied to the TLS session between the user and the server?

The TLS Finished message is derived by both parties and verifies the TLS
handshake user authentication, and cannot be faked by a MITM.  The only
complication I see is TLS resumption, but I don't see how that breaks
the model.  There cannot be any MITM, or TLS is broken.

Thus, if the KDC wishes to use the user authentication provided by TLS
to pre-authenticate the Kerberos request, it just has to follow the TLS
protocol and then it knows the other end is the appropriate user.

A normal situation where channel bindings helps is where a client does
not verify the TLS server credentials.  For krb5starttls, the client
would then be tricked into tunneling the Kerberos V5 request via an
attacker and then to the KDC.  This situation is already covered by the
security considerations.  Further, if this poses a security problem, I
would say that sending the request over TCP has the same concern.

The reason for the pa-channel-binding in krb5starttls (as I understood
it) was not to bind the TLS session to the TLS user authentication
(which I argue is nonsensical).  It was to bind some _other_
pre-authentication request to the particular TLS channel.  That is the
reason the format and semantics is not defined, they cannot be until
this other pre-auth mechanism is specified.  I now believe this does not
belong in the krb5starttls document, but rather in this future pre-auth
mechanism document that specify how it wants to bind its authentication
to the TLS channel.

Nico said earlier that one reason for doing a channel binding in
krb5starttls is to avoid the need for clients to verify KDC
certificates, or perhaps rather, to make it possibly for clients to
learn the KDC certificate without knowing it.  This seems to require
modifications of the reply key.  However, this was not the design goal
of krb5starttls, and it makes the explicit design goals more complex.

However I do agree that Nico's use case is nice.  But, it is possible to
achieve separately from the krb5starttls document: just define a
pre-auth mechanism that indicates that the Kerberos reply key needs to
be modified using key material from the TLS channel.

Thus, I agree with Nico above that section 3 is unnecessary and propose
that it is removed.

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 02 Mar 2009 15:18:52 +0100

Dear WG,

I've updated the krb5starttls document to remove the incomplete section
on channel bindings:

http://www.ietf.org/internet-drafts/draft-josefsson-kerberos5-starttls-05.txt

To (hopefully) address the channel binding concern, and to describe the
advantages we get from using channel bindings together with
krb5starttls, I have written a new document.  See announcement below.

If you read the document below, I believe it will be clear that in some
cases it is not needed and the implementations will use pure
krb5starttls.  That is the reason why I believe channel bindings do not
necessarily have to be part of the core krb5starttls document.  And if
it doesn't _have_ to be part of the core krb5starttls document, I
believe it helps readability to remove it.  Occam's razor.

/Simon

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : Strengthening the Kerberos V5 Reply Key using TLS
> 	Author(s)       : S. Josefsson
> 	Filename        : draft-josefsson-krb5starttls-bootstrap-00.txt
> 	Pages           : 10
> 	Date            : 2009-03-02
>
> This document describes how to strengthen the Kerberos V5 reply key
> using keying material derived from TLS, by using a pre-authentication
> mechanism.  The goals are to 1) allow clients to securely learn a
> realm's KDC X.509 certificate, 2) distribute the X.509 trust anchors
> used by the KDC, and 3) make it possible for clients to use Kerberos
> V5 over TLS without having to validate the server certificates.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-krb5starttls-bootstrap-00.txt

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 10:24:11 -0600

> problem before suggesting solutions.

If one were using PA-ENC-TIMESTAMP over a StartTLS connection then one
should like to see PA-ENC-TIMESTAMP channel bound to StartTLS.

To do this I think you'd derive a session key from the client
principal's long-term key and the channel binding data.  And since
PA-ENC-TIMESTAMP doesn't have an explicit reply message, derive the
AS-REP reply key similarly.

> are inherently tied to the TLS session between the user and the server?

If you're using user authentication provided by TLS then you definitely
don't need channel binding.  That's because there's no authentication
mechanism above the channel to bind to the channel.

Instead you need a pre-auth method that says to use the underlying
channel for authentication, and you'll want thate pre-auth method to set
the reply enctype to the null enctype (since there will not be a key to
use for the reply!), or alternatively derive an AS-REP reply key from
the TLS PRF.

So what I'm expecting from the Kerberos StartTLS I-D is:

1) How to use PA-ENC-TIMESTAMP over StartTLS with TLS anon DH cipher
   suites and with channel binding from the former to the latter.

2) How to use TLS for user and AS authentication, particularly how to
   deal with the normal need for a AS-REP reply key.

See above.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 02 Mar 2009 22:02:09 +0100

> AS-REP reply key similarly.

What I am missing is a reason why this belongs in the krb5starttls
document.

None of the reasons motivating krb5starttls that are mentioned in the
document require a channel binding pre-auth mechanism like that, or do
they?

To me it sounds as if you are asking for a feature enhancement rather
than a bugfix.  Is that correct?

> mechanism above the channel to bind to the channel.

I agree.

> use for the reply!), or alternatively derive an AS-REP reply key from

Whoa, that definitely goes beyond the scope of krb5starttls.  The core
Kerberos V5 protocol is not modified by krb5starttls in this area.  The
reply key to use for the AS-REP is derived from the long term user
password, just like normal Kerberos V5.

The krb5starttls document should be compared to a Kerberos V5 over TCP
document.

>    suites and with channel binding from the former to the latter.

If you haven't seen it already, please read
draft-josefsson-krb5starttls-bootstrap-00.txt.  It attempts to solve one
actual use-case that may be the same use-case as the one you want to
solve here.  If the use cases are not the same, can you describe what
the use case for your 1) is?

>    deal with the normal need for a AS-REP reply key.

In what way isn't this already addressed?  The krb5starttls document
refers to RFC 4120 on this, which means it uses the user's long term
shared secret for deriving the AS-REP reply key.

Hm.  Possibly your use-case is to _only_ use the TLS channel for
authenticating the user to the KDC?  I can see how your pre-auth type
above would achieve this.  I think this could easily be described in the
krb5starttls-bootstrap document.  Do you see any reason why this
wouldn't work?

I am only guessing here.  I think it would help to mention the use cases
more explicitly.

Thanks,
/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 15:12:34 -0600

> What I am missing is a reason why this belongs in the krb5starttls

I suppose it doesn't, but IMO without it it'd be hard to argue for
putting krb5starttls on any standards track as FAST does deal with this.
OTOH, if what I'm asking for what just be in a separate document then
I'm OK with that.

> document require a channel binding pre-auth mechanism like that, or do

Perhaps not, but for me one useful aspect of StartTLS and FAST is the
ability to do anon-anon DH and channel-bound PA-ENC-TIMESTAMP.  It
allows for detection of MITMs and protects against eavesdroppers without
having to have a PKI for KDC certificates.  That's a significant
improvement over plain PA-ENC-TIMESTAMP with zero infrastructure impact.

> > mechanism above the channel to bind to the channel.

See below.

> password, just like normal Kerberos V5.

So then you're never using TLS user certs for client principal
authentication?

> the use case for your 1) is?

It does help with the reply key aspect of (1) (and (2) below), but I
think you also want to strengthen PA-ENC-TIMESTAMP.  Also, if the
principal has a long-term key then there's no need to use the TLS PRF as
you use it: better to use a krb5 prf keyed with the long-term key over
the TLS channel bindings.

> krb5starttls-bootstrap document.  Do you see any reason why this

Sure.

Nico

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 02 Mar 2009 16:44:04 -0500

> What I am missing is a reason why this belongs in the krb5starttls

The question is "what evidence does the client have that the TLS
connection was in fact established to the KDC and not to a MITM
which in turn established its own TLS connection to the KDC?"

The purpose of the channel binding is to assert that the guarantees
asserted by the establishment of the TLS connection do in fact apply
to the AS exchange.

Jeffrey Altman

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 00:26:03 +0100

> improvement over plain PA-ENC-TIMESTAMP with zero infrastructure

Right, but how is that different from what krb5starttls-bootstrap does?

> So then you're never using TLS user certs for client principal

Sure.  I don't see how that requires the reply key to be modified?  It
can still be derived from the user's long term user password.  That
provides two factor authentication (cert + password).

> think you also want to strengthen PA-ENC-TIMESTAMP.

Why?  I still don't follow your use case.

> Also, if the principal has a long-term key then there's no need to use
> the TLS PRF as you use it: better to use a krb5 prf keyed with the
> long-term key over the TLS channel bindings.

What advantage is there in that?

>> krb5starttls-bootstrap document.  Do you see any reason why this

Ok.  I am going to submit an updated version now.  I still don't see why
a modified PA-ENC-TIMESTAMP is required, as distinct from merely a bit
that states "hey derive reply key from only TLS".  However I think
seeing this documented will help discussion.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 00:30:12 +0100

> which in turn established its own TLS connection to the KDC?"

That is addressed by the document:

   Note that TLS does not protect against Man-In-The-Middle (MITM)
   attacks unless clients verify the KDC's credentials (X.509
   certificate, OpenPGP key, etc) correctly.

> asserted by the establishment of the TLS connection do in fact apply

If the client verifies the server credentials, I believe that assertion
holds without using channel binding.

/Simon

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 02 Mar 2009 18:39:35 -0500

> holds without using channel binding.
How does the client verify the server credentials?  Is there an
attribute in the certificate that states that this certificate belongs
to a KDC in the FOO.BAR realm?  Even if there were, how does the client
verify that the certificate wasn't just one made up by an attacker? 

I'm not saying that this is something that must be addressed by this
document.  The extension prevents attacks by passive attackers not
active attackers.  That is more than is currently provided today by the
use of raw TCP/IP.   However, without the channel binding the start-tls
extension for krb5 is weaker than FAST.  If you wish it to be as secure,
a channel binding is necessary.

Jeffrey Altman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Mar 2009 18:51:04 -0500

> holds without using channel binding.

No, they don't.  Without channel binding, the client has no guarantee that 
there is not a MITM which watched the entire AS exchange.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 00:55:18 +0100

> verify that the certificate wasn't just one made up by an attacker? 

The trusted server certificate can be be set up manually, or the client
can use the technique described in
draft-josefsson-krb5starttls-bootstrap-01.txt to use an existing long
term secret to setup trust in the server certificate.  I am sure there
are other mechanisms too.

> a channel binding is necessary.

This should be addressed by draft-josefsson-krb5starttls-bootstrap.

I don't see this is a something all implementations of krb5starttls will
want or need, though, thus the separation into two documents.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 00:58:24 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> No, they don't.  Without channel binding, the client has no guarantee
> that there is not a MITM which watched the entire AS exchange.

I don't follow.  The client connects to a KDC.  It verifies that the
presented X.509 server certificate belongs to the KDC he wants to talk
to.  It verify that the other end knows the private key belonging to
that certificate using the TLS protocol.  How is there a man in the
middle here?

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 17:52:21 -0600

> Right, but how is that different from what krb5starttls-bootstrap does?

krb5starttls-bootstrap doesn't talk about PA-ENC-TIMESTAMP.  As I've
said, I don't mind two docs, with krb5starttls-bootstrap being the one
that explains how to do PA-ENC-TIMESTAMP with channel binding to TLS.

> provides two factor authentication (cert + password).

But you might want user certs only and no passwords, then what?  You'd
still need server certs in that case (as without a password you'd need
something else to authenticate the KDC with).

IIRC you're implementing StartTLS but not PKINIT, but surely you see
value in some of the use cases of PKINIT.

> Why?  I still don't follow your use case.

PA-ENC-TIMESTAMP over TLS w/o certs (anon cipher suites).  You want to
detect MITMs, and channel binding does that.

> What advantage is there in that?

You don't need to have an implementation of TLS that provides the PRF
extractor.

> seeing this documented will help discussion.

Hmmm, actually, if all you do is derive the reply key from the client
principal's long-term and the TLS channel binding then that should be
enough (you can't detect the MITM until there's a response and you must
interpret timeout as an MITM; having bound the PA-ENC-TIMESTAMP itself
to the channel does not protect you from the MITM, and you need a valid
AS-REP to decide that there was no MITM).

But "hey derive reply key from only TLS" would be bad.

Nico

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 02 Mar 2009 19:07:11 -0500

> want or need, though, thus the separation into two documents.
Ugh.  I would not assume the end user can store this information
securely on the local machine.  Every client is going to have to perform
the bootstrap exchange and then request the ticket.  This is much more
expensive than just defining new PA-TIMESTAMP-TLS and simply using that
for all requests over the TLS protected channel.  Which is what Nico was
recommending.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 18:06:21 -0600

> want or need, though, thus the separation into two documents.

That's not necessarily a good reason to separate into two documents.
You could do both in one document and specify what modes are REQUIRED to
implement.  Not that I'm against two documents -- I'm just clarifying.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 18:12:23 -0600

I agree.

Whether one uses StartTLS or FAST, the following are the useful modes:

1) Modes not requiring a PKI for authenticating the server (meaning that
   trust anchors need not be distributed, etc...):

   a) PA-ENC-TIMESTAMP bound to an anon-anon DH channel;

   b) client cert + PA-ENC-TIMESTAMP bound to a channel where the server
   is not authenticated.

2) Modes requiring a PKI for authenticating the server:

   a) PA-ENC-TIMESTAMP, whether channel bound or whether the server cert
      is matched to the client principal's realm by name matching rules
   b) client cert

Modes (1a) and (1b) are easier to deploy than modes (2a) and (2b): it's
just software.  Even for mode (2a) channel binding is simpler because
you can "learn" server certs dynamically (but be careful: what is
learned under one user cannot be used when doing an AS exchange for
another).

Nico

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 01:24:50 +0100

> that explains how to do PA-ENC-TIMESTAMP with channel binding to TLS.

My point is that I believe krb5starttls-bootstrap-00 achieves what you
describe above _without_ using PA-ENC-TIMESTAMP.

> value in some of the use cases of PKINIT.

I do, but it seems beyond the scope of the krb5starttls document to me.
I think we now agree that this can be separated.

> detect MITMs, and channel binding does that.

Sure, but using the TLS PRF and combining the long term shared secret
and a channel binding achieves the same thing.  That is what
krb5starttls-bootstrap-00 (and -01) does.

> You don't need to have an implementation of TLS that provides the PRF

Ok, worth considering.  Since bootstrap-01 now also discuss situations
where the principal doesn't have a long term key, it seems the TLS PRF
is required anyway, it seems simpler to use the same function.

> But "hey derive reply key from only TLS" would be bad.

I meant a signal "hey derive reply from TLS + CB".  Do you see any
problem with that?  I don't see what PA-ENC-TIMESTAMP offers that the
simpler signal doesn't.  The KDC will notice a MITM earlier with
PA-ENC-TIMESTAMP, but both sides will notice it eventually.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 01:32:38 +0100

> implement.  Not that I'm against two documents -- I'm just clarifying.

Agreed.

Given that the krb5starttls document has been essentially the same for
over 4 years, my hope is that unless this channel binding stuff really
MUST be in the core document it will help to move the core document
along in the IETF process faster if the channel binding stuff is in a
separate document.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 01:37:44 +0100

Jeffrey Altman <[email-masked]> writes:

> securely on the local machine.

It doesn't have to.

> Every client is going to have to perform the bootstrap exchange and
> then request the ticket.  This is much more expensive than just
> defining new PA-TIMESTAMP-TLS and simply using that for all requests
> over the TLS protected channel.  Which is what Nico was recommending.

The pa-krb5starttls-bootstrap (or pa-krb5starttls-strengthen) exchange
seems cheaper to me than the PA-ENC-TIMESTAMP/PA-TIMESTAMP-TLS approach.
You save the round-trip of a KRB-ERROR and the cost of encrypting the
PA-ENC-TIMESTAMP.  And you still need to derive a reply key with the
PA-ENC-TIMESTAMP approach, don't you?  There is no null encryption in
Kerberos V5.

/Simon

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 2 Mar 2009 17:24:08 -0800

> PA-ENC-TIMESTAMP, but both sides will notice it eventually.

I think this exchange discusses a distinction without a difference.   
IIUC the easiest way to encapsulate the "hey derive reply key from  
only TLS" bit would be to define a new PA mech identical to PA-ENC- 
TIMESTAMP except for how the reply key is generated.

If you're concerned about the round trip for the KDC to tell the  
client the new PA is desired I don't think that's a concern.  I would  
expect that clients capable of the new PA mech would heuristically try  
it first if they have an appropriate TLS session to the KDC  
available.  Any client that tries an inappropriate PA mech in an  
AS_REQ needs to get the list of supported mech's back regardless of  
what they started with.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Mar 2009 19:46:44 -0600

> describe above _without_ using PA-ENC-TIMESTAMP.

I'll re-read it, but my first impression was that it does not do what I
want.

> I think we now agree that this can be separated.

"Can" be, not "must" be.

> is required anyway, it seems simpler to use the same function.

I think that's a crucial advantage.

> PA-ENC-TIMESTAMP, but both sides will notice it eventually.

This only works if you have server certs.  That's what I'm arguing the
protocol should NOT require -- server certs are nice, they help a lot,
but it'd be nice not to require them.  If you don't have server certs
then you need to make the reply key based on the client's long-term key
and the channel binding.  Also, you don't need the PRF.  And in the
server certs + user certs case you don't need a reply key -- you could
use the null enctype.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 2 Mar 2009 23:20:45 -0800

> server certs + user certs case you don't need a reply key -- you could

I think I agree with you Nico, but somewhere there was a claim that  
this draft describes some actual deployed stuff.  Could I ask the  
group (Simon?) how these issues are dealt with (or not) in what was  
deployed?
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 13:10:44 +0100

> I'll re-read it, but my first impression was that it does not do what I

Please check it.  I believe we either misunderstand each other, or there
is something in your use-case that you didn't explain.

However I agree with Henry that there isn't a substantial difference
here: a PA-ENC-TIMESTAMP would achieve the same thing, but it seems it
would take more time to do.  What I am trying to understand is whether
that slowdown can be motivated by some advantage.

Agreed.

> I think that's a crucial advantage.

It may be if someone is planning on implementing this using a TLS
library that does not expose the PRF but can export the TLS Finished
messages _and_ with a Kerberos V5 implementation that exposes the
Kerberos V5 PRF.

> and the channel binding.

I believe that is exactly what krb5starttls-bootstrap achieves,
_without_ requiring server certs or a PA-ENC-TIMESTAMP.  Please read it
and explain where you think our disagreement is.

> Also, you don't need the PRF.  And in the server certs + user certs
> case you don't need a reply key -- you could use the null enctype.

There is no null enctype in Kerberos V5.  I recall a null enctype was
discussed when RFC 3961 was written, and IIRC one problem was which
checksum type would be associated with the null enctype and how that
interacts with what checksumtype the client selects when talking to
other systems.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 13:25:12 +0100

> group (Simon?) how these issues are dealt with (or not) in what was

The deployed protocol is krb5starttls and the implementation requires
server certs.  This new document, krb5starttls-bootstrap, describes
techniques that aren't even implemented.  The new work goes beyond what
krb5starttls was originally designed for.  I think it adds complexity to
the discussion around the core krb5starttls document to mix these two
together.  It seems clear that the ideas around krb5starttls-bootstrap
can be built on top of the existing krb5starttls.

Another reason to keep these separate is that the mechanisms in
krb5starttls-bootstrap aren't the only way to achieve these goals by
using krb5starttls.  They can be implemented in many ways (which is
shown by the discussion about PA-ENC-TIMESTAMP vs other approaches), and
some may not be as good as others.  By coupling together krb5starttls
with the krb5starttls-bootstrap work the interface between the two parts
becomes blurred and, in my opinion, the architecture becomes less
elegant.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 13:29:30 +0100

> TIMESTAMP except for how the reply key is generated.

I agree a new pre-auth type seems better than overloading the
PA-ENC-TIMESTAMP timestamp.  I'll try to make this change in a
krb5starttls-bootstrap-02 document.

Or are there any reasons for overloading the PA-ENC-TIMESTAMP pre-auth
type with a new meaning when used under TLS?  I don't see it, but there
may be.

> AS_REQ needs to get the list of supported mech's back regardless of

Good point.  With a separate pre-auth mechanism the client can supply it
directly as well, if it wants to, without having to wait for the KDC to
respond with KDC_ERR_PREAUTH_FAILED.  So this will be better.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Mar 2009 09:21:20 -0500

Simon, I agree with a number of points you've made over the last day:

1) We should do what we can to avoid additional delays on the starttls document: that should be a significant goal in how we approach this.

2) I think that starttls without channel binding has value.
3) I think that the documents can be separated.

4) If you verify server certificates, and have appropriate
    authorization checks--is Bob permitted to be a KDC--then channel
    binding is not required.  I'd like to hear Jeff Hutzelman's
    explanation of why you and I are wrong about this point, but I
    have high confidence that you are right.

As such, your general approach seems fine.

I'd like to note a couple of things.  These are not disagreements,
just things to think about.

1) There may be some value to a facility to influence the reply key
   from the TLS exchange regardless of any other channel bindingish
   stuff.  For example, if the KDC using FAST chooses to replace the
   reply key, then an attacker cannot successfully trim the FAST
   message from the response (although they can of course trim it from
   the request).  If the client could demand that a KDC do that, then
   the client could protect against attackers that can trim a FAST
   response but not a FAST request.  There may be similar issues in
   starttls, although the model is different because the client knows
   that this session will be using TLS before the request is
   constructed.  Obviously, since there is no client facility to
   demand that the KDC replace the reply key, we've decided that
   attack is not critical to defend against in FAST.  I can't really
   think of a compelling argument that these class of attacks are
   important.  However they are sufficient to convince me that there
   are differences between introducing channel binding at the
   beginning and later.  We may some day find this distinction important.

2) It is typical in IETF protocols to specify mandatory-to-implement
   checks for certificates.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 16:04:30 +0100

> As such, your general approach seems fine.

Great, I agree.

>    stuff.

Right.

However when deriving the reply key from the TLS exchange (using
e.g. tls-extractor draft) it seems that adding some channel binding data
is cheap and does not preclude any use-case that I can see.  The client
TLS Finished message will always be available on both sides, so why not
add it.  Having the channel binding data be combined with the long term
key enables several interesting use-case so it cannot be removed without
loss of functionality.

However, specifying a pre-auth type that strengthens the reply key
without adding in a channel binding will be possible in the future so I
am comfortable this can be addressed if a need develops.

>    For example, if the KDC using FAST chooses to replace the

Yes, although I also fail to identify a concrete attack here.

The difference has been discussed already: the PA-ENC-TIMESTAMP approach
introduce a channel binding early (in the request), whereas my initial
pa-krb5starttls-strengthen idea introduce a channel binding later (in
the response).

For krb5starttls, the situation to think about seems to be restricted to
when the client doesn't check server certificates, i.e., the tls dh anon
mode.  However, here the long term shared secret secure the exchange, so
I don't see how this could be more insecure than over TCP [unless the
TLS PRF is broken and destroys the entropy provided by the long term
key].  If the client checks server certificates properly, a channel
binding isn't necessary.

> 2) It is typical in IETF protocols to specify mandatory-to-implement

Could you point to some documents for inspiration?  I'm not sure exactly
what you are looking for here.  SASL over TLS doesn't specify any checks
like that, if I recall correctly.

I'm not sure if anything beyond manual configuration of the server
certificate in clients, or automatic discovery using the
krb5starttls-bootstrap protocol, could be recommended.  I would feel
uncomfortable making clients trust that it is talking to the proper KDC
based on server name checking and that the server cert chains back to a
(by the client) trusted CA.  Both DNS and commercial PKIs are too
fragile.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Mar 2009 11:12:53 -0500

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    >> 2) It is typical in IETF protocols to specify
    >> mandatory-to-implement checks for certificates.

    Simon> Could you point to some documents for inspiration?  I'm not
    Simon> sure exactly what you are looking for here.  SASL over TLS
    Simon> doesn't specify any checks like that, if I recall
    Simon> correctly.

Sure RFc 4556 tells you how to determine if a given certificate is a
valid KDC certificate.  SASL over TLS in general does not do this, but
for example the TLS LDAP binding, the TLS XMPP binding all tell you
how to determine whether a particular certificate matches the service
you're talking to.  Contrast this with the DTLS CAPWAP binding for an
example where we'vve still discussed the issue but have been a bit
more loose in how we specify things.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Mar 2009 10:16:39 -0600

On Tue, Mar 03, 2009 at 01:25:12PM +0100, Simon Josefsson wrote:
> server certs.  [...]

But how are server certs validated?

My guess: they must be pre-shared.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 11:26:08 -0500

--On Tuesday, March 03, 2009 09:21:20 AM -0500 Sam Hartman 
<[email-masked]> wrote:

> 1) We should do what we can to avoid additional delays on the starttls
> document: that should be a significant goal in how we approach this.
>

I agree on all of these points.  With regard to point 4, my previous 
comments were specifically about the case where the client does not verify 
the KDC's certificate, in which case some form of CB is needed to avoid 
MITM attacks.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Mar 2009 10:19:14 -0600

> messages _and_ with a Kerberos V5 implementation that exposes the

The last part is wrong -- the krb5 start-tls implementor is necessarily
the krb5 implementor, therefore there's no need to "expose" a krb5 PRF.

> interacts with what checksumtype the client selects when talking to

There was a null enctype, and though it's been removed it could be
revived if there was a use for it, which there is.  If you need to add
a constant-checksum type to go with the null enctype, then do that.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 17:39:04 +0100

> My guess: they must be pre-shared.

That is right.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 17:52:00 +0100

> the krb5 implementor, therefore there's no need to "expose" a krb5 PRF.

True.

On the other hand, there is no single krb5 PRF.  Each enctype defines
its own.  Further, there is no process defined to add a new Kerberos key
usage numbers.  This complicates writing the actual text, and I am a bit
lost on how to do this.  Text suggestions welcome.

> a constant-checksum type to go with the null enctype, then do that.

I think it works fine without doing that.

The null enctype was apparently intentionally removed, although the
complete discussion motivating the change were not public.  See earlier
discussion:

http://thread.gmane.org/gmane.ietf.krb-wg/1849

Possibly the reasons for not defining a null enctype back then are still
valid.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 12:04:16 -0500

>> My guess: they must be pre-shared.

Yeah, that's not so great.  The client should validate the KDC's 
certificate using rules substantially similar to those described in RFC4556 
section 3.2.4.  In fact, I suspect the only difference between those rules 
and what krb5starttls should do lie in the required key usage (not EKU). 
In PKINIT, the KDC's cert must have the digitalSignature key usage bit; in 
krb5starttls, the required usage bits will be dictated by TLS and by the 
particular cipher suite in use.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Mar 2009 11:04:56 -0600

> On the other hand, there is no single krb5 PRF.  Each enctype defines

Actually, there is no krb5 PRF as such, not in RFC3961.  But we don't
necessarily need one as the channel binding operation doesn't have to be
particularly strong: it just has to be not cryptanalyzable in real-time.
So HMAC(would-be-reply-key, TLS channel binding) + truncation/padding
would suffice.

> lost on how to do this.  Text suggestions welcome.

There is also RFC4402, and while that's in the context of the krb5 GSS
mech, it's still useful.  I'll look at writing text.  I may well just
punt.

> Possibly the reasons for not defining a null enctype back then are still

RFC1510 has a null enctype.  It was removed in RFC4120 because there was
no use for it.  If a use for it appears then it can be re-added, with
suitable warnings that it's very use-specific.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 12:15:18 -0500

> lost on how to do this.  Text suggestions welcome.

There is a PRF in the RFC3961 abstraction.  The particulars are, of course, 
dependent on which enctype is used, but the interface is always the same. 
In this case, if you're talking about using the krb5 PRF keyed by the 
principal's long-term key, then the particular function to use is implied 
by the enctype of that key.

There is a process defined to add key usage numbers, in RFC4120 section 9. 
Specifically, that namespace is managed by this working group, which means 
new numbers can be assigned by consensus of this WG.  Ask Tom Yu for an 
unused number and put that in your document, but be aware that the number 
is not really "assigned" until the WG approves the document.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Mar 2009 11:17:17 -0600

> There is a PRF in the RFC3961 abstraction.  The particulars are, of course, 

Ah, yes, somehow I didn't see it just now, I searched too quickly, for
the wrong term.  Excuse me.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Mar 2009 11:19:00 -0600

> particular cipher suite in use.

+1

The good news is that the text in start-tls about server cert validation
can be mostly a reference to PKINIT.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 12:32:03 -0500

--On Tuesday, March 03, 2009 11:04:56 AM -0600 Nicolas Williams 
<[email-masked]> wrote:

> Actually, there is no krb5 PRF as such, not in RFC3961.

You mean, other than the one described as part of the enctype profile about 
halfway down page 8 of RFC3961.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Mar 2009 12:33:42 -0500

I strongly prefer that the null enctype not be used or re-introduced
and that we use the prf of the enctype associated with the reply key.

Note that for the PRF you actually don't need a key usage number.  For
some things you do need a key usage number.  I'd recommend asking Tom
for assignments and including something similar to section 7 of the
pre-auth framework draft.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Mar 2009 11:32:47 -0600

> halfway down page 8 of RFC3961.

I know I just embarrassed myself, but, do we need *two* replies from the
same person pointing it out?  :)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 20:19:43 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> certificate using rules substantially similar to those described in
> RFC4556 section 3.2.4.  In fact, I suspect the only difference between
> those rules and what krb5starttls should do lie in the required key
> usage (not EKU). In PKINIT, the KDC's cert must have the
> digitalSignature key usage bit; in krb5starttls, the required usage
> bits will be dictated by TLS and by the particular cipher suite in
> use.

Thanks for these ideas.  This may actually be something that belongs in
the core krb5starttls document, although I am not certain.  I have
written a section that could be added.  Comments?  If I don't hear
anything, I'll post an update that includes the following text.

/Simon

5.  Validation of Server Certificate

   The TLS protocol can provide server authentication.  By validating
   the server certificate, the client can be certain that it is talking
   to the intended KDC.  The Kerberos V5 STARTTLS protocol does not
   require server certificate validation for all situations.  However,
   it can sometimes be useful and this section provides guidelines for
   how to implement it.  It is expected that other documents will extend
   these rules to accomodate special use cases.

   To validate the server certificate, the client MAY use local
   configuration (e.g., a copy of the server's certificate) and compare
   that with the authentication information provided from the server via
   TLS.  For illustration, the server certificate could be a X.509
   certificate or an OpenPGP key.

   When X.509 server authentication is used, there is an alternative way
   to validate server credentials that MAY be used.  The client is pre-
   configured with a set of trusted CA certificates.  The KDC server
   certificate MUST then be validated as described in [RFC5280].
   Further, the client MUST check that the server certificate contains a
   Subject Alternative Name (SAN) that binds the the server certificate
   to the intended Kerberos realm and for the purpose of using the
   Kerberos V5 STARTTLS extension.  For this purpose, we define a
   otherName SAN identified using a type-id of id-krb5starttls-san.  The
   value field should contain the Realm of the KDC, which is a
   KerberosString type.

          id-krb5starttls-san OBJECT IDENTIFIER ::=
            { iso(1) identified-organization(3) dod(6) internet(1)
              private(4) enterprise(1) gnu(11591)
              shishi(6) krb5starttls-san(1) }

   The TLS cipher suite used dictate the required key usage bits in the
   server certificate, this protocol does not specify any additional
   checking.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 14:29:56 -0500

> anything, I'll post an update that includes the following text.

- Don't make server cert validation optional.  It should be REQUIRED;
  we can have other documents that allow validation to be skipped when
  a particular alternate mechanism such as CB is used.  Of course, it
  is fine to use a preconfigured cert.

- Don't say "the client is pre-configured with a set of trusted CA
  certificates".  There is nothing that requires the client's trust
  anchors to be represented as certificates.  Simply referring to the
  validation process described in RFC5280 is quite sufficient.

- Don't make up a new SAN; use the one defined in PKINIT.  This is not
  a differnet type of name than that one.

- Do require the presence of the PKINIT KDC EKU, lacking specific client
  configuration to the contrary, in the same way that PKINIT does.  This
  is essential to prevent people using web server certs to impersonate
  a KDC.

- I don't think you need to say anything specific about key usage; not
  even "TLS dictates...".  That should be obvious to the TLS implementor,
  and restating it here suggests that other things dictated by TLS can be
  ignored.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 21:07:19 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> You mean, other than the one described as part of the enctype profile
> about halfway down page 8 of RFC3961.

> and that we use the prf of the enctype associated with the reply key.

Looking closer at what the Kerberos V5 pseudo-random function, for,
e.g. aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96 actually does
doesn't inspire much confidence to me.  The pseudo-random definition is:

   pseudo-random (protocol-key, octet-string)->(octet-string)
      This pseudo-random function should generate an octet string of
      some size that is independent of the octet string input.  The PRF
      output string should be suitable for use in key generation, even
      if the octet string input is public.  It should not reveal the
      input key, even if the output is made public.

Reading the description of the enctypes defined in RFC 3961, it seems
"some size" is a fixed length rather than a variable length.

Thus, the first problem is that the pseudo-random function would only
work if its output size from the pseudo-random function is the same as
the key size.

Reading more about how the pseudo-random is defined I see:

pseudo-random function    tmp1 = H(octet-string)
                          tmp2 = truncate tmp1 to multiple of m
                          PRF = E(DK(protocol-key, prfconstant),
                                  tmp2, initial-cipher-state)

For aes128-cts-hmac-sha1-96 m is 1 according to RFC 3962.  Thus it seems
the pseudo-random function hashes the input, takes the first byte of the
hash, and encrypts that.  I note that this loses most of the entropy in
the input.

Given that tmp2 is a 1 byte message, the output will be one block large.
The block size of AES is 128 bits.  So for aes128-cts-hmac-sha1-96 the
output happens to be the same size as the key, and it works.  However,
if the long term shared key uses an enctype of aes256-cts-hmac-sha1-96
the pseudo-random function will not generate enough keying material.

Thus, my conclusions is that I don't think the krb5 "pseudo-random"
function is useful here.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 15:25:31 -0500

> "some size" is a fixed length rather than a variable length.

Correct.  If you need something longer, you need to use a PRF+ construct. 
This is a fairly well-understood approach.  See, for example, section 6.1 
of draft-ietf-krb-wg-preauth-framework-09.txt

>                                   tmp2, initial-cipher-state)

That's the definition for enctypes using the simplified profile.  The AES 
enctypes do fall into that category, but other enctypes might not.

> hash, and encrypts that.  I note that this loses most of the entropy in

Ah, except that the input in question has no entropy to begin with -- the 
entropy comes from the key.  The input string is nearly always a constant; 
it's used to allow an upper-layer protocol to use the PRF multiple times 
with the same key and get different answers; in other words, it performs a 
function similar to that of a key usage.

Though in retrospect, using m here was probably a mistake, as it 
significantly limits the number of distinct PRF blocks that can be derived 
from a given input key.  We probably should have said something like "a 
multiple of m, but not less than X".

---

From: Marcus Watts <[email-masked]>
Date: Tue, 03 Mar 2009 15:51:25 -0500

...
> hash, and encrypts that.  I note that this loses most of the entropy in
...
>                           tmp2 = truncate tmp1 to multiple of m

I believe the correct interpretation of "truncate tmp1 to multiple of m"
is "if sizeof tmp1 isn't a multiple of m, make the smallest truncation
that will result satisfy that requirement".  For m==1, that should mean
no truncation at all.

The data to be passed should be at least the size of the encryption
block, 16 bytes, or the encryption will simply fail.  For the context "m"
was defined in, that's not a problem because data to be encrypted will
contain a confounder & hash.  In this particular use, I think that means
the hash size for H must be > 16 bytes, which is probably guaranteed true.
For sha1, the hash size would be 20 bytes, so the last cbc fold operation
will degenerate into folding only 4 bytes into the last crypt operation.
You'll get exactly 20 bytes of entropy out, since E is reversible.  I
don't believe you're losing anything at all.

				-Marcus Watts

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Mar 2009 15:55:15 -0500

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> Though in retrospect, using m here was probably a
    Jeffrey> mistake, as it significantly limits the number of
    Jeffrey> distinct PRF blocks that can be derived from a given
    Jeffrey> input key.  We probably should have said something like
    Jeffrey> "a multiple of m, but not less than X".

There's no probably about this.
It seems clear that you wanted to use the block size  of the underlying encryption scheme.

It also seems clear that if at all possible we should treat this as a spec bug.

KRB-FX-CF2, and a bunch of other things will depend on this being
fairly strong.

I believe the PRF in 3962 is provably strong if it has a full block input given two assumptions:

1) the  hash has second preimage resistance
2) AES is a pseudo-random permutation.

Both of these seem like good assumptions to me.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 16:09:16 -0500

> that will result satisfy that requirement".  For m==1, that should mean

This is a sensible interpretation.

> block, 16 bytes, or the encryption will simply fail.

No.  16 bytes is the block size of the underlying cipher, but the E() 
operation describes the cipher in the particular mode used by this enctype, 
with a minimum block size of 'm'.  CTS mode can handle inputs of any size, 
though IIRC the handling for messages smaller than one block is a bit odd.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 22:14:29 +0100

> that will result satisfy that requirement".  For m==1, that should mean

That would improve things.

> don't believe you're losing anything at all.

According to RFC 3962, H is 12 bytes (96 bits) for both AES enctypes.
So the output size will be one block, or 16 bytes.

/Simon

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 3 Mar 2009 16:31:59 -0500

> So the output size will be one block, or 16 bytes.

H is SHA-1, without truncation; the 96-bit truncation is applied for  
"checksum" generation.  As Marcus indicated, the truncation should be  
to the largest multiple of 'm', which is 1 byte for AES, so no  
truncation would happen.  So, a 20-byte hash should get encrypted with  
the derived key.

That doesn't appear to be what MIT's current code does though.

Ken

---

From: Martin Rex <[email-masked]>
Date: Tue, 3 Mar 2009 23:38:40 +0100 (MET)

The idea behind the channel binding is that all data exchanges
that are cryptographically bound to the underlying TLS channel
will inherit reliable replay protection.

The prerequisite of a reliable replay protection is a inclusion
of a challenge from both communication peers into the establishment
of the TLS channel, which is provided by the client random
and server random in the respective hello handshake messages.

A lot of token exchanges in the Kerberos protocol world are 2-way
only.  Some exchanges require (or use) a time-based nonce plus
a server-side replay cache in order to provide replay protection
--but that doesn't really work in the multiple-KDC case where
distinct KDC instances that normally do not share a replay
cache use the same Kerberos principal.

The advantage of the replay protection based on TLS channel bindings
would be that it does not require an additional round-trip,
replay protection is a by-product of the TLS session establishment.

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Mar 2009 23:46:34 +0100

>  is fine to use a preconfigured cert.

I don't think that belongs in krb5starttls -- server cert validation is
not required, nor are channel bindings, to make Kerberos V5 a secure
protocol.  Remember, Kerberos V5 is secure over TCP.

>  validation process described in RFC5280 is quite sufficient.

Agreed, good point, I have reworded this.

>  a differnet type of name than that one.

It is different; id-pkinit-san contains a principal name and
id-krb5starttls-san contains a realm.

>  is essential to prevent people using web server certs to impersonate

I'm not convinced an EKU is needed.  The key in the server certificate
is only used for TLS server authentication.  I don't see a EKU defined
for RFC 2487, RFC 2595, RFC 4642, for example.  Not even IKE for IPSEC
defines an EKU (well IKE used to have an EKU but it was obsoleted).
Compare also EAP-TTLSv0 in RFC 5281, it doesn't define a EKU either but
it defines an authentication protocol over TLS.

So I think the normal key usage bits that are necessary to support TLS
are sufficient.  Maybe we could as the PKIX folks about this.

>  and restating it here suggests that other things dictated by TLS can be

Agreed, I have removed this part.

Updated text below.

Thanks,
/Simon

   these rules to accommodate special use cases.

   When X.509 server authentication is used, there is an alternative way
   to validate server certificates implicitly using trust anchors that
   MAY be used.  In this mode, the KDC server certificate is validated
   as described in [RFC5280].  The client MUST check that the server
   certificate contains a Subject Alternative Name (SAN) that binds the
   the server certificate to the intended Kerberos realm and for the
   purpose of using the Kerberos V5 STARTTLS extension.  For this
   purpose, we define a otherName SAN identified using a type-id of id-
   krb5starttls-san.  The value field should contain the Realm of the
   KDC, which is a KerberosString type.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Mar 2009 16:49:00 -0600

> replay protection is a by-product of the TLS session establishment.

Thank you.  You've hit the nail on the head.  It's important to bind
PA-ENC-TIMESTAMP, if you'll use it, and the AS-REP reply key, to the TLS
channel.

The only time you can get away with not doing that is when you're
validating the server's cert.  That's a difficult-to-deploy use case.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Mar 2009 19:08:23 -0500

> id-krb5starttls-san contains a realm.

True, but PKINIT describes how to use id-pkinit-san to name the KDC for a 
realm.  KDC's should not need different certificates depending on whether 
the client is using PKINIT or krb5starttls.

> it defines an authentication protocol over TLS.

We had this discussion when defining PKINIT, and I believe the same 
arguments made there apply here.

No, an EKU is not needed for every protocol.  However, we specifically 
defined one for PKINIT so that one could use a certificate to impersonate a 
KDC only if the certificate was specifically issued for that purpose.  This 
prevents a certificate issued for use by a web server from being used to 
impersonate a KDC.  Since it is quite common for a web server to have a 
hostname which is the same as the name of a Kerberos realm, and the 
operators of web servers are typically not authorized or competent to 
operate KDC's, it is desirable to prevent the certificates held by web 
servers from being used for KDC's.  Further, since web servers typically 
present a much larger attack surface than do KDC's, it is desirable to 
prevent an attacker who compromises a web server from being able to 
impersonate a KDC.

Looking at this from another angle, in defining PKINIT we set down specific 
rules for certificates belonging to KDC's.  I think if you want to use 
different rules for krb5starttls, you need to justify why the difference is 
necessary and appropriate.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Mar 2009 17:17:38 -0500

Marcus, that may be the best interpretation of the spec, although I'm
concerned that coming up with a security proof for it will be
difficult.  My intuition is that it is insecure because you have 160
bits of input into your encryption function and 256 bits of output.
Now, it is very hard for me to argue that your construction is less
secure than the one I will propose, but it is also beyond my ability
to analyze the security of your construction.

Here's what MIT does and has been shipping for a while.  We truncate
the hash to 128 bits and encrypt one block of that, effectively using
AES in ECB mode.

I can argue that's secure under the assumptions that sha-1 is
collission resistant and that AES is a PRP.  I think assuming that AES
is a PRP seems entirely reasonable: that's one of the properties of a
good block cipher.  In practice I suspect we only depend on sha-1
being second preimage resistant but I cannot construct a proof off the
top of my head that works that way.

So, if MIT_AES_PRF is not a PRF then that means there exists an
attacker A, that when given oracle access to either a random function
R or mit_aes_prf P can determine with probability greater than
0.5+epsilon which it was given access to.  We will construct an
attacker B that distinguishes AES from a PRP.
That is, B will either be given access to a random function or to AES and must return which it is given access to with probability similar to A's success probability.

B^x calls A^(sha-1(x)).  If A returns random function, B returns random function; else B returns AES.

If B is given aes as an input, then B gives A access to mit_aes_prf.
If B is given a random function as input, then A is given access to a
function that maps the inputs through sha-1 and then calls the random function.  Any permutation on the inputs of a random function will still produce a random function; so assuming that A does not find sha-1 collisions then A still has access to a random function.

Thus when B is given AES, A is given mit_aes_prf; when B is given a
random function, A is given a random function.  By the definition of
A, A will distinguish these two cases.  Whenever A correctly
distinguishes, B will correctly distinguish.  Thus, B violates the
assumption that AES is a PRP and no A exists under these assumptions.

I don't think this proof can easily be extended to aes-cbc or aes-cts
without an argument for the assumption that aes-cbc is a PRF.  That
assumption seems unreasonable because the second block of input to
AES-CBC does not affect the first block of output.

There may be some more complicated proof that aes-cbc(sha-1(x)) is a
PRF.

I have more confidence that mit_aes_prf is in fact a PRF than I do
that the TLS PRF is a PRF.  I suspect some people in CFRG would agree
with me and others would have equal confidence.  I suspect most would
agree that both functions are reasonable.

My preference is that we standardize mit_aes_prf as the AES PRF.
Whether we can do this depends on what if any interoperability
problems would result.

Can we hear from implementers about whether they ship a PRF and if so
what it does?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 04 Mar 2009 12:08:59 +0100

> agree that both functions are reasonable.

Have MIT_AES_PRF been documented before your e-mail?  If not, I believe
the usual conservative approach from the cryptographic community would
be to "wait and see".  I believe the TLS PRF has had more deployment
than MIT_AES_PRF.  The former is used to derive keys in many protocols.
I believe the cryptographic community's confidence in the TLS PRF is
comparatively high.

I don't think krb5starttls is an good place to invent yet another PRF.
The "pseudo-random" function provided by RFC 3961 do not appear to be
sufficient here since its output is not variable length.

Finally, when the user does not have a long term key, using the TLS PRF
to derive key appears unavoidable.

All this argues for using the TLS PRF in krb5starttls-bootstrap.

I would welcome standardization of MIT_AES_PRF, and once it is
available, it would be easy to specify a krb5starttls-bootstrap pre-auth
variant that uses the MIT_AES_PRF instead of the TLS PRF when the user
has a long term shared secret.

> Can we hear from implementers about whether they ship a PRF and if so

Shishi does not expose any PRF, or even the RFC 3961 "pseudo-random
function".  It does expose the DR and DK primitives.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 04 Mar 2009 12:29:26 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> True, but PKINIT describes how to use id-pkinit-san to name the KDC
> for a realm.  KDC's should not need different certificates depending
> on whether the client is using PKINIT or krb5starttls.

I think KDCs should have the ability to use a separate certificate/keys
for PKINIT and krb5starttls.

With my proposal, the administrators can decide for themselves whether
they want to use one certificate/key for both PKINIT and krb5starttls
(thus containing both id-pkinit-san and id-krb5starttls-san) or whether
they want to use separate certificates/keys (one with id-pkinit-san and
another with id-krb5starttls-san).

> defined one for PKINIT so that one could use a certificate to
> impersonate a KDC only if the certificate was specifically issued for
> that purpose.  This prevents a certificate issued for use by a web
> server from being used to impersonate a KDC.  Since it is quite common
> for a web server to have a hostname which is the same as the name of a
> Kerberos realm, and the operators of web servers are typically not
> authorized or competent to operate KDC's, it is desirable to prevent
> the certificates held by web servers from being used for KDC's.
> Further, since web servers typically present a much larger attack
> surface than do KDC's, it is desirable to prevent an attacker who
> compromises a web server from being able to impersonate a KDC.
>
> Looking at this from another angle, in defining PKINIT we set down
> specific rules for certificates belonging to KDC's.  I think if you
> want to use different rules for krb5starttls, you need to justify why
> the difference is necessary and appropriate.

The rules set down in PKINIT were specific to that protocol, but I will
think more about this.  It seems to me that a krb5starttls server
doesn't _need_ the ability to sign KDC responses via PKINIT, and it is
thus potentially harmful to require that their certificates are issued
with that ability.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Mar 2009 10:34:29 -0500

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Have MIT_AES_PRF been documented before your e-mail?  If
    Simon> not, I believe the usual conservative approach from the
    Simon> cryptographic community would be to "wait and see".  I
    Simon> believe the TLS PRF has had more deployment than
    Simon> MIT_AES_PRF.  The former is used to derive keys in many
    Simon> protocols.  I believe the cryptographic community's
    Simon> confidence in the TLS PRF is comparatively high.

I *thought* mit_aes_prf was specified in 3961/3962.  The fact that it
is not is almost certainly my fault.

I'm certain that the construction of using a cipher in ECB mode with a
hash as a compression function is well studied and understood.

I have no objection to you using the TLS extractor in starttls; I
think using the PRF directly would be problematic.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Mar 2009 10:45:16 -0500

I don't think you need the EKU if you have a particular SAN that
implies you are a KDC.  I.E. if you have a SAN that is only for
krb5-starttls KDCs then it seems fine to use without an EKU.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Mar 2009 11:29:50 -0600

> > on whether the client is using PKINIT or krb5starttls.

Well, they may need different certificates if they are used in different
ways (e.g., one to sign the other to encrypt).

But as far as *naming* and validation rules go, I don't see any reason
for PKINIT and start-tls to differ at all.

> for PKINIT and krb5starttls.

I disagree as to certificate naming.  Why should a CA and/or realm
administrator care which of two mostly equivalent[*] protocols using
PKIX gets used here?

[*] for the purpose of authenticating the server anyways.

Put it this way:

 - It will be simpler for you as the I-D author to just reference PKINIT
   normatively for this, particularly given that you've not implemented
   any option other than pre-shared server certs.

 - It will be simpler for you as an implementor to implement PKINIT
   server cert naming and validation rules given that you (or someone
   else) might want to add PKINIT support to your implementation some
   day and then there will be no need to have two code paths for this.

 - It will be simpler for other implementors who have PKINIT
   implementations now to add start-tls if they can re-use their
   existing server cert naming and validation code.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Mar 2009 11:32:57 -0600

> think using the PRF directly would be problematic.

Yes, using the krb5 PRF turns out to be not as simple as using the GSS
PRF -- that's why RFC4402 wasn't entirely trivial.

I would prefer use of the krb5 PRF over the TLS extractor if it were
trivial.  Evidently it's not.  I reluctantly retract my proposal that
start-tls use the krb5 PRF.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 04 Mar 2009 23:03:43 +0100

> hash as a compression function is well studied and understood.

Agreed.  I think mit_aes_prf should be describe in a separate document
rather than in krb5starttls, and until that I-D is created it will be
difficult to find a normative reference.

> think using the PRF directly would be problematic.

Right.  I meant the tls-extractor draft [1] when I referred to "TLS PRF"
above.

/Simon

[1] http://tools.ietf.org/html/draft-ietf-tls-extractor-04
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Mar 2009 17:13:51 -0500

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
    Simon> Agreed.  I think mit_aes_prf should be describe in a
    Simon> separate document rather than in krb5starttls, and until
    Simon> that I-D is created it will be difficult to find a
    Simon> normative reference.

Well, I'm hoping that we retroactively change the AES PRF in the krb5
crypto systems.
I'm hoping that mit_aes_prf becomes the krb5 prf for AES.

That's clearly something MIT can do.  Larry has not stated an opinion
on whether it is a good idea, but did not raise an interoperability
concern when I gave him an opportunity to do so.  Preliminary evidence
suggests that Heimdal will not raise an interoperability concern, although of course I'm waiting for Love to comment.
You said earlier today that you did not expose the krb5 PRF.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Mar 2009 00:00:33 +0100

> top of my head that works that way.

One thing that may complicate your proof is that you truncate the hash:
It is likely fine for the particular instance of SHA-1, but I think it
is possible to create a theoretical hash function that wouldn't behave
as well under truncation.  I believe this makes it difficult to create a
security proof of the PRF in a generic setting where you only assume
properties of the hash function and block cipher.

Here is a hash function that would fool your proof but still believed to
be collision resistant: the output is 128+160 bits consistent of 128
zero bits concatenated with the 160 bit SHA-1 hash of the input.

I am not sure you need a generic proof.  You only need a proof that the
PRF used with SHA-1 is secure, and then you can assume more than just
collision resistance.

Generally, I would prefer a PRF that has a proof in a general model
where only properties of the algorithms are needed though.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 04 Mar 2009 18:21:18 -0500

> zero bits concatenated with the 160 bit SHA-1 hash of the input.

That's not a very good cryptographic hash.  I'm afraid the terminology I'm 
looking for is escaping me at the moment, but we generally expect that 
every bit of a hash output will depend on every bit of the input.  There 
are certainly any number of situations in which a truncated hash value is 
expected to be just as unpredictable as the untruncated value.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Mar 2009 18:22:46 -0500

Simon> Sam Hartman <[email-masked]> writes:
    >> Here's what MIT does and has been shipping for a while.  We
    >> truncate the hash to 128 bits and encrypt one block of that,
    >> effectively using AES in ECB mode.
    >> 
    >> collission resistant and that AES is a PRP.  I think assuming
    >> that AES is a PRP seems entirely reasonable: that's one of the
    >> properties of a good block cipher.  In practice I suspect we
    >> only depend on sha-1 being second preimage resistant but I
    >> cannot construct a proof off the top of my head that works that
    >> way.

    Simon> One thing that may complicate your proof is that you
    Simon> truncate the hash: It is likely fine for the particular
    Simon> instance of SHA-1, but I think it is possible to create a
    Simon> theoretical hash function that wouldn't behave as well
    Simon> under truncation.  I believe this makes it difficult to
    Simon> create a security proof of the PRF in a generic setting
    Simon> where you only assume properties of the hash function and
    Simon> block cipher.

You are correct that my proof depends on the *truncated hash function*
being collission resistant.  Or, I suspect in practice, being second
preimage resistant.

If we're going to use that construction in the simplied profile, we do
need a generic proof.  If we're going to junk the simplified profile
going forward, I agree we don't need something generic.

Also, as a side note, the function you provide would not generally be
considered collission resistant because that typically means you
expect more than 2**(n/2) work to find a collission.  For your hash
function I expect to find collissions in less than 2**80 work, but if
it is good would expect to need 2**144 work.  That said, I agree with
the general point you are making: truncation of hashes is an open
problem in cryptography or at least was a couple years ago.

Assuming that the truncation of a generic hash is also a hash is not
an unreasonable assumption, but it is an additional assumption.

--Sam

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 4 Mar 2009 17:50:55 -0800

> an unreasonable assumption, but it is an additional assumption.

I suppose that's an assumption in the strict mathematical sense.  Any  
real hash that did not satisfy that property would be considered  
poorly designed.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Mar 2009 09:59:13 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> That's not a very good cryptographic hash.  I'm afraid the terminology
> I'm looking for is escaping me at the moment, but we generally expect
> that every bit of a hash output will depend on every bit of the input.
> There are certainly any number of situations in which a truncated hash
> value is expected to be just as unpredictable as the untruncated
> value.

Right, but assuming the hash has the property you describe goes beyond
what one usually wants to assume about a hash function when doing
security proofs.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Mar 2009 10:15:58 +0100

Sam Hartman <[email-masked]> writes:

> it is good would expect to need 2**144 work.

You must be using a different definition of collision resistance than I
do.  I haven't seen any definition of collision resistance that
_requires_ any correlation between the hash output size and the
computability infeasibility.  Compare:
http://en.wikipedia.org/wiki/One-way_hash_function

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Mar 2009 10:21:05 +0100

> administrator care which of two mostly equivalent[*] protocols using

Because an administrator may want that a pkinit certificate is not
usable as a krb5starttls certificate and vice versa.

I think it should be _possible_ to use the same certificate for both
pkinit and krb5starttls.  But I don't think it should be _required_.

/Simon

---

From: Marcus Watts <[email-masked]>
Date: Thu, 05 Mar 2009 04:35:55 -0500

Simon had replied to Sam:
...
...

sha-1 is supposed to be ok to truncate, & has a preferred direction
of truncation (delete the right-most bits).

There's of course no guarantee a randomly constructed hash might have
that property, but "ok to truncate right-most bits" is almost certain
to be a safe assumption for a "well-designed" general purpose cryptograpic
hash function.

				-Marcus Watts

---

From: Marcus Watts <[email-masked]>
Date: Thu, 05 Mar 2009 05:02:37 -0500

Jeffrey Hutzelman <[email-masked]> wrote:
...
> expected to be just as unpredictable as the untruncated value.

The term Jeff was looking for is "avalanche effect".  It is a perfectly
valid security assumption.

I think I ought to point out there's a difference between "mathematical
proof" and "real world security".  For instance, it's not hard to
design a system that has PFS using 16 bit Diffie-Hellman keys.  Wonderful
math, great performance, terrible security.  The converse is also easy
to demonstrate.  For "real world security", you have to look at *all*
the factors, and there are nearly certain to be some that defy complete
mathematical analysis.

				-Marcus Watts

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Mar 2009 11:34:40 +0100

> the factors, and there are nearly certain to be some that defy complete

I agree.  Security proofs are not always that relevant (the assumptions
required are often too far from what holds in reality), but to some
communities they have value.  So I think that if it isn't too difficult
to change an algorithm to make it easier to do a security proof in a
general model, I think it is worth it.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Mar 2009 09:07:07 -0600

> usable as a krb5starttls certificate and vice versa.

Why should the CA admin care which protocol is being used?  And as for
the KDC admin, they can just turn off the protocol(s) they don't want.

If the issue is that you think there may be a cut-n-paste attack from
one protocol to the other, let's make sure that that's not the case.

> pkinit and krb5starttls.  But I don't think it should be _required_.

You can have the same naming requirements and still have separate
certificates.

I'm not interested in forcing the admins to have one cert -- I'm
interested in being able to write KDC certificate validation code once
and use it for both, PKINIT and start-tls.

Nico

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Mar 2009 17:48:20 +0100 (MET)

> the KDC admin, they can just turn off the protocol(s) they don't want.

<rant>
Because CAs use it to defend their business models and create
revenue stream.  Some CAs even go as fas as claiming DMCA
copyright protections to "software" in form of X.509 certs
that they sign/issue.
</rant>

I think we should tailor our specifications to meet
technical requirements and security considerations only
and entirely ignore specific business models that seriously
inconvenience the consumers of the technology.

-Martin

<pkix topic>
I think we need a standard that requires X.509 certs that are
to be used with IETF protocols (e.g. based on rfc3280/rfc5280)
to come with unlimited unrevocable redistribution rights or
otherwise be declared non-compliant.  How about adding an X.509v3
extended attribute that indicates the "unlimited unrevocable
redistribution rights" to (the successor of) rfc5280 with
a status of "RECOMMENDED" that is eventually turned into
a MUST be present, must be TRUE.
</pkix topic>
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Mar 2009 10:53:20 -0600

> copyright protections to "software" in form of X.509 certs

[This is very OT.  There was a discussion of this recently on the
cryptography@metzdowd list, and the consensus seemed to be that such CA
operators are smoking crack, that no such copyright claims are likely to
hold up in court.  We should not turn this thread into a repeat of that
one.  If you want to continue this OT sub-thread do change the Subject.]

> inconvenience the consumers of the technology.

I take it you agree with me then that start-tls should copy the cert
validation specification from PKINIT :)

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 05 Mar 2009 15:53:00 -0500

> one.  If you want to continue this OT sub-thread do change the Subject.]

<hat type=chair>
No, please drop the off-topic subthread, and stick to the business at hand.
</hat>

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 06 Mar 2009 13:23:52 +0100

Nicolas Williams <[email-masked]> writes:

> Why should the CA admin care which protocol is being used?

They probably don't.  Realm admins do.

> And as for the KDC admin, they can just turn off the protocol(s) they
> don't want.
>

No, here is the problem: an attacker compromises the PKINIT
implementation on a KDC and get the private key.

With your model, the attacker can now impersonate a krb5starttls service
as well.

With my model, the administrator have the ability to protect against
this attack by using separate certificate and keys for the two services,
and use different machines/implementations for the two services to
reduce the risk that an attacker can compromise both systems.

> You can have the same naming requirements and still have separate

Sure, but then you become vulnerable to the problem above.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 06 Mar 2009 14:05:33 +0100

Simon Josefsson <[email-masked]> writes:

> written a section that could be added.

I have updated the text after considering the comments so far.  I'm
still not sure if this is useful or where it belongs.  I think more
discussion of the updated text will help to answer that.

/Simon

   The TLS protocol can provide server authentication using, for
   example, X.509 and OpenPGP.  By validating the server certificate,
   clients can be certain that it is talking to the intended KDC.  The
   Kerberos V5 STARTTLS protocol do not require clients to verify the
   server certificate.  That is because the client can verify that it is
   talking to the intended KDC by using the Kerberos V5 protocol.

   If a KDC presents a X.509 server certificate over TLS, it MUST
   contain an otherName Subject Alternative Name (SAN) identified using
   a type-id of id-krb5starttls-san.  The intention is to bind the
   server certificate to the Kerberos realm for the purpose of using
   Kerberos V5 STARTTLS.  The value field of the otherName should
   contain the realm as the "Realm" ASN.1 type.

   To validate a server certificate, the client MAY use local
   configuration (e.g., a list that map realm names to a copy of the
   server's certificate) and compare that with the authentication
   information provided from the server via TLS.  For illustration, the
   server certificate could be a X.509 certificate or an OpenPGP key.
   In this mode, the client need no processing related to id-
   krb5starttls-san.

   When the server presents a X.509 server certificate, there is an
   alternative way that clients MAY use to validate the server
   certificate.  In this mode, the KDC server certificate is validated
   by "Certification Path Validation" as described in [RFC5280].  In
   addition, the client MUST verify that the server certificate contains
   the id-krb5starttls-san SAN and that the value is identical with the
   intended Kerberos realm.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Mar 2009 17:28:17 -0600

> With your model, the attacker can now impersonate a krb5starttls service

If the compromise the implementation of one protocol and can recover one
private key (or use it, if it's on a token) then they can do the same
for the other one.

> reduce the risk that an attacker can compromise both systems.

Who's going to do that?  The KDC discovery protocol right now does not
allow for discovery of different KDCs based on pre-auth type (PKINIT) or
TCP extensions use.

> Sure, but then you become vulnerable to the problem above.

That I don't care about.  But I'd be OK with adding an optional EKU that
clients can require for one or the other.  I'm NOT OK with adding a new
subjectAlternativeName or any other significant certificate naming
differences relative to PKINIT.

Nico

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 07 Mar 2009 02:02:57 +0100

> private key (or use it, if it's on a token) then they can do the same

I disagree.  PKINIT and krb5starttls are sufficiently different
protocols that there can be attacks against implementations of one that
may not be effective against the other.

> Who's going to do that?

I believe it is a good practice to use different keys for different
protocols, so I would do that if I were to deploy both PKINIT and
krb5starttls in a Kerberos realm.  For similar reasons, I use different
keys on each MX for SMTP STARTTLS.  Compromise of one MX should not lead
to compromise of other MXs.

> The KDC discovery protocol right now does not allow for discovery of
> different KDCs based on pre-auth type (PKINIT) or TCP extensions use.

What KDC discovery protocol?  The SRV record defined in krb5starttls
allow clients to discover krb5starttls-aware servers for a realm.

> differences relative to PKINIT.

I think an EKU instead would work, technically, but I don't think it can
be optional for the same reason the SAN cannot be optional: otherwise
you risk that someone with a web server certificate for a domain can
impersonate a krb5starttls service for a realm.

This seems like more of an PKIX question than a Kerberos V5 question,
really, so we could ask for guidance from the PKIX WG.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 11 Mar 2009 17:01:51 -0500

> may not be effective against the other.

If you're saying that you'd implement separation between the
implementations of both, then I agree.  Are you trying to implement
start-tls via an stunnel-like shim?  (It is tempting, provided that you
can communicate the relevant TLS information to the KDC.)

> impersonate a krb5starttls service for a realm.

Right, start-tls clients would have to require that EKU; they could be
configured not to, but by default they'd have to require it.  PKINIT
clients would not.

> really, so we could ask for guidance from the PKIX WG.

Sure.  But the bottom-line for me is that the KDC cert naming rules for
start-tls be as similar as possible to PKINIT's, and that they be
referenced by, rather than copied into the start-tls I-D.

What differences there might be should be the minimum required to allow
the separation that you want.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 16 Mar 2009 14:28:49 +0100

> can communicate the relevant TLS information to the KDC.)

That wasn't exactly what I was thinking of, but it results in mostly the
same architecture.

The point is that the attack surface of an krb5starttls KDC will not
necessarily be the same as the attack surface of an pkinit KDC, and thus
we should prefer a model that allows (but do not force) administrators
to setup a KDC so that compromise of keys for one server doesn't
necessarily lead to compromise of the other server.

As far as I can see, this requires a separate required attribute in the
server certificate that clients can check.

> configured not to, but by default they'd have to require it.  PKINIT

Right.  Equally for a SAN.

I agree.

So the questions is whether krb5startts should require that server
certificates contain a new id-krb5starttls-san SAN or a new EKU
id-krb5starttls-kp.

However, I don't see how an id-krb5starttls-kp by itself would work.  If
only an EKU is used, there would be no mapping in the certificate
between the KDC server certificate and the Kerberos realm.  Clients
would then be forced to have a locally configured list of mapping
between server certificates and Kerberos realms.  Then I don't see a
point in using RFC 5280 style verification at all -- the client can
verify the server's certificate against its locally stored certificate
directly without using RFC 5280 verification.

So it seems one SAN is needed to hold the realm.

Using only a id-pkinit-san wouldn't work: then you could use the same
certificate for both krb5startls and pkinit, and consequently attackers
compromising one system would compromise both.

Using a id-pkinit-san with a id-krb5starttls-kp doesn't work, PKINIT
says that if the id-pkinit-san is present no checking of the EKU is
needed:

   If the KDC certificate contains the Kerberos TGS name encoded as an
   id-pkinit-san SAN, this certificate is certified by the issuing CA as
   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.

However, an id-krb5startls-san SAN by itself would work.  The client can
verify that the server certificate is intended for the appropriate
realm, and for the purpose of krb5starttls.

Defining a new SAN is what the new section I proposed does.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 16 Mar 2009 09:48:14 -0400

> Right.  Equally for a SAN.

The presence of a SAN really shouldn't be used to indicate that a 
certificate is useable for a particular purpose; that's not what the field 
is for.  We allowed PKINIT to proceed without the PKINIT KDC EKU if a 
particular SAN was present (with a particular value) as a compromise; 
that's not a decision we should emulate.

> So it seems one SAN is needed to hold the realm.

Yes.  And, we have already defined how to do this using the Kerberos 
principal name SAN defined in PKINIT.

> certificate for both krb5startls and pkinit

Which is fine in some cases.

> says that if the id-pkinit-san is present no checking of the EKU is

No, it doesn't.  It says that if id-pkinit-san is used to encode TGS name, 
thus indicating that this certificate belongs to a KDC, then the 
requirement that the id-pkinit-KPKdc EKU is not required to be present. 
This is _not_ the same as saying that EKU checking is not required.

RFC3280 section 4.2.1.13 is quite clear on how EKU's work, and we verified 
this with the PKIX folk when defining PKINIT.  It says:

>   If the extension is present, then the certificate MUST only be used
>   for one of the purposes indicated.  If multiple purposes are
>   indicated the application need not recognize all purposes indicated,
>   as long as the intended purpose is present.  Certificate using
>   applications MAY require that a particular purpose be indicated in
>   order for the certificate to be acceptable to that application.

PKINIT invokes that last sentence, requiring that id-pkinit-KPKdc be 
present in certificates used for PKINIT KDC's, but only when the 
certificate does not contain an id-pkinit-san SAN naming the TGS.  However, 
even when such a SAN is present, the requirements imposed by RFC3280 still 
apply; this means that if the Extended Key Usage extension is present, it 
_must_ contain either id-pkinit-KPKdc or anyExtendedKeyUsage (from 
RFC3280); otherwise the certificate is not valid for use with PKINIT.

This is important; it prevents a certificate issued exclusively for some 
_other_ purpose from being used with PKINIT.  For example, a certificate 
containing an EKU extension listing only a krb5starttls-specific usage 
would not be usable for PKINIT.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 16 Mar 2009 15:16:55 +0100

Right.

> Which is fine in some cases.

But not fine in some cases.

> No, it doesn't.  It says that if id-pkinit-san is used to encode TGS
> name, thus indicating that this certificate belongs to a KDC, then the
> requirement that the id-pkinit-KPKdc EKU is not required to be
> present. This is _not_ the same as saying that EKU checking is not
> required.

Right, but if the certificate follow this approach (i.e., id-pkinit-san
and id-krb5starttls-kp) you open up for the attack we discussed:

  Compromise the krb5starttls (or pkinit) server, steal the private key,
  and use that certificate and key to fake a pkinit (or krb5starttls)
  server.

I believe that allowing this to happen is bad protocol design.

Do you disagree with that?

If so, I understand your position (but wouldn't agree with it).

If not, I don't follow the rest of your e-mail: you appear to enable an
attack that we want to protect against.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 16 Mar 2009 10:40:48 -0400

>   and use that certificate and key to fake a pkinit (or krb5starttls)

No, it doesn't.  A certificate containing the id-krb5starttls-kp EKU and no 
other _cannot be used for PKINIT_.  It fails the test described in RFFC3280 
section 4.2.1.13, where Extended Key Usage is defined:

>    for one of the purposes indicated.

> Do you disagree with that?

I do.  PKINIT and krb5starttls are not independent services; they are 
different ways of reaching the same service.  Their fate is inexorably tied 
together; a compromised KDC is a compromised KDC is a compromised realm, no 
matter what protocol was used.  However, I think we can agree to disagree 
on this point, and still make progress.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 16 Mar 2009 16:31:34 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> No, it doesn't.  A certificate containing the id-krb5starttls-kp EKU
> and no other _cannot be used for PKINIT_.  It fails the test described
> in RFFC3280 section 4.2.1.13, where Extended Key Usage is defined:
>

I wonder if the client comes that far since RFC 4556 contains:

   Unless the client knows by some other means that the KDC certificate
   is intended for a Kerberos KDC, the client MUST require that the KDC
   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
...
   If the KDC certificate contains the Kerberos TGS name encoded as an
   id-pkinit-san SAN, this certificate is certified by the issuing CA as
   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.

A reasonable interpretation seems to be that a KDC certificate with a
id-pkinit-san is intended for a Kerberos KDC, and the client does not
have to check the EKU.

This interpretation is reinforced later down in the pkinit document:

   In order to trust a KDC certificate that is certified by a CA as a
   KDC certificate for a target realm (for example, by asserting the TGS
   name of that Kerberos realm as an id-pkinit-san SAN and/or
   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
   as described in Section 3.2.4), the client MUST verify that the KDC

Note use of 'and/or' rather than 'and'.

However, what are you suggesting for krb5starttls?

That krb5starttls should require presence of BOTH id-pkinit-san and
id-krb5starttls-kp in X.509 server certs?

> different ways of reaching the same service.

Some clients will need to talk to a krb5startls-enabled KDC.  Talking to
a PKINIT-enabled KDC cannot achieve the same thing.  This makes the
services distinct to me.

> Their fate is inexorably tied together; a compromised KDC is a
> compromised KDC is a compromised realm, no matter what protocol was
> used.

There is no linking like that in krb5starttls.

Compromising a krb5starttls server certificate does not have to be a
significant problem: it would basically reduce the security of Kerberos
V5 to what is offered by Kerberos V5 over TCP.  That security isn't
considered compromised by most people.

This is another reason that using distinct keys for both services is a
good idea, and further, that compromise of one service should not allow
attackers to compromise the other service.

> However, I think we can agree to disagree on this point, and still
> make progress.

As long as it is _possible_ to protect against the attack I'm concerned
with, I agree.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 16 Mar 2009 14:29:41 -0500

> There is no linking like that in krb5starttls.

I believe that Jeff meant that a compromise of the TGS keys and/or the
service principals' long-term keys is catastrophic.  I believe that's
right.

> As long as it is _possible_ to protect against the attack I'm concerned

It is, as Jeff explained.  To summarize:

 - one cert, both protocols -> no EKUs or both, PKINIT and start-tls
                               EKUs present

 - one cert per protocol -> one cert with PKINIT EKU, one cert with
			    start-tls EKU

We don't need a new SAN, just a new EKU.

Nico

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 17 Mar 2009 11:41:41 +0100

> service principals' long-term keys is catastrophic.  I believe that's

Ok.  I was talking about compromise of the private key for the
krb5startls certificate.  That wouldn't be the end of the world; it
reduces the security level of krb5starttls to Kerberos V5 over TCP.

If the same private key is used for PKINIT, and it is compromised, the
problem appears much worse?

That's why I believe administrators should not be encouraged, or even
have the possibility, to use the same key for both protocols.

I prefer a protocol where administrators cannot make this mistake.  But
if you and Jeff wants to use the same private key for both krb5starttls
and PKINIT, and nobody else in the WG speaks up, I think we are close to
agreeing on a compromise that makes the protocol allow both models, and
leave the decision to administrators.

>  - one cert per protocol -> one cert with PKINIT EKU, one cert with

Right.  The PKINIT SAN needs to be present in all cases.

> We don't need a new SAN, just a new EKU.

Alternatively, we don't need a new AKU, just a new SAN.

The complete picture is:

  - one cert, both protocols -> PKINIT SAN, no EKUs or both
                                PKINIT/KRB5STARTTLS EKU present

  - one cert per protocol -> PKINIT SAN, one cert with PKINIT EKU,
                             one cert with start-tls EKU

The alternative that I suggested would be:

  - one cert, both protocols -> PKINIT/KRB5STARTTLS SAN,
                                EKU as per PKINIT

  - one cert per protocol -> one cert with PKINIT SAN/EKU,
                             one cert with KRB5STARTTLS SAN

Thus the choice is between:

1) Define a krb5starttls EKU.  A SAN is still needed, so krb5starttls
   needs to specify one or use the PKINIT SAN.  RFC5280-validating
   krb5starttls clients MUST process both SAN and EKU.

2) Define a krb5starttls SAN.  An EKU is not needed.  RFC5280-validating
   krb5starttls clients MUST check only the krb5starttls SAN.

I prefer 2) because it is less complex to implement and appears more
robust.

We may be close to formulate a question for the PKIX WG.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Mar 2009 10:25:37 -0500

> reduces the security level of krb5starttls to Kerberos V5 over TCP.

Until you throw in your start-tls bootstrap I-D.  Then you have the same

> problem appears much worse?

Not really: with the server's private key but not the realm's TGS or
other principals' long term secret keys all the attacker can do is
impersonate the server to the client -- bad enough, but it can't act as
an MITM between the client and other services, and it can't impersonate
any client principal to any service because the Tickets it issues have
to be encrypted in valid secret keys that the attacker doesn't have.

Which means that clients should still validate TGTs obtained via PKINIT
when performing user logins, even though the KDC might be authenticated
by PKINIT.

The better argument might be that it's harder to separate PKINIT from
the rest of the KDC implementation than it is to separate start-tls from
the rest of the KDC implementation, so that a compromise of a PKINIT
implementation is more likely to be a complete KDC compromise than a
compromise of start-tls.  But it's all about implementation details.  I
think that separating processing of PKINIT pre-auth is probably quite
doable.

But even with that argument you still fail to be convincing about the
need to separate start-tls and PKINIT: if a PKINIT compromise
compromises the whole realm then protecting start-tls becomes
irrelevant, and if a PKINIT compromise does not compromise the whole
realm then you're back to what the attacker can do with the stolen
private key: "not much" (see above).

> Right.  The PKINIT SAN needs to be present in all cases.

Yes.

> Alternatively, we don't need a new AKU, just a new SAN.

New EKUs are easier to add as far as CAs are concerned.  New SANs are
much harder to add.

>                              one cert with start-tls EKU

Yes.

>                              one cert with KRB5STARTTLS SAN

No.

> I prefer 2) because it is less complex to implement and appears more

You've not made the case for (2) being "more robust" and you're ignoring
the difficulty of adding new SANs (i.e., it's not just a matter of
specifying it, but of getting CAs to support it).

> We may be close to formulate a question for the PKIX WG.

Yes, but I don't think we've exhausted all avenues in this WG yet.

For one I think that the impact of private key compromise in both, the
PKINIT and start-tls cases is small enough relative to the compromise of
a realm's principal's long-term keys that I think you're making too big
a deal of this.  For another you've not made the case that adding a new
SAN will make start-tls "more robust" than adding a new EKU.  Once we've
thought about these two issues a little more I think we can distill a
question for the PKIX WG.

Nico

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 18 Mar 2009 01:39:06 +0100

> Until you throw in your start-tls bootstrap I-D.  Then you have the same

The main use of krb5starttls does not involve starttls-bootstrap
techniques.

> when performing user logins, even though the KDC might be authenticated

Thanks for explanation.

> private key: "not much" (see above).

This also argues that server certificate validation should be optional
for krb5starttls clients: proper server certificate validation does not
protect against any particular attack.  Right?

Server certificate validation may be needed when krb5startls-bootstrap
is used to avoid use of client's long-term key.  So possibly the section
on server certificate validation belongs in that document only.

> New EKUs are easier to add as far as CAs are concerned.  New SANs are

That is not my experience.  Adding a new SAN to a certificate, and
checking a SAN, is easy in the implementations I'm familiar with.
Adding a new EKU requires more work, and there aren't even APIs to do
it.  Which CA implementation are you thinking of?

>>                              one cert with KRB5STARTTLS SAN

I assume you are only asserting your preference here?

> specifying it, but of getting CAs to support it).

Perhaps this is the problem: to me, adding and checking SANs are easier
than adding and checking both a SAN and an EKUs.

> question for the PKIX WG.

My reason for believing it is more robust is because there is less
complexity and less specification reading involved.  If the pkinit SAN
is used by two different protocols, there is a risk that assumptions
about the SAN that is valid in the context of one protocol may not be
valid in the context of the other protocol.  Evaluating the semantics of
the id-pkinit-san SAN would require knowledge of _both_ krb5starttls and
pkinit to get the complete picture.  If krb5starttls use a separate SAN,
anyone evaluating the use of id-pkinit-san can ignore the krb5starttls
document, and anyone evaluating use of id-krb5starttls-san can ignore
the pkinit document.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 17 Mar 2009 23:55:04 -0500

> The main use of krb5starttls does not involve starttls-bootstrap

OK, see below.

> protect against any particular attack.  Right?

Well, no, it does provide some protection, specifically against:

 - off-line passive dictionary attacks (the attacker can't get the
   PA-ENC-TIMESTAMP ciphertext to attack if you're using a cipher suite
   with confidentiality protection and if you authenticate the server,
   provided neither the cipher suite nor the server's private key are
   compromised);

 - clients that have no host credentials with which to validate TGTs (by
   getting a service ticket and decrypting it) can still authenticate
   the AS, otherwise an attacker could mount an MITM attack (though
   without breaking pre-auth the MITM will not be able to authenticate
   as the client user to the server, but depending on what the attacker
   might cause the client to send and on whether they've been able to
   steal credentials then the attacker might get something);

These attacks are not terribly worrisome, but that doesn't mean that we
shouldn't at least provide a mode to defeat them -- and that's what a
server cert does in your case.  But the first of these is at least quite
feasible (through attacks on DNS), so if you do nothing about it one
might wonder why bother with start-tls in the first place.

> on server certificate validation belongs in that document only.

I agree that server cert validation will be all the more important as
the second I-D progresses.

But I think specifying it now is useful if it's a simple matter of a
normative reference to PKINIT's server cert validation + a new EKU.  If
it's more complicated, spec-wise, and if you're implementing it to begin
with, then yes, I agree that it'd be better done in a subsequent
document -- better than specifying something now that may not be
implemented at all.

Don't misunderstand what I'm saying.  I think it's entirely reasonable
for start-tls' main deployment case to involve either pre-shared
self-signed server certs or even leap-of-faith learning of server certs
(though there's a sec. cons. related to leap-of-faith on a multi-user
system, but that's probably not germane to the common start-tls
deployment).

> it.  Which CA implementation are you thinking of?

OpenSSL supports both, arbitrary SANs and arbitrary EKUs, but arguably
it's much simpler for an administrator to get an EKU right than it is to
get a SAN that has complex structure (as id-pkinit-san does).

Oh, I suppose that's a great argument that we got it wrong with PKINIT
-- that we should have used RFC1964 principal name syntax instead of
using a SEQUENCE of realm and principal name (which is a SEQUENCE of
components).  But I think it's too late for this.  Now to add a new SAN
surely would be annoying to an OpenSSL CA admin issuing certs for
servers with both, start-tls and PKINIT.

I don't know enough about other CAs though.  Partly I'm parroting what I
remember from the PKINIT discussion.

But it definitely stands to reason.  Teach software about EKUs and every
additional EKU is just a matter of parsing an OID.  The same can't be
said about SAN types -- each one is unique (unless two or more SANs
share the same ASN.1 type but have different OIDs), or you punt and let
the admin do the hard work of dealing with SANs (like OpenSSL does).

> I assume you are only asserting your preference here?

Indeed :)

> than adding and checking both a SAN and an EKUs.

Interesting.  But I'm still not sure how adding SANs is simpler than
adding EKUs.  What am I missing?

> complexity and less specification reading involved.  If the pkinit SAN

PKIX is a large body of specs.  You don't have to read everything, but
you don't get to throw out large portions and do what you feel like
(well, yes, you do get to do that, but the IETF might not go along with
even Informational then).

> valid in the context of the other protocol.  Evaluating the semantics of

There is always the risk of bugs.  I don't see that as sufficient
rationale to reject an established specification.

> pkinit to get the complete picture.  If krb5starttls use a separate SAN,

Just because id-pkinit-san has "pkinit" in the name?  I think it's
entirely reasonable to have start-tls normatively reference only the
certificate validation portion of PKINIT, with the modification that the
start-tls EKU applies instead of the PKINIT EKU.

But maybe your objection is to id-pkinit-san's complexity?  That I buy
(see above comments about OpenSSL).

> document, and anyone evaluating use of id-krb5starttls-san can ignore

But anyone implementing both has more work to do.  And you have to write
more text than you'd have to otherwise.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 18 Mar 2009 09:52:07 -0400

>    steal credentials then the attacker might get something);

Actually, this one is rather worrisome.  Authentication of the AS, 
traditionally by TGT validation, is necessary to prevent a classic attack 
(the Zanarotti attack) in which an attack gains access to a system by 
presenting a fake password _and_ impersonating a KDC.

> remember from the PKINIT discussion.

... much of which is about what CA's are willing to do, and part of this is 
due to the purpose and meaning of SAN's and EKU's.  An EKU is just an ID 
for a particular usage; it means the certificate may be used for some 
purpose.

A SAN is _not_ intended to mean the certificate can be used for a 
particular purpose.  It is used to indicate that the certificate names a 
particular entity.  Using a new SAN is problematic for CA's not only 
because of the effort required to make the software capable of encoding it, 
but also for policy reasons -- including a SAN means the CA is certifying 
that the public key named in the certificate belongs to the entity named by 
the SAN, which a CA cannot do unless it understands the SAN and has a 
policy in place for determining whether the assertion is actually true.  It 
is much easier to get a CA operator to drop an extra EKU into a certificate 
than to teach them about the meaning of a SAN and get them to adopt a 
policy allowing issuance of certificates using it.

As I said before, giving EKU-like semantics to the Kerberos principal name 
SAN in PKINIT was a compromise and an anomaly; we should not do it again.

>>>>   - one cert, both protocols -> PKINIT/KRB5STARTTLS SAN,

But that doesn't work; such a certificate _cannot_ be used with 
krb5starttls, because it contains an Extended Key Usage extension 
indicating that it may only be used for PKINIT.  This is not a matter of 
opinion or how we decide to define the krb5starttls protocol; this behavior 
is required by RFC3280 and must be implemented consistently by all relying 
parties in order to meet the intent of the issuing CA to restrict the use 
of a certificate to only those usages listed in the EKU extension.

> start-tls EKU applies instead of the PKINIT EKU.

Actually, I think it would be fine for krb5starttls to _copy_ the relevant 
portion of PKINIT, normatively referencing it only for the definition of 
the Kerberos principal name SAN.  Note that we fully expect that other 
specifications will have the same reference; in fact, PKINIT contains this 
definition only because it was the first user to be ready.

> (see above comments about OpenSSL).

It seems like that would have been an argument for when we were defining 
id-pkinit-san.  IIRC we also specifically chose _not_ to define a second 
SAN for KDC's, for some of the same reasons I'm now arguing against 
krb5starttls defining a new SAN (but not all of them; one of the arguments 
I'm making now is that a SAN is for naming something, not for indicating 
permitted usages, and that there is already an established way to name the 
thing you want to name).

-- Jeff