Subject: Re: ["Frank O'Dwyer" <[email-masked]>: Re: Kerberos login sniffer and cracker for Windows 2000/XP]

From: Jeffrey Altman <[email-masked]>
Date: Mon, 2 Dec 2002 11:50:06 EST

> On Mon, Dec 02, 2002 at 11:20:16AM -0500, Jeffrey Altman wrote:
> > Nico:
> > 
> > The cases I am describing above involve situations where there is no
> > "host key" shared between the client's machine and the KDC.  If the
> > clients machine belongs to CC.COLUMBIA.EDU and there is no cross realm
> > with ATHENA.MIT.EDU; and I need a TGT for ATHENA.MIT.EDU I cannot use
> > the host key assigned to my machine in the request to the
> > ATHENA.MIT.EDU realm.
> 
> I understand.  The case of public, key-less kiosks cannot be addressed
> with DCE RFC26 or any variation of it.  My point is that this should not
> stop us from specifying a solution based on the DCE RFC26 concept.

There is consensus that a DEC RFC26.0 solution is one of the MUST
implements.  We are discussing the need for smb's ADH proposal.

> > Nor in the case of the vast majority of machines at University
> > campuses can I assume that there are host keys assigned to the vast
> > majority of the computers used by end users.  Most computers are
> > managed by local end users (students, faculty, staff) and not by the
> > central computing authority.
> 
> Clients managed by end users, but which are not public kiosks, could be
> given host keys (it's akin to giving a user a very long, random password
> for them to use along with their normal password and which the user
> stores in a smartcard or in her computer's hard disk and which they
> never have to actually type in).

Client systems and departmental systems are NOT managed.  They are
frequently compromised by viruses; patches are not applied promptly if
ever; etc.  It is not acceptable to me for us to count on end users
maintaining the integrity of their systems well enough to allow a long
term secret to be stored on their hard disk.

Additionally these client machines are frequently transient in
nature.  They do not have fixed or even long term names.  The last
thing I want to do is require KDC administrators to be forced to
register all of the end user machines that communicate with their
KDC.   It is just not feasible.

The ADH solution therefore seems to me to be a MUST implement.

 Jeffrey Altman * Volunteer Developer      Kermit 95 2.1 GUI available now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP, and 
 [email-masked]               OpenSSL.

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Mon, 2 Dec 2002 12:22:08 -0600

On Mon, Dec 02, 2002 at 11:50:06AM -0500, Jeffrey Altman wrote:
> implements.

I don't think there is.  I think many here recognize that the DCE
RFC26.0 approach is fatally flawed.

The `only' advantage DCE RFC26.0 seems to have going for it is that it
is already specified.

On the other hand, ANY solution involving public key cryptography and
(a certified public key for the KDC) will gain you everything you
might get with DCE RFC26.0, and it will not have these flaws.

> term secret to be stored on their hard disk.

Exactly, thank you.

> KDC.   It is just not feasible.

Exactly, thank you.

> The ADH solution therefore seems to me to be a MUST implement.

Given that we cannot at this time mandate EKE-like schemes nor SRP, I
agree.  [MUST in some future document, not in Kerberos clarifications.
I think it is too late )-: ]

Cheers,
-- 
Jacques A. Vidrine <[email-masked]>          http://www.celabo.org/
NTT/Verio SME          .     FreeBSD UNIX     .       Heimdal Kerberos
[email-masked]     .  [email-masked]  .          [email-masked]

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 02 Dec 2002 13:34:20 -0500

>might get with DCE RFC26.0, and it will not have these flaws.

You're just pushing the flaws into a different problem.  You need to
somehow securely distribute a public key for the KDC.  How do you do
that?  Seems like a lot of hand waving to me.  Admittedly, it's a single
key instead of a per-workstation key, but it's been my experience that
the "secure distribution" is really the tough nut to crack.

I'm not saying that a PKI based solution is a bad idea to specify for
people that want to interoperate, but I can't see the harm in doing DCE
RFC 26.0; it could solve a problem for a number of people.  And
speaking as a WG participant, I've always gotten the impression that
there was a consensus for it being at least a SHOULD, and possibly a
MUST.

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 10:39:13 -0800

> RFC26.0 approach is fatally flawed.

It is not fatally flawed - it is merely not usable by a significant
slice of the Kerberos community, which does not a fatal flaw make.

> The `only' advantage DCE RFC26.0 seems to have going for it is that it

