Subject: [Ietf-krb-wg] referrals: server name canonicalization

From: Ken Raeburn <[email-masked]>
Date: Sun, 23 Dec 2007 17:42:47 -0500

Should we revisit the decision not to support server name  
canonicalization?  I'm leaning towards the opinion now that it's a  
glaring omission from the set of changes currently supported in the  
draft.

I know, we're supposed to be working towards Last Call now, but it  
seems kind of weird to have one flag to enable client name  
canonicalization, client name referrals, and server referrals, and  
later need to add another flag to enable server name canonicalization  
(if we add it).  We can do it, it'd just be weird.

The pa-data type currently described as PA-CLIENT-CANONICALIZED would  
also be the obvious place to put the data necessary to do server name  
alias processing securely in an AS exchange.  However, the  
ReferralInfo type is extensible, so we can fix that later.

Otherwise, having aliases for a server means that either (1) the  
server has to ignore the server principal name indicated in the  
ticket presented, and must simply know all the encryption keys that  
could be used, kind of at odds with letting a server support multiple  
independent realms as we allow now even if it's not widely used; or  
(2) the server must know all of its aliases, and thus all services on  
a host as well as the KDC must be updated if an additional alias for  
the hostname is created.

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

---

From: Martin Rex <[email-masked]>
Date: Fri, 28 Dec 2007 17:19:09 +0100 (MET)

> a host as well as the KDC must be updated if an additional alias for  

Microsoft's Kerberos implementation has been ignoring the servers
name in the ticket.  They're brute-forcing the ticket with the
available key(s) using the only the REALM name as the salt.
They kind of had to do this since they did _not_ implement service
principals (only service name aliases that are known only to the KDC,
but not to the server/service itself).

At least this was how it worked with Win2K.  I once created two
seperate domain accounts with the same password and when running
the SSPI-adapted version of gss-sample server under one of the accounts,
I could use either name as target name on the gss-sample client and the
authentication would succeed.

The one big disadvantage about this is that the server might then have
difficulties to determine the (client-side) configuration error
"incorrect target-name" an error situation which traditionally
can be determined and reported reliably with MIT Kerberos.

-Martin