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

From: Lawrence Greenfield <[email-masked]>
Date: Sun, 01 Dec 2002 12:59:54 -0500

for Windows 2000/XP]
Message-ID: <[email-masked]>
In-Reply-To: <CMM.0.91.0.1038754394.jaltman@watsun>
References: <CMM.0.91.0.1038754394.jaltman@watsun>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [email-masked]
Precedence: bulk

--On Sunday, December 01, 2002 9:53 AM -0500 Jeffrey Altman 
<[email-masked]> wrote:

> The Kerberos Login Sniffer is directly aimed at Windows logins which
> do use pre-auth.  This is the tool that we have feared would be
> released prior to our coming to a solution before Microsoft absolutely
> had to release something.
>
> If we still do not want Microsoft to begin using TLS to protect TGT
> requests we need to come to an agreement quickly.  Probably within
> days.  Otherwise, Microsoft might feel pressured to solve this within
> a few weeks as I am sure that given this tool has now hit NTBUGTRAQ it
> will be all over slashdot and e-week.

I've never understood why we're against using TLS to protect TGT requests. 
We've already come to a consensus that TCP support is a MUST. TLS is widely 
deployed and analyzed, can function in an anonymous DH mode for sites that 
don't want to deploy certificates, and solves the problem.

If not TLS, it seems that Kerberos should consider adapting one of the 
other security frameworks for the initial authentication. If UDP support 
really is required (why?) then GSS is the obvious choice. If not, SASL 
support would also work (defining a new SASL mechanism if needed).

Larry

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 Dec 2002 14:17:47 -0500

>>>>> "Lawrence" == Lawrence Greenfield <[email-masked]> writes:

    Lawrence> If not TLS, it seems that Kerberos should consider
    Lawrence> adapting one of the other security frameworks for the
    Lawrence> initial authentication. If UDP support really is
    Lawrence> required (why?) then GSS is the obvious choice. If not,
    Lawrence> SASL support would also work (defining a new SASL
    Lawrence> mechanism if needed).

I certainly wouldn't mind someone writing a draft to specify GSS
preauth.  From a technical standpoint I'd prefer SPKM as a way to use
X.509 certs over TLS.

I suspect that a TLS preauth draft will probably get written.  

I don't think either of these solutions should be MUST implements and
I'm not really even convinced about SHOULD.

---

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

> preauth.  From a technical standpoint I'd prefer SPKM as a way to use

This is reasonable, particularly since most Kerberos implementations
also implement GSS-API and RFC1964.

GSS pre-auth even has the benefit of facilitating DCE RFC26 style
pre-auth: the client and the KDC first establish a GSS context through
the padata of AS-REQ and KRB-ERROR and then the client sends a
GSS_Wrap(PA-ENC-TIMESTAMP) as padata; since the GSS initiator principal
need not be the same as the AS-REQ client principal the Kerberos GSS
mechanism can be used, thus reducing to the moral equivalent of DCE
RFC26.

> I'm not really even convinced about SHOULD.

I find GSS pre-auth to be appealing.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Mon, 2 Dec 2002 23:04:33 +0100 (MET)

> I find GSS pre-auth to be appealing.

It looks extremely awkward to me -- please don't use GSS-API.

It's about the same excess protocol bloat as TLS,
in particular if something like SPKM is used, and
it also requires one or more additional roundtrips.

If Kerberos wants to be a GSS-API mechanism by itself, then
it should definitely not require/use another GSS-API mechanism
underneath!

-Martin

---

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

> It looks extremely awkward to me -- please don't use GSS-API.

Awkward, yes, but better than TLS for the simple, historical reason that
Kerberos implementations often include a GSS/rfc1964 implementation.

> it also requires one or more additional roundtrips.

Er, no, not if GSS_C_PROT_READY_FLAG is used (see my first post about
GSS pre-auth in this thread).

> it should definitely not require/use another GSS-API mechanism

Plus ca change... One might ask why bother with PKTAPP too (if you can
do PKI then why bother wrapping it in Kerberos? This is rethorical).

:)

Cheers,

Nico
--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 2 Dec 2002 14:38:55 -0800 (PST)

I agree. Let's keep in mind that we want to keep
Kerberos within the reach of embedded
applications. Please don't assume huge distros
full of unused gunk. Flash is still expensive for
low end widgets.

	Mike

---

From: OKABE Nobuo <[email-masked]>
Date: Tue, 03 Dec 2002 13:15:42 +0900 (JST)

# Sorry if my comment does not match the context
# because I'm a newcomer of this area.

Please also keep crypto computational cost in mind
because both RSA and DH are too complicated for
small embedded system (ex. 8-bit or 16-bit cpu).

I' not against using TLS or so on.
At the same time, I want the WG to leave current kerberos way
(= relatively light-weight crypto) for embedded systems.

thanks,

From: Michael Thomas <[email-masked]>
Subject: Re: ["Frank O'Dwyer" <[email-masked]>: Re: Kerberos login sniffer and cracker
Date: Mon, 2 Dec 2002 14:38:55 -0800 (PST)

>  > it should definitely not require/use another GSS-API mechanism

---- nobuo

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Dec 2002 12:17:40 -0500

>>>>> "OKABE" == OKABE Nobuo <[email-masked]> writes:

    OKABE> # Sorry if my comment does not match the context # because
    OKABE> I'm a newcomer of this area.

    OKABE> Please also keep crypto computational cost in mind because
    OKABE> both RSA and DH are too complicated for small embedded
    OKABE> system (ex. 8-bit or 16-bit cpu).

What secure mechanism of handling passwords for unkeyed small devices
do you believe exists?

If you can propose a solution we'll certainly consider it.

---

From: Martin Rex <[email-masked]>
Date: Tue, 3 Dec 2002 18:08:28 +0100 (MET)

> Kerberos implementations often include a GSS/rfc1964 implementation.

EXTREMELY awkward.

TLS and SPKM are about the same magnitude of complexity
(Lot's of ASN.1, X.509-cert stuff (cert path, cert validation/CRL,
 and public key crypto)

There is an OpenSource TLS implementation available, but there
isn't any OpenSource SPKM implementation (that I know of).

> GSS pre-auth in this thread).

It looks like you're not aware of it, but GSS_C_PROT_READY is simply
not available for (generic) SPKM.  When using DHE key exchange both
sides add keying material and an full exchange, and when using
RSA key exchange the initiator first needs to get the certificate
of the target (which takes a full roundtrip in SPKM1) in order to
send the target keying material encrypted with the public key
of the target.

> do PKI then why bother wrapping it in Kerberos? This is rethorical).

If Kerberos could *not* live without another GSS-API or TLS implementation,
then it would be time to abandon and bury Kerberos because it wouldn't
be needed anymore (because neither of GSS-API nor TLS requires Kerberos).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Dec 2002 10:01:16 -0800

> It looks like you're not aware of it, but GSS_C_PROT_READY is simply

GSS_C_PROT_READY is available for some mechanisms and not for others.
So?

Nico
--

---

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 03 Dec 2002 13:11:45 -0500

> full of unused gunk. Flash is still expensive for

Most of the low end widgets that I've seen around do TLS but don't do 
Kerberos. I guess I've been told of low-end Cisco switches that can use 
Kerberos to verify a password but don't do TLS, but somehow this doesn't 
seem to be a very compelling use of Kerberos.

Any solution to the non-keyed device trying to do initial authentication is 
going to involve some amount of heavy duty math.

Larry

---

From: Michael Thomas <[email-masked]>
Date: Tue, 3 Dec 2002 10:18:19 -0800 (PST)

Packetcable (residential voip over cable) is using
Kerberos. This is definitely *extremely* low end
boxen which has no reason to drag in all kinds of
extraneous gunk. Kerberos is already a hardship.
The complex math part is less of a concern, IMO,
because it is only needed for the AS-REQ/REP which
can be done relatively infrequently and in the
background if need be. The code footprint, on the
other hand, is a significant concern.

	    Mike