No, its advantage is ease of specification and implementation coupled
with the fact that many deployments involve clients that have host keys,
thus resulting in ease of deployment.  It is not a panacea, but it's a
start.

> might get with DCE RFC26.0, and it will not have these flaws.

ADH allows MITM attacks - DCE RFC 26 does not.

I'd might be willing to agree to ADH with MUST implement, but subject to
per-realm KDC policy and DCE RFC 26-style pre-auth with MUST implement
subject to client key availability.

If we take too long to reach a consensus or specify a workable solution
and if users get desperate for a solution then we risk inviting
implementors to design and deploy their own, non-interoperable
solutions.  The record for this WG is such that I don't think anything
more complicated than DCE-style pre-auth is likely to go anywhere in
less than a year at best, years at worst.

I see no reason why something like DCE RFC 26 should not be specified.
Its uselessness to some does not make it useless across the board.

> I think it is too late )-: ]

I think that the DCE RFC 26 approach is simple enough to specify that it
could conceivably be folded into clarifications.  ADH, EKE, SRP, et. al.
cannot possibly be folded into clarifications at this point.

Cheers,

Nico
--

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Mon, 2 Dec 2002 13:12:25 -0600

> slice of the Kerberos community, which does not a fatal flaw make.

Words, words, words. :-)   We have different views of clients, I guess.

> thus resulting in ease of deployment.  It is not a panacea, but it's a

First, the protocol may be easy to implement, but I think the cost of
implementing the client-machine-side details has been ignored.  With
this approach, the client suddenly needs additional privileges and
that must be managed with care.

Second, personally I do not find DCE RFC26.0 on-the-wire protocol any
easier to implement than other potential solutions.

> ADH allows MITM attacks - DCE RFC 26 does not.

You might re-read what I wrote :-)  I was not referring to ADH.

> subject to client key availability.

That seems backwards to me.  Why would one burden implementors
with the necessity to implement a solution that many (IMHO, most)
organizations cannot use,   as a condition before implementing a
solution that any organization can use?
If anything, something like ADH should be a MUST, while things that
require additional keying should be a MAY (or perhaps SHOULD).

> solutions.  

This is also what will happen also if we provide a solution that
cannot be used everywhere.

> The record for this WG is such that I don't think anything

I do not think DCE RFC 26.0 should be put in clarifications, either --
certainly not as a MUST.  I do not think any extension that breaks
the basic assumptions that the client needs only his name and password
should be a MUST.

Gotta catch a plane.  I'll try to start some more discussion about the
other alternatives during the week.  Thanks for putting some details
behind this (DCE RFC 26.0) proposal.

Cheers,

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 12:11:06 -0800

> Words, words, words. :-)   We have different views of clients, I guess.

"Kerberos is not useful to everyone, therefore Kerberos is fatally flawed."

See?

> that must be managed with care.

No, no, this is easy to implement and deploy in environments where
clients already have keys.  This is the common case in Solaris and
Windows Kerberos environments.

> easier to implement than other potential solutions.

I am not proposing DCE RFC26.0 as it stands.  See my actual proposal
please (one variation requires no new ASN.1 type definitions!).

> You might re-read what I wrote :-)  I was not referring to ADH.

Asymmetric crypto approaches to solving this problem:

 - realms have certs, clients know public keys (does not solve your key
   distribution problem, though it does simplify it)

 - EKE, SRP, etc... (patents, patents)

 - ADH, vulnerable to MITM/dictionary attacks

I assume that, like me, you'd prefer if the patent issues disappeared so
we could use EKE or SRP or some variant thereof.  The other two
solutions are less than ideal.  The DCE solution is ideal where clients
have keys.

> solution that any organization can use?

I'm not ready to make any statements about what sort of Kerberos
environment is most prevalent - I simply do not have the information at
hand.

I don't believe that an MITM/dictionary attack on the ADH approach is so
much harder than sniffing that it is worth specifying while not
specifying the DCE approach at all.  I think there's a place for both
approaches and I do not wish to see either dropped altogether.

> require additional keying should be a MAY (or perhaps SHOULD).

No, the KDC should be required to support both, the clients should be
required to implement either.

> cannot be used everywhere.

No, we should specify two solutions (because we cannot specify EKE/SRP),
each at their own pace, otherwise we'll wait a long time to get a
solution.

> the basic assumptions that the client needs only his name and password

Certainly, whether or not to require the use of one or another
technology which is more secure than PA-ENC-TIMESTAMP ought to be a
per-realm policy issue - the RFC ought to dictate support, but not
actual use for these alternatives to PA-ENC-TIMESTAMP.

> behind this (DCE RFC 26.0) proposal.

Thanks.  Have a safe trip.

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 03 Dec 2002 14:48:31 -0500

My two cents:

No solution will be adequate for everyone.  If we're lucky, perhaps
two or three approaches can cover 99% of everyone's needs.

The managed-client case is common enough (e.g., Microsoft domains)
that I think something based on DCE RFC 26 is highly desirable.  In
fact, some time ago, John Brezak had intended to write up a proposal.

However, there are probably environments where it does little or no
good, so making it a MUST may not be appropriate.  Making it a SHOULD
may be best.  (IIRC, "SHOULD" means "do it unless you've got a good
reason not to", and "our environment can't store host keys"
+ "lack of code space" would probably qualify as a good reason.)

The root-access issue is, I think, unimportant.  It's an
implementation detail.  A UNIX login process running as root won't
have a problem.  A Windows login session probably won't either.  A
UNIX kinit would, since we don't want it to be setuid, but some sort
of IPC (server listening on a socket, or pipe to a tiny, dedicated,
setuid helper program) would get around that.

However, we should make sure that an attacker logging into a host
(thus knowing the user's -- his own -- key) can't determine the host's
key, either through breaking the software or by cryptographic
analysis.  (I haven't looked at DCE RFC 26 in a while.  It's probably
fine.  I just bring it up because it's better to look *again* than to
make assumptions.)

If someone really thinks the root-access issue is important, the only
other solution I see offhand is to give the user's processes access to
only part of the crypto information -- for example, one half of a
public/private key pair.  (Perhaps the KDC holds the other half, and
the registration was done as root, even automatically, using the host
key for protection.)

As for the more general case without using a host key, I'd also remind
people of the LEAF-based proposal John Brezak and I were looking at a
while back, and I outlined in email on 12 March 2002.  Neither of us
(well, as far as I know) has taken it any further than the discussions
on this list months ago, but I outlined a one-round-trip exchange that
requires no transitory state to be stored on the KDC.  It does require
one public-key encryption and decryption, and requires the
availability (or, in an extended form, the ability to verify, such as
by fingerprint) a public key for the KDC.

If people want to put out an Informational RFC on using SRP as a
Kerberos preauth scheme, I've got a very rough draft based on
discussions with Tom Wu, Tom Yu, Jeff Altman, a while back.  But
unless we can find an option that doesn't have patent problems, I
think the other two types of approaches we've been discussing are our
best bets.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Dec 2002 12:04:03 -0800

> My two cents:

...
> + "lack of code space" would probably qualify as a good reason.)

When I said that this should be a MUST, earlier, I meant, and thought
I'd made clear, that KDC support for the feature would have to be a
MUST.  For clients this should be a MAY or a SHOULD.

...
> fine.  I just bring it up because it's better to look *again* than to

If the host has a key and an attacker can break into the host through
software flaws then the attacker will have the key.  Kerberos says
nothing about local security.

Cryptanalysis is another issue.  In general, when we let some user see
another's tickets (as in u2u, for example), we give them some ciphertext
on which to try to cryptanalize.  And if we give them an AP-REQ they get
a bit more ciphertext.  And all this ciphertext is going to contain some
known plaintext interspersed with unknown plaintext.  A sniffer can
always get at the very same ciphertext, but with this approach we just
hand it to the user, but user-2-user Kerberos also requires ciphertext
sharing, so it must be ok. (right?) :)

...
> by fingerprint) a public key for the KDC.

This approach has been mentioned here in the past few days.

> think the other two types of approaches we've been discussing are our

I think the DH w/ key combination approach that Sam suggested is another
possibility.  That approach has a detectable MITM attack, which, being
detectable, is tolerable.

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 03 Dec 2002 16:47:58 -0500

> nothing about local security.

True.  But the whole "setuid program" business that was brought up is
about local security.

> sharing, so it must be ok. (right?) :)

If it's using a ticket's session key, that's probably okay.  (Though
it should be a ticket used one time only, or a subkey.)  If it uses
the host's key directly, we should be concerned.  If I can use a
ticket of my own to invoke this preauth mechanism and get back
something encrypted in your long-term key, we should worry a lot.

> detectable, is tolerable.

Yes, sorry, three other approaches.  I've lost count. :-)

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Dec 2002 14:28:37 -0800

> True.  But the whole "setuid program" business that was brought up is

Nonetheless, any implementor can botch local security anytime; this is
not new.  So your concern may be good to place in a "Security
Considerations" section of any spec we end up producing about this, but
otherwise should have no further bearing on the matter.

> something encrypted in your long-term key, we should worry a lot.

*nod*

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 03 Dec 2002 17:38:20 -0500

> otherwise should have no further bearing on the matter.

Yes, but if I don't have to run your code as root (or setuid), then I
don't care quite as much if your code sucks.  As soon as you _require_
adding that setuid bit, you now require that ALL CODE under that app
be pristine, because it is now inside your security barrier.

Sure, it's just a matter of implementation, but it's a _new_ change
that didn't exist before.  Is it _wrong_?  I don't have an answer.
However, it certainly makes me a bit uncomfortable...  It's certainly
a _change_ from the status quo..

If nothing else, there needs to be a clear statement about the
ramifications of using this method.

OTOH, as there are other methods that are aguably better (work in more
situations and provide an arguably equivalent security), I see nothing
wrong with requiring KDCs to implement both DCE-RFC-26 and AuthDH, but
requiring clients only implement AuthDH.

-derek
-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Dec 2002 14:43:35 -0800

> be pristine, because it is now inside your security barrier.

We've been over this.  Setuid is an implementation detail and there are
ways to implement this without setuid.

> ramifications of using this method.

Again, "Security Considerations."

> requiring clients only implement AuthDH.

I see nothing wrong with this either.  Do we have consensus on this?

Cheers,

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 03 Dec 2002 17:52:03 -0500

> ways to implement this without setuid.

Yes, this is an implementation detail, but one that lots of people get
wrong.  As far as I can tell there is no way to implement DCE-RFC-26
without help from root.  Whether it means kinit is setuid, or there is
a root "kinitd" that kinit talks to via some local IPC, it still
requires root priviledges.

If you can show me a way to implement this without some hook into
root's space and without giving users access to the keytab I'd be very
happy to listen (and will drop my objection).

-derek

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Dec 2002 14:56:21 -0800

> happy to listen (and will drop my objection).

Is it an objection, as in you'd never approve of DCE RFC 26 -like
pre-auth?  Or is it a comment you wish to see in the Security
Considerations section of some document?

And yes, DCE RFC 26 involves crossing a priviledge barrier, one way or
another, for the typical user to be able to use DCE RFC 26 pre-auth (the
other user need not be root, but certainly must have access to a
host-specific key).

Nico
--

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Tue, 3 Dec 2002 18:13:00 -0600

On Tue, Dec 03, 2002 at 02:48:31PM -0500, Ken Raeburn wrote:
> while back, and I outlined in email on 12 March 2002.  

Thanks for the reminder!  I'd forgotten about it, and I just re-read
your outline.  If this approach can be used with-or-without client
access to a public key (or fingerprint thereof), then I think it is in
the same ballpark as DH with optional half-certification.  It seems to
have some further interesting properties as well.

Do you happen to have the original reference for SPX and/or LEAF
handy?

Cheers,

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 03 Dec 2002 21:32:20 -0600

> I see nothing wrong with this either.  Do we have consensus on this?

No, not yet. The question is still do we need both in the KDC.
Can a AuthDH protect against a MITH, and handle 99% of the cases.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 03 Dec 2002 22:37:44 -0500

> Do you happen to have the original reference for SPX and/or LEAF

The one I found is: Stephen H. Brackin, "Automatic Formal Analyses of
Cryptographic Protocols",
http://www.arca.com/projects/docs/brackin/nissc96u.pdf.  Google is so
useful sometimes. :-) (I'd love to see someone do an analysis of
Kerberos 5, especially the effects of the preauth variants we've been
discussing....)

He references J. Tardo and K. Alagappan, "SPX: Global authentication
using public key certificates", in IEEE's Proc. of the Symposium on
Security and Privacy, May 1991, which I haven't found online so far,
but Brackin's paper incorporates the specification "taken almost
verbatim".

As I've said, what I've described really isn't LEAF, it's uses a few
of the ideas but lots of the public-key stuff has been thrown out.
For one thing, the LEAF protocol had at least three parties involved,
and multiple encryptions to avoid any party but the user having the
user's private key.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 03 Dec 2002 22:37:44 -0500

Ken

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 04 Dec 2002 08:53:35 -0600

DH is based on  X=g**x mod n and Y=g**y mod n where g and n are 
publicly known. But what if g and n where based on the user's key, 
and known only to the user and the KDC?

Then the MITH would not have access to g or n.

One way to generate g and n might be,
 n = largest prime less then k,(or (n-1)/2 ) is prime.  
 g = k - n; special cases like g=0 or g=1   

I came up with this last night driving home. It may have flaws,
or may even be patented. Any thoughts, especially on how to generate
n and/or g from the key.

Here is another one What about the "22.6 Fortified Key Negotiation"
as defined in "Applied Cryptography"  It looks like a MITM would
be detected, or would have to mount multiple MITM attacks to get
one password. 

--

---

From: Matt Crawford <[email-masked]>
Date: Wed, 04 Dec 2002 09:05:54 -0600

> And yes, DCE RFC 26 involves crossing a privilege barrier, one way
> or another, for the typical user to be able to use DCE RFC 26
> pre-auth (the other user need not be root, but certainly must have
> access to a host-specific key).

draft-ietf-krb-wg-hw-auth uses something remotely like this (a host's
service key standing in for the user's) but it happens only in the
telnet, ftp and ssh servers, which started out as root.  If a user
needs this method for a subsequent TGT, we give them a script which
does "telnet localhost" and saves the resulting new creds.

But you don't have to use the service key on behlaf of the user.
There could be a user-readable key for every (user, host)
combination.  The host principal could have kadmin ACL rights to
create such principals and their keytabs.  (Database bloat, but hey,
many environments can handle it.)

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Dec 2002 07:48:39 -0800

> or may even be patented. Any thoughts, especially on how to generate

Cool!

n has to be very large, which means key expansion of long term keys in
order to generate g and n from them.

Could g and n be generated independently of the long term key, kept
by the KDC and sent to the client encrypted in the client's long term
key?  The fact the (n-1)/2 should be a prime may allow a dictionary
attack on E(k)(g, n), but since n has to be very large the dictionary
attack might still be too expensive.  The EKE and related patents might
still apply, for all I know - though neither X nor Y are being
encrypted.

There's no MITM either way, whether g and n are derived from k or are
exchanged encrypted in k.

> be detected, or would have to mount multiple MITM attacks to get

Each MITM attack on fkn has a high probability of failing (and of being
detected).

I thought I remembered fortified key negotiation being discarded here.
Sounds like a decent approximation of EKE, without being EKE.

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 04 Dec 2002 11:45:20 -0500

> > or may even be patented. Any thoughts, especially on how to generate

Lots of time and effort usually goes into choosing "good" DH groups.
I don't think you could effectively choose one "on the fly".  You are
(more likely than not) going to achieve a sub-optimal generator, or
even worse, a non-prime n.

Even though it reaks of EKE, I think you're much better off folding
the long-term key into the DH shared-secret and using that to defeat a
MitM.  In other words, do a normal DH with a well-known (and proven
"good") g and p, and then send:

        Enc{K, TGT} where
        K = key-fold(K_dh, K_user)

Clearly only the KDC and User would be able to generate K, and a MitM
wouldn't.  If key-fold() is "strong enough" then there is enough
randomness in K_dh to protect against dictionary attacks.

> order to generate g and n from them.

Yes, this is certainly a problem..  But worse, the issue we're trying
to protect against is a dictionary attack.  If an attacker could
create a dictionary of passwords, then they can just as easily apply
that dictionary to this transform as they could to DES/3DES/AES/etc.

> key?  The fact the (n-1)/2 should be a prime may allow a dictionary

This doesn't help protect against dictionary attacks, which is why
we're trying to protect the long-term key in the first place.

-derek

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Dec 2002 08:57:57 -0800

...
> we're trying to protect the long-term key in the first place.

Yes and maybe no.  Clearly a dictionary attack is possible, but it
involves checking decrypted g/n pairs to see if they make sense.  If n
is large enough (and it has to be large) then checking that (n-1)/2 is
prime may sufficiently slow the attack; otoh, primality testing is not
so very expensive.  Hmmm, overall I wouldn't feel confident with this
approach.

Cheers,

Nico
--

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Wed, 4 Dec 2002 10:11:58 -0600

> or may even be patented. Any thoughts, especially on how to generate

Deriving n from the password is the PDM proposal (see Kaufman and
Perlan, ``PDM: A New Strong Password-Based Protocol'').  The SACRED WG
(and this WG at IETF 53) rejected PDM for the same reasons it rejected
SRP --- because it might be covered by patents.

Cheers,

---

From: Derek Atkins <[email-masked]>
Date: 04 Dec 2002 12:08:29 -0500

> so very expensive.  Hmmm, overall I wouldn't feel confident with this

No, all the attacker needs to do is verify that the decryption test
yields "known plaintext".  Unless you are sending raw bits (which is
unlikely), there is probably some amount of formatting that limits the
search.  For example, if you are sending g/n pairs as ASN.1 encoded
integers, an attacker can just look at the decrypted ASN.1 _first_ to
verify that the encoding "looks" right.  If I decrypt your
octet-string with a test-key and what I get back looks like an ASN.1
encoding of two integers of the right length, then there is a good
chance that I've found your long term key.

Note that this verification test is _fast_.

Also note that this verification test is _necessary_ in order for the
_REAL CLIENT_ to know they have the right key....

-derek

PS: It's a good concept in general, but there are issues.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Dec 2002 09:19:38 -0800

> chance that I've found your long term key.

Yes, (g, n) would have to be encoded in way which minimizes known
plaintext.  It gets ugly.

Nico

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 04 Dec 2002 11:42:37 -0600

Your right its PDM. I new it sounded too good. 

> SRP --- because it might be covered by patents.

Your right its PDM. I new it sounded too good. 

--

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 04 Dec 2002 14:52:03 -0500

I wrote:
>  (I'd love to see someone do an analysis of

As Jacques reminded me, there is at least one such paper out there,
and it's one I'd known about.  A preliminary version is available at
http://www.cis.upenn.edu/~scedrov/recent_papers.html:

    A formal analysis of some properties of Kerberos 5 using MSR (with
    F. Butler, I. Cervesato, and A. Jaggard). In: S. Schneider, ed.,
    "15-th IEEE Computer Security Foundations Workshop, Cape Breton,
    Nova Scotia, Canada, June, 2002", IEEE Computer Society Press,
    2002, pp. 175-190. Preliminary version [.pdf] [.ps] [.ps.gz].

Indeed, searching Google for "formal analysis" and "kerberos 5" gets
me multiple references to this paper, but not much else.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Dec 2002 23:31:57 +0100

> me multiple references to this paper, but not much else.

Especielly, none of the cryptographic suites have been proved secure
for integrity and privacy as far as I'm aware.  It would be nice if
the new AES suite would have been proved secure, like Jakob Jonsson's
proof of integrity/privacy properties in draft-housley-ccm-mode-01.txt.

---

From: "Marcus Leech" <[email-masked]>
Date: Fri, 06 Dec 2002 12:41:36 -0500

> randomness in K_dh to protect against dictionary attacks.
The MITM could conceivably use the TGT-requesting client as an oracle to verify
  guesses at K_user over very many protocol runs, since the *only* thing the
  MITM doesn't have access to is K_user, which is likely lowish entropy.

-- 
----------------------------------------------------------------------
Marcus Leech                             Mail:   Dept 8M70, MS 012, FITZ
Advisor                                  Phone: (ESN) 393-9145  +1 613 763 9145
Security Architecture and Planning       Fax:   (ESN) 393-9435  +1 613 763 9435
Nortel Networks                          [email-masked]
-----------------Expressed opinions are my own, not my employer's------

---

From: Sam Hartman <[email-masked]>
Date: Fri, 06 Dec 2002 12:51:59 -0500

>>>>> "Marcus" == Marcus Leech <[email-masked]> writes:

    Marcus> Derek Atkins wrote:
    >> 
    >> 
    >> Lots of time and effort usually goes into choosing "good" DH
    >> groups.  I don't think you could effectively choose one "on the
    >> fly".  You are (more likely than not) going to achieve a
    >> sub-optimal generator, or even worse, a non-prime n.
    >> 
    >> Even though it reaks of EKE, I think you're much better off
    >> folding the long-term key into the DH shared-secret and using
    >> that to defeat a MitM.  In other words, do a normal DH with a
    >> well-known (and proven "good") g and p, and then send:
    >> 
    >> Enc{K, TGT} where K = key-fold(K_dh, K_user)
    >> 
    >> Clearly only the KDC and User would be able to generate K, and
    >> a MitM wouldn't.  If key-fold() is "strong enough" then there
    >> is enough randomness in K_dh to protect against dictionary
    >> attacks.
    >> 
    Marcus> The MITM could conceivably use the TGT-requesting client
    Marcus> as an oracle to verify guesses at K_user over very many
    Marcus> protocol runs, since the *only* thing the MITM doesn't
    Marcus> have access to is K_user, which is likely lowish entropy.

Limiting the MITM to only guessing a small number of passwords per
protocol run would be an improvement if it didn't violate patents.

---

From: "Marcus Leech" <[email-masked]>
Date: Fri, 06 Dec 2002 12:59:26 -0500

>   MITM doesn't have access to is K_user, which is likely lowish entropy.
And, following up to my own message.  [Assume that I don't have KRB5 wired
  into my brain], but if "User" usually sends something like:

    E{K, "I am User and here is some low-entropy"}

    K being derived as you suggest

    K = Key_fold (DH_key, User_key)

Then you don't even need an Oracle, since the MITM already has DH_key. The MITM
  then has a nice offline way of computing User_key.

I think the proposals that make the modulii (and optionally, generator)for D-H 
  key-dependant are stronger, since they require a (slow) Oracle-based attack
  by the MITM, whereas a conventional D-H proposal, like the one you made earlier,
  allow the MITM to do an offline dictionary attack.

-----------------Expressed opinions are my own, not my employer's------

---

From: Derek Atkins <[email-masked]>
Date: 06 Dec 2002 13:11:09 -0500

Let me state for the record that I meant "Key_Fold" in the generic sense.
I actually considerd "DH_Key ^ User_key mod p" to be a reasonable Key-Fold
technique ;)

I believe that this would "slow" the attacker down significantly...

-derek

---

From: "Marcus Leech" <[email-masked]>
Date: Fri, 06 Dec 2002 13:14:37 -0500

> I believe that this would "slow" the attacker down significantly...
That's what Doug Engert proposed a few days ago, although the notation you use
  is different [unless I'm smoking crack again].

-----------------Expressed opinions are my own, not my employer's------

---

From: Derek Atkins <[email-masked]>
Date: 06 Dec 2002 13:54:51 -0500

>   is different [unless I'm smoking crack again].

Yes, I know.  I proposed it a day earlier in person with Sam and Tom.
And yes, my notation is slightly different.  I agree that chosing the
Key-Fold algorithm is part of the means of detecting a MitM.  Although
it does mean that detecting the difference between "bad password" and
"you're being attacked by a MitM" might be hard to distinguish.

-derek