[3030] in Kerberos-V5-bugs
Re: krb5-kdc/682: KDC shouldn't check server principal for preauth requirements
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Sat Jan 16 01:17:12 1999
Date: Sat, 16 Jan 1999 01:17:00 -0500 (EST)
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
In-Reply-To: Frank Cusack's message of Wed, 13 Jan 1999 06:42:03 -0500,
<199901131142.GAA13087@ratbert.iconnet.net>
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:
>> Yeah, I set a host/<host> principal with +requires_hwauth, and could
>> only get a service ticket with a TGT that had the h/w auth flag set.
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.
>> Do you think it would be better to disable the hwauth flag checking
>> when issuing a service ticket (I think so now) or to check for a
>> special principal (sudo/<host>) and then always set the hwauth flag?
>> They seem almost equivalent in terms of any security loss.
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
