[3029] in Kerberos-V5-bugs
Re: krb5-kdc/682: KDC shouldn't check server principal for preauth requirements
daemon@ATHENA.MIT.EDU (Frank Cusack)
Wed Jan 13 06:40:39 1999
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
In-Reply-To: Your message of "Wed, 13 Jan 1999 00:24:01 EST."
<199901130524.AAA07471@dcl>
Date: Wed, 13 Jan 1999 06:42:03 -0500
From: Frank Cusack <fcusack@iconnet.net>
In message <199901130524.AAA07471@dcl>,
"Theodore Y. Ts'o" writes:
> 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 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:
>> 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.
>> 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.
Marc
-------------
~frank
