Subject: I-D ACTION:draft-weber-krb-wg-kerberos-pfs-00.txt

From: [email-masked]
Date: Mon, 28 Jul 2003 11:06:11 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Kerberos Perfect Forward Secrecy
	Author(s)	: J. Weber
	Filename	: draft-weber-krb-wg-kerberos-pfs-00.txt
	Pages		: 8
	Date		: 2003-7-28
	
This document defines the use of a Diffie-Hellman exchange in
Kerberos, both with AP-REQ/AP-REP (in order to protect against
passive eavesdropping of a session by the realm administrator), and
as a preauthentication method (in order to prevent a passive
eavesdropper from capturing ciphertext with which an offline
dictionary attack can be mounted).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-weber-krb-wg-kerberos-pfs-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-weber-krb-wg-kerberos-pfs-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-weber-krb-wg-kerberos-pfs-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 29 Jul 2003 02:40:38 -0400

After I submitted the perfect forward secrecy internet-draft, I got my
hands on a copy of Ferguson and Schneier's ``Practical Cryptography'',
which mentions that it is reasonable to ``publish g^x (mod p) in the
digital equivalent of a phone book''.

I think it would be best if diffie-hellman preauth for Kerberos is
done in such a way that the server's public diffie-hellman key changes
relatively infrequently (perhaps on the order of once a year, but
obviously the exact timing should be determined by the realm
administrator; and you probably want to keep old keys around and
usable indefinitely when you do key changes).  Doing this means that
the client has several options:

1) You can do truely anonymous diffie-hellman, and the client can
   request the server's public key each time it wants to do
   authentication.

2) You can do something very much like the known_hosts mechanism in
   ssh, and blindly accept the server's public key the first time you
   connect to the kdc from a given workstation as a given user, and
   used the cached value after that.

3) You could distribute the key along with the config files if you're
   concerned about a man in the middle attack the first time you
   connect to the KDC.  This option should be quite usable for sites
   that have their own software distribution infrastructure for
   getting consistent software onto a large collection of identical
   workstations.

I suspect that changing the draft to use a kvno rather than a hash of
the public diffie-hellman key makes sense if key changes are going to
be very infrequent.

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 29 Jul 2003 13:27:33 -0400

>[...]

I can only say that if we're resorting to this kind of key management for
diffie-hellman preauth, I for one would never deploy it, since it would
leave us in the same key management hell that SSH is in.  Just my $0.02.

--Ken

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 29 Jul 2003 16:09:56 -0400

> leave us in the same key management hell that SSH is in.  Just my $0.02.

What sort of thing are you interested in deploying?  Anonymous
diffie-hellman?  Something else?

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 29 Jul 2003 22:07:13 -0400

>diffie-hellman?  Something else?

"Something else", which doesn't involve any new key management issues.
We're doing some stuff now with hardware preauthentication tokens that
involve the mixing out the token output with the user's password; that
seems to work well (the tokens are more of a political solution than
technical one, but since they're a requirement we might as well get
some usefulness out of them).

--Ken

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 29 Jul 2003 23:27:52 -0400

> some usefulness out of them).

How much entropy do you get from the token output?

(I suspect that there may be some cases where doing some sort of
diffie-hellman combined with a token and a password gets you somewhat
better protection against some attacks than just the token and
password.)

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 29 Jul 2003 23:48:57 -0400

>How much entropy do you get from the token output?

In the ones we're using, about 32 bits.  It seems to reasonably
protect against offline dictionary attacks (at least makes the job
much harder).

>better protection against some attacks than just the token and

Well ... in my mind there's a graph that has on one axis, "Security",
and the other axis has "Usability".  I have to try to maximize
both.  If D-H involves storing client-side some server public key,
"Usability" goes _way_ down (added into this mix is a requirement
for regular server rekeying).  I guess my point is that I'm not
willing to have an increase in security with a large decrease in
usability, especially when it's easy to get a handle on usability
decreasing, but it's harder to get an idea on how _much_ you've
increased security.  If we can get D-H into the mix without any
extra state on the client, then I'm happy.

As always, just my $0.02.

--Ken

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 30 Jul 2003 12:51:55 -0400

> protect against offline dictionary attacks (at least makes the job

One case I'm curious about is how easy it is to attack a user's
Kerberos credentials in the case when someone uses a password for
access to some insecure website all the time (perhaps a webmail site),
and same password as their kerberos password used in conjuction with a
token, assuming that you can successfully get the website password
with a packet sniffer.  (Because we all know that some users will
conflate their secure and insecure passwords, even when told to not do
that.)

I know the ~4 year old computer I normally use can iterate over 22
bits worth of DES keys in an hour.  A higher-end, newer computer could
probably crack 25 or 26 bits in an hour, and if you got 16-32 such
computers working together, you could probably crack 30 bits in an
hour.  (Consider also that DDoS attacks have taught us that
troublemakers are entirely capable of getting access to 100 computers.)

So if the ticket granting ticket the client gets back from the KDC is
effectively protected by a 32 bit key, those resources likely will let
you crack the key used to protect the TGT within a couple hours,
assuming you're using the DES string to key function.

However, if the entropy from the token is being fed through the AES
string to key function, an offline attack may be marginally more
difficult.  Given that my ~4 year old computer can try about 1300
passwords per second with DES, the extra effort to process the
iteration count is probably on the order of 1000 to 5000 times more
work.  But an attacker who can consistently eavesdrop for a year and
keeps trying may succeed eventually.

I'm assuming here that the token is strong enough that it is
effectively impossible to do anything better than try to brute force
each TGT that is issued.  Without knowing details of the token, I
don't know if that's true or not.

> for regular server rekeying).

I get the impression that if you change the D-H key extremely
infrequently, and generally allow each key to work for several years
after you generate a new key, you are likely to get better security
than if you are constantly accepting an unauthenticated D-H key.  I'm
not sure exactly what requirement you see for regular server rekeying,
so it's hard to respond to that usefully.  (And I'm assuming that you
pick a value of several years such that your clients machines will
have all been replaced before you throw away an old key, or
something.)

> I guess my point is that I'm not

What I have in mind with the protocol I'm proposing is that sites that
want to not store state on the client ought to have that option,
although whether that option is available is to some extent an
implementation issue.

(I've also not yet written up any spec on using d-h with SAM, although
I suspect that it will eventually be worthwhile to do so.)

And I'm also not disagreeing that it's important to minimize the
usability impact of any security improvement.  But I'm skeptical that
passwords by themselves are ever really going to be secure, and I'm
skeptical of tokens that only do 32 bits.

Once we have PKINIT, I think investigating the use of the usb crypto
frobs that do 1024 bit (and sometimes 2048 bit) RSA with Kerberos
might be worthwhile.  If it is done right, I suspect that is likely to
be more secure than the tokens you are describing.

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 30 Jul 2003 13:25:44 -0400

>conflate their secure and insecure passwords, even when told to not do

I admit that the hardware preauth token isn't really useful in this
scenario, but you're running up against limitations in the device display
and against the "Usability" axis again.  But if the plaintext password
has been sniffed, the game is instantly over for the non-hardware
preauth case, so I don't know that I feel _too_ bad about that.

We fight the conflating the secure and insecure passwords with a fairly
vigorous password quality checker and regular password expiration; this
assumes a user isn't going to change all of their insecure passwords to
match their secure password when it expires.

>don't know if that's true or not.

It's a straight DES encryptor with a DES key stored on it, so I think
it would take a brute force on the token DES key to attack it (newer
modules will do 3DES and AES, but you're still limited into probably 32
bits of token output).

>have all been replaced before you throw away an old key, or

"Bad assumption".

Our requirements are server rekeys every three months.  And I see
client hardware being used for 5-7 years.  Like I said, anything that
involves client-side state is a non-starter.

>skeptical of tokens that only do 32 bits.

Well, this is part of the problem.

I'm not sure I know what "secure" means in this context.  I think
passwords plus token are "secure enough", but that's just a gut feeling.
But I'm not sure there is anything more than "gut feelings" here.

>be more secure than the tokens you are describing.

Unfortunately, there are serious technical challenges to anything like
a usb crypto frob, so I'm still skeptical of them right now.

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Jul 2003 10:53:54 -0700

> involves client-side state is a non-starter.

What if the client-side state is optional and automatically updatable?

When the KDC's response advertises a public key that a client does not
know the client can warn the user (or just log) yet proceed and if
pre-auth succeeds then it can cache the public key for the next time.

The initial case forces an attacker to impersonate a KDC or be a MITM
but leaves it only with material it can attack off-line (which today the
attacker can get by snooping).

The non-initial case foils the attack.

The client-side state is self-updating and you can monitor the logs.

[Aside: We've previously discussed about using anonymous DH exchanges to
	fortify password-based pre-auth; I think Joel's suggestion of
	having a public KDC DH parameter may be an improvement over
	that.

	But I am opposed to adding PFS to AP exchanges outside the
	context of extensions.  I'm open to arguments for why we need it
	now, now, now and can't wait the year or two, or even three it
	will take to get extensions specified/implemented.  And remember,
	applications can add PFS on their own; also, we really need to
	revise the GSS-API so that PFS can be requested / checked for.]

Cheers,

Nico
--

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 30 Jul 2003 14:16:35 -0400

>What if the client-side state is optional and automatically updatable?

That sounds reasonable ... but I have a few questions/comments about
the details (let's put aside questions of "where does this state get
stored" for now).

>pre-auth succeeds then it can cache the public key for the next time.

The problem I have with displaying a dialog is that the average user won't
understand it, so it either gets ignored or generates a help desk call.
I'm not sure which one is worse.

In terms of logging it on the client ... I'm not sure where we could log it
to, since in many cases these machines aren't under our control.

>The non-initial case foils the attack.

I think I missed something ... how is the new KDC DH parameter updated
securely?  Or is are you treating this as "initial"?

>	context of extensions.

No argument here.

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Jul 2003 12:17:57 -0700

> the details (let's put aside questions of "where does this state get

If it doesn't get cached/stored then it's the same as using anon DH to
protect pre-auth, which we've discussed before and which Jacques
Vidrine, IIRC, was working on, and which is susceptible to a MITM +
dictionary attack, but not susceptible to passive attacks (which
pa-enc-timestamp suffers from now).

> I'm not sure which one is worse.

So don't warn.  See above.

> to, since in many cases these machines aren't under our control.

Still, in such cases yo're no worse off than with anon DH protection for
pa-enc-timestamp.  And if your users log in to your realm from other
realms' computers, well, you can't make sure there's no trojans there...

> securely?  Or is are you treating this as "initial"?

If you don't know the DH parameter (you didn't have it cached) you
proceed as with anon DH protected pre-auth and if that succeeds, and if
you are willing to assume that no MITM could crack the password in
real-time, then cache the KDC's DH parameter.

Basically, your users' password will then be safest when used only on
your clients that can cache KDC public DH parameters.  But in the base
case this approach is no safer than anon DH protected pre-auth.

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 30 Jul 2003 15:47:30 -0400

> involves client-side state is a non-starter.

I still don't understand why my proposal of keeping your
diffie-hellman keys active for 7 years is worse (less secure) than
doing truely anonymous diffie-hellman, or doing something that doesn't
involve diffie-hellman at all.  I'm not proposing to stop using any of
the keys you would otherwise be using, just using diffie-hellman in
addition to the other keys.

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 30 Jul 2003 15:52:07 -0400

>     	  revise the GSS-API so that PFS can be requested / checked for.]

I'd like to see PFS be possible for password changes without needing
to do it specifically in the context of the password change protocol.
Given that I have come to realize that PFS preauth probably solves
this problem, and in some respects is better than doing PFS in the
AP-REQ, I don't think I really care that much exactly when PFS in the
AP exchange happens.

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 30 Jul 2003 15:56:28 -0400

>addition to the other keys.

Uh, did you miss the part about "rekey every three months"?  That also
means, "stop using the old keys".  I never said it was less secure, just
less usable.

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Jul 2003 12:56:36 -0700

> AP-REQ, I don't think I really care that much exactly when PFS in the

I have no problem with this approach.  As long as PFS is not a
requirement for the change password protocol (else we'll get bogged
down) and it can be added later, whether in the AP exchange or, because
in this situation the service runs on the KDC[1], in the KDC
exchanges[2].

[1] Technically, the change password protocol could run off the KDCs.

[2] PFS could remotely be useful in the TGS exchanges, depending on what
    people end up stuffing into "ticket extensions."  In any case, PFS
    in the AS exchange is mostly useful in that it involves DH - an
    improvement over pa-enc-timestamp (by locking out passive attacks).

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 30 Jul 2003 16:41:02 -0400

> means, "stop using the old keys".  I never said it was less secure, just

I did see that you said ``rekey every three months'', but I don't
recall seeing an explaination of what problem you are trying to solve
by rekeying every three months.

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 30 Jul 2003 16:37:51 -0400

> real-time, then cache the KDC's DH parameter.

Consider the behavior where the client always caches the KDC's DH key
the first time it connects, and then always uses that rather than
asking the KDC for a new key.  With a bit of luck and a bunch of
documentation (and training the helpdesk people appropriately), it may
be the case that such an attack would ultimately cause the user to
wonder why Kerberos wasn't working for them, and the helpdesk could
ask the user to read the numbers in the keyfile, and when it is
discovered that they don't match, you'd at least know what happened
and could get the user to replace the key and change their password.
(Of course, then the user will tell their friend when it happens to
their friend ``well, they told me to delete this file, and then they
made me change my password.''  and their friend will say ``but I don't
want to change my password; it's a nice easy one.  maybe I'll just
delete that file and not call the helpdesk.''  But if MitM attacks are
sufficiently uncommon, this may not really come up in the real world.)

I'm not sure if this is the best mechanism for detecting a MitM attack
or not.

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 30 Jul 2003 22:00:10 -0400

(You don't need to send me a seperate copy)

>by rekeying every three months.

I never said that I was trying to solve a problem.  I was just giving an
example of a real policy (I didn't come up with it) that I have to deal
with.

--Ken

---

From: Sam Hartman <[email-masked]>
Date: Thu, 31 Jul 2003 18:11:38 -0400

>>>>> "Joel" == Joel N Weber <[email-masked]> writes:

    >> If you don't know the DH parameter (you didn't have it cached)
    >> you proceed as with anon DH protected pre-auth and if that
    >> succeeds, and if you are willing to assume that no MITM could
    >> crack the password in real-time, then cache the KDC's DH
    >> parameter.

    Joel> Consider the behavior where the client always caches the
    Joel> KDC's DH key the first time it connects, and then always
    Joel> uses that rather than asking the KDC for a new key.  With a
    Joel> bit of luck and a bunch of documentation (and training the
    Joel> helpdesk people appropriately), it may be the case that such
    Joel> an attack would ultimately cause the user to wonder why
    Joel> Kerberos wasn't working for them, and the helpdesk could ask
    Joel> the user to read the numbers in the keyfile, and when it is
    Joel> discovered that they don't match, you'd at least know what

Any key management that does not support rekeying automatically is
not acceptable to me from a deployment standpoint.