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 8:48:14 EST

I'm not sure why a TLS profile would be required.  The rule would
simply be that you cannot use the KRB5 ciphers as a means for
protecting the TGT request.

In any case, I do agree that Kerberos should be able to stand on its
own and so at the very least smb's adh approach should be implemented
as a MUST solution.

I have a feeling that others might want to implement TLS as a SHOULD.

 - Jeff

> Sam Hartman wrote:
> >>>>>>"Jeffrey" == Jeffrey Altman <[email-masked]> writes:
> 
> <snip>
> 
> > 
> > I don't want to require the complexity of TLS; Kerberos is complex
> > enough without it.  Also, as it currently stands, Kerberos provides
> > its own security infrastructure; I think this is an important property
> > of the base protocol.  In addition, using TLS would require TCP.  I
> > think being able to do a Kerberos AS exchange in two or fewer round trips  is
> > important.
> 
> I agree. Also one would have to profile TLS for this use since
> kerberos can be used as a crypto mech inside TLS ...
> 
> 	leifj
> 

 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: Ken Hornstein <[email-masked]>
Date: Mon, 02 Dec 2002 11:10:27 -0500

>While I do not wish to see TLS become the solution to the problem at
>hand, I see no reason why, if we were to use TLS, we could not use the
>TLS Kerberos cipher suite to protect KDC exchanges.

I was under the impression that the TLS Kerberos cipher suite was an
AP_REQ/AP_REP exchange.  How do you generate an AP_REQ without talking
to the KDC first?  (chicken and egg problem)

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 08:05:04 -0800

While I do not wish to see TLS become the solution to the problem at
hand, I see no reason why, if we were to use TLS, we could not use the
TLS Kerberos cipher suite to protect KDC exchanges.  We need only add
protection for the pre-auth used in the AS exchange anyways and if
another principal has tickets available that could be used to add that
protection then they ought to be used.  In fact, that's precisely the
point of the DCE-style pre-auth approach.

> I have a feeling that others might want to implement TLS as a SHOULD.

Only if a host-key + user long term key system is defined and required
as a MUST implement.

>  - Jeff

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 08:16:32 -0800

> to the KDC first?  (chicken and egg problem)

Using a different principal's key.

It's the same as the DCE RFC26 solution, only instead of doing it in the
pre-auth holes you do it with TLS.

> --Ken

Cheers,

Nico
--

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 02 Dec 2002 11:22:45 -0500

>pre-auth holes you do it with TLS.

I guess if I was given a choice, I'd much prefer DCE RFC 26.0 rather than
adding in TLS (I'm siding with Sam on this one; too much complexity).

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 08:28:07 -0800

> adding in TLS (I'm siding with Sam on this one; too much complexity).

Oh, I agree!  I agreed before too.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Mon, 02 Dec 2002 19:53:52 +0100

> protecting the TGT request.

Thats a profile right there -- it must be written down and taken
through the ietf process. If TLS changes, this profile _may_ need
to change since TLS may define other ciphers which for other reasons
are unsuitable for this application.

	leifj