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 ; 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 >Number: 682 >Category: krb5-kdc >Synopsis: KDC should only check client principal for preauth requirements >Confidential: no >Severity: non-critical >Priority: low >Responsible: krb5-unassigned >State: closed >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Tue Jan 12 13:09:01 EST 1999 >Last-Modified: Fri Jan 22 00:57:02 EST 1999 >Originator: Frank Cusack >Organization: Qwest Communications >Release: krb5-current-19981119 >Environment: Unix System: SunOS ratbert 5.6 Generic_105181-09 sun4u sparc SUNW,Ultra-5_10 Architecture: sun4 >Description: 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. >How-To-Repeat: >Fix: 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 >Audit-Trail: From: "Theodore Y. Ts'o" 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 To: "Theodore Y. Ts'o" 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: > 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/ 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: X-mailer: Gnus v5.3/Emacs 19.34 From: Marc Horowitz To: Frank Cusack Cc: krbdev@MIT.EDU Subject: Re: sudo vs SAM Date: 08 Jan 1999 20:28:39 -0500 Frank Cusack writes: >> Yeah, I set a 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/) 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 From: "Theodore Y. Ts'o" To: Frank Cusack Cc: "Theodore Y. Ts'o" , 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 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/ 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 Date: 08 Jan 1999 20:28:39 -0500 Frank Cusack writes: >> Yeah, I set a 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/) 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 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. >Unformatted: