Subject: [Ietf-krb-wg] client referrals and reused passwords

From: Ken Raeburn <[email-masked]>
Date: Tue, 16 Oct 2007 20:45:36 -0400

Back in April I wrote some email examining the risks of using  
passwords for multiple Kerberos principals, in one realm or in  
multiple realms.  (Unwise, yes, but realistic.)

> In the client referral case, all the client receives is an  
> unprotected KRB-ERROR message pointing it to the new realm name.   
> No new client name can be provided by the KDC, but if a spoofed  
> reply (or a legitimate reply to a spoofed query) points the user to  
> realm2, and the client name used is accepted by the realm2 KDC as  
> well as the realm1 KDC, a proper AS-REP will be issued using the  
> user's realm2 key (which may require the attacker to insert a salt  
> string in the reply message).

So when a client referral is expected, the principal name form should  
be one that would distinguish realm1 from realm2 without reference to  
the realm component supplied.  For example, the NT-ENTERPRISE name  
"[email-masked]" might be accepted by REALM1.EXAMPLE.COM and  
REALM2.EXAMPLE.COM, but they must not both be configured to consider  
Alice as a local user; all realms not outright rejecting the name  
must agree on which one realm "[email-masked]" belongs to, or they  
risk having the wrong principal name (and perhaps wrong server-side  
accounts and/or wrong privileges) used if Alice has multiple distinct  
accounts in the enterprise and uses the same password for each.

This isn't a protocol issue, but a matter of how the realms should  
coordinate their administration to provide the best security.  If a  
man-in-the-middle attacker can get Alice to use her REALM2  
credentials when she should be using her REALM1 credentials, the  
administrator of REALM2 is doing her a disservice.  (Perhaps this  
example would be more meaningful if the example realm names didn't  
appear to both be within the same organization.)

If an NT-PRINCIPAL name ("alice") is sent and a WRONG-REALM error is  
returned, caution should be used before trusting the new realm name.   
While it's been suggested (by me, mostly) that client referrals might  
be used to correct the spelling of a realm name (e.g., return a realm  
name in uppercase when it was supplied in lowercase by the user), or  
supply an organization's correct realm name when it doesn't match the  
default domain name as in the ATHENA.MIT.EDU case, the same technique  
might be used to redirect Alice to REALM2 in this example.

I'm still trying to figure out just what the advice should be in this  
case, compared to the normal client referral case.  Anyone want to  
make a suggestion?

There's also the question of how far we should go to protect the user  
against doing something stupid with her own accounts....

Ken
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg