Ticket History #682: KDC should only check client principal for preauth requirements

From fcusack@ratbert.iconnet.net Tue Jan 12 13:08:50 1999
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id NAA23626 for <bugs@RT-11.MIT.EDU>; Tue, 12 Jan 1999 13:08:49 -0500
Received: from ratbert.iconnet.net by MIT.EDU with SMTP
id AA29788; Tue, 12 Jan 99 13:08:40 EST
Received: (from fcusack@localhost)
by ratbert.iconnet.net (8.9.1/8.9.1) id NAA04358;
Tue, 12 Jan 1999 13:10:23 -0500 (EST)
Message-Id: <199901121810.NAA04358@ratbert.iconnet.net>
Date: Tue, 12 Jan 1999 13:10:23 -0500 (EST)
From: fcusack@iconnet.net
Reply-To: fcusack@iconnet.net
To: krb5-bugs@MIT.EDU
Cc: fcusack@iconnet.net
Subject: KDC shouldn't check server principal for preauth requirements
X-Send-Pr-Version: 3.99

Qwest Communications
Unix
System: SunOS ratbert 5.6 Generic_105181-09 sun4u sparc SUNW,Ultra-5_10
Architecture: sun4

KDC checks the preauth flags on the server principal when
issuing tickets. If preauth (or hwauth) is required, and
the appropriate flag is not set in the ticket request, the
new ticket is not issued. This check should not be done
for server principals, based on email from Marc Horowitz.
Index: kdc_util.c
===================================================================
RCS file: /icon/d04/cvsroot/3rd-party/krb5-19981119/kdc/kdc_util.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 kdc_util.c
--- kdc_util.c 1998/11/24 17:05:08 1.1.1.1
+++ kdc_util.c 1999/01/12 18:05:27
@@ -1292,6 +1292,7 @@
st_idx++;
}

+#if 0
/* Check for hardware preauthentication */
if (isflagset(server.attributes, KRB5_KDB_REQUIRES_HW_AUTH) &&
!isflagset(ticket->enc_part2->flags,TKT_FLG_HW_AUTH)) {
@@ -1305,6 +1306,7 @@
*status = "NO PREAUTH";
return KRB_ERR_GENERIC;
}
+#endif /* 0 */

/*
* Check local policy

From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: krb5-bugs@MIT.EDU, fcusack@iconnet.net
Cc: krb5-unassigned@RT-11.MIT.EDU, gnats-admin@RT-11.MIT.EDU,
krb5-prs@RT-11.MIT.EDU, marc@MIT.EDU
Subject: Re: krb5-kdc/682: KDC shouldn't check server principal for preauth requirements
Date: Wed, 13 Jan 1999 00:24:01 -0500

Date: Tue, 12 Jan 1999 13:10:23 -0500 (EST)
From: fcusack@iconnet.net

KDC checks the preauth flags on the server principal when
issuing tickets. If preauth (or hwauth) is required, and
the appropriate flag is not set in the ticket request, the
new ticket is not issued. This check should not be done
for server principals, based on email from Marc Horowitz.

This is correct behaviour --- a system administrator may be so paranoid
that they want it to be the case that tickets for some highly privileged
service, say:

vault/door.fort-nox.gov@FORT-KNOX.GOV

should only be issued if the ticket-granting ticket was originally
obtained using hardware preauthentcation.

I don't understand why you had this attribute (REQUIRES_HW_PREAUTH) set
on the principal if you didn't want this to be the case. Why not clear
the attribute from the database, instead of commenting out the check in
the KDC database?

- Ted


From: Frank Cusack <fcusack@iconnet.net>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, krb5-unassigned@RT-11.MIT.EDU,
gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU, marc@MIT.EDU
Subject: Re: krb5-kdc/682: KDC shouldn't check server principal for preauth requirements
Date: Wed, 13 Jan 1999 06:42:03 -0500

In message <199901130524.AAA07471@dcl>,
"Theodore Y. Ts'o" writes:

I think so too, but consider that

The RFC (rev-03), par 5.3.1, under "flags" says "The hardware
authentication method is selected by the KDC and the strength of
the method is not indicated".

Also note that

a) the hwauth flag (as opposed to the preauth flag) is really just
"advisory". For many types of h/w auth (eg those using ANSI X9.9
tokens) there is no way to "prove" a hardware device was actually
used. As another example S/Key is done with the hwauth flag.
b) If the TGT was obtained from a KDC in another realm (outside of
the direct administration of the local realm), the hwauth flag is
more suspect.

There is some mention of preauth (although it should be more general)
in A.1-A.3 (AS_REQ pseudocode) but none for TGS_REQ operations.

I personally need this to work without checking, for protocols that
won't support multiple password exchanges (eg ftp). eg: principal P
requires hwauth (SAM). He does a plain password auth to server S. The
server is unable to get a TGT for P b/c only one password can be
received from the ftp client, and obtaining the TGT requires a
password and the SAM response. So instead S gets a TGT for host/<host>
and verifies it by getting a service ticket for P. This wouldn't be
possible if hwauth checking occured since P requires hwauth.

Here's the note from Marc:

-----------
Message-id: <t5390fdkzeg.fsf@rover.cygnus.com>
X-mailer: Gnus v5.3/Emacs 19.34
From: Marc Horowitz <marc@MIT.EDU>
To: Frank Cusack <fcusack@iconnet.net>
Cc: krbdev@MIT.EDU
Subject: Re: sudo vs SAM
Date: 08 Jan 1999 20:28:39 -0500

Frank Cusack <fcusack@iconnet.net> writes:


Whatever the KDC does with this is a local implementation matter. The
RFC doesn't say what it means for preauthentication to be required for
a service principal.


I think that checking the hwauth flag on a service ticket (if that's
what's happening, I haven't looked at the code) is wrong, and should
be removed.

Marc
-------------

~frank



From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Frank Cusack <fcusack@iconnet.net>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, krb5-bugs@MIT.EDU,
krb5-unassigned@RT-11.MIT.EDU, gnats-admin@RT-11.MIT.EDU,
krb5-prs@RT-11.MIT.EDU, marc@MIT.EDU
Subject: Re: krb5-kdc/682: KDC shouldn't check server principal for preauth requirements
Date: Sat, 16 Jan 1999 01:17:00 -0500 (EST)

Date: Wed, 13 Jan 1999 06:42:03 -0500
From: Frank Cusack <fcusack@iconnet.net>

The RFC (rev-03), par 5.3.1, under "flags" says "The hardware
authentication method is selected by the KDC and the strength of
the method is not indicated".

I don't see why this is relevant. This is basically defining what it
means for the HW-AUTHENT flag means in the ticket. What the definition
basically says is that if the ticket can trace its lineage back to a TGT
or a AS request which involved a hardware authentication token, then
this bit will be set.

Also note that

a) the hwauth flag (as opposed to the preauth flag) is really just
"advisory". For many types of h/w auth (eg those using ANSI X9.9
tokens) there is no way to "prove" a hardware device was actually
used. As another example S/Key is done with the hwauth flag.

Huh? In all of the h/w authentication I'm aware, of the KDC has to be
involved; they all involve some kind of preauth exchange.

If you're storing the DES key in a smart-card (which no one is doing as
far as I know), presumably you won't allow the user to know the DES
key. If you don't, then indeed the KDC won't know for sure whether or
not the hardware device was set, and therefore it shouldn't set the
HW-AUTHENT bit. If the KDC "knows" that only the smart card has the DES
key, then we could set a bit in the principal entry so that the KDC will
set the HW-AUTHENT bit for that user. That's not implemented today, but
the code to securely initialize the smartcard unit isn't implemented
either.

b) If the TGT was obtained from a KDC in another realm (outside of
the direct administration of the local realm), the hwauth flag is
more suspect.

There is some mention of preauth (although it should be more general)
in A.1-A.3 (AS_REQ pseudocode) but none for TGS_REQ operations.

I personally need this to work without checking, for protocols that
won't support multiple password exchanges (eg ftp). eg: principal P
requires hwauth (SAM). He does a plain password auth to server S. The
server is unable to get a TGT for P b/c only one password can be
received from the ftp client, and obtaining the TGT requires a
password and the SAM response. So instead S gets a TGT for host/<host>
and verifies it by getting a service ticket for P. This wouldn't be
possible if hwauth checking occured since P requires hwauth.

Ergh. Now I see what you're doing. That's a really nasty hack.

It also doesn't work in the general case, since the FTP server doesn't
necessarily know what salt to use for the string-to-key algorithm.
I didn't even consider something like this, since ordinarily it's
incredibly bad form to be passing your kerberos key to an FTP server.

Even if you are requiring hardware authentication, when a bad guy gets
your password (say from the FTP server), he will be able to wait for the
next time you login, grab the AS_REP, and decrypt it since they have
your password.

A fundamental design principle for Kerberos is to *not* let the Kerberos
password leave the workstation. A system which *encourages* users to
type their plain password, probably over an uncrypted channel (to the
ftp server), is really asking for a disaster.

From: Marc Horowitz <marc@MIT.EDU>
Date: 08 Jan 1999 20:28:39 -0500

Frank Cusack <fcusack@iconnet.net> writes:


Whatever the KDC does with this is a local implementation matter. The
RFC doesn't say what it means for preauthentication to be required for
a service principal.

The RFC doesn't say anything about for how to enforce preauthentication
requirements at all --- for clients or for servers. That's a local
configuration option in the KDB, which is outside the scope of the RFC.


I think that checking the hwauth flag on a service ticket (if that's
what's happening, I haven't looked at the code) is wrong, and should
be removed.

If Marc wants to argue about why it's "wrong", I'm willing to listen,
but I won't accept unsupported assertions. I believe that allowing
configure service principals to require that the user used
preauthentication is a good and useful feature.

We could split the require_preauth flags to mean "require preauth when
used as a client", and "require preauth when used as a server", but I'll
need a better justification than a desire to implement a fundamentally
unsafe scheme which violates a fundamental Kerberos design principal.

- Ted

State-Changed-From-To: open-closed
State-Changed-By: tytso
State-Changed-When: Fri Jan 22 00:56:15 1999
State-Changed-Why: Marc's wrong.