Subject: resend: kerberos-referrals-07 issues

From: Ken Raeburn <[email-masked]>
Date: Sun, 19 Mar 2006 23:57:15 -0600

I'm not sure why this didn't get through when I sent it a few days  
ago, but it didn't get into the archive, and a couple of people I  
talked to tonight apparently never saw it.  But we're supposed to be  
discussing the draft on Monday morning.  So, just in case anyone  
checks email between now and then....

Begin forwarded message:
> From: Ken Raeburn <[email-masked]>
> Date: March 15, 2006 02:36:38 CST
> To: IETF Kerberos Working Group <[email-masked]>
> Subject: kerberos-referrals-07 issues
>
> Hi, all.  I submitted a kerberos-referrals-07 draft, since the old  
> one had expired.  Not much in the way of updates, I'm sad to say,  
> just tweaking some references.  That's not to say there aren't open  
> issues.  Larry and I had a discussion about some of them at  
> Vancouver; unfortunately, some of my notes have gone missing, and  
> some just aren't very good, so I'm trying to reconstruct largely  
> from memory.  (Serves me right for not doing it promptly after we  
> talked.)  Larry, I'd appreciated it if you'd fill in whatever you  
> can...
>
> Some of the issues I think can be fixed fairly easily, though they  
> involve some protocol changes; others, I don't have a good fix for  
> at the moment, and could use some ideas.  Many (most?) of them are  
> security related, not just a matter of the protocol not supporting  
> odd cases.
>
> * If an implementation supports client name canonicalization, it  
> should support corresponding server principal name aliases or  
> referrals based on the same data.  Consider user-to-user  
> authentication when each user only knows the NT-ENTERPRISE name of  
> the other.  Alice ([email-masked] => [email-masked]) and Bob  
> ([email-masked] => [email-masked]) want to communicate, and while  
> Alice may be able to get the TGT from Bob to do the u2u  
> authentication, the only name she's gotten in a secure fashion may  
> be [email-masked].  So she sends {client=[email-masked],  
> server=[email-masked], extra-tgt={client=[email-masked],...}} to her  
> KDC, where she should be given a TGT and referred to OFFICE.MS.COM.
>
> (This is an easy one.  If there's no objection, I'll add a  
> paragraph strongly recommending this.)
>
> * In the above case, Bob is going to get credentials from  
> [email-masked] (or maybe NT-UID principal [email-masked]).   
> He wants to talk to [email-masked]; how does he know they're the same?
>
> * If an implementation supports aliases for server principal names,  
> should it be encouraged to support these aliases in client name  
> canonicalization?  Consider a script, written to run on a server  
> system, which does "kinit host/[email-masked]"; can it get  
> a client referral to the correct realm for that server?
>
> * In the cross-realm server referral case, if DNS data (including  
> CNAME records) is used (securely, of course) in determining the  
> referred-realm or the true-principal-name, the implementor should  
> consider the fact that DNS records have lifetimes.  I don't know  
> whether the right answer is to incorporate the TTL into the cross- 
> realm TGT lifetime calculation or not -- it may depend on the  
> specifics of the environment.  We could make it a MAY and leave it  
> to the implementor to figure out.
>
> * It's not exactly part of this draft, but ... server name  
> canonicalization, or aliases, in the local realm, say if the user  
> types "ftp foo" and foo.example.com is an alias for  
> foobar.example.com?  Protocol-wise, nothing happens here.  The  
> client can ask for any of the server's names, and the KDC returns  
> credentials with the server name specified by the client.  If the  
> server implementation in such a realm uses principal names to find  
> the key to use to decrypt the credentials, then it has to know all  
> of its names, and the program can't be written to only accept one  
> name.  If it derives keys from a stored password on the fly, then   
> it may get different keys for different client-supplied names  
> (under a cryptosystem that uses the salt data in key generation),  
> since there is no standard way to pass the "true" server name.
>
> Also see above about using DNS TTL data.
>
> I think Larry and I discussed doing something else, but Sam  
> reminded me we had previously agreed that the server name wouldn't  
> be changed by the KDC in this case.  Unless we want to reevaluate  
> that decision.
>
> This could have messy implications for GSSAPI applications, I think.
>
> * If a client wants to get multiple tickets for a service --  
> perhaps with different authorization data or valid time ranges or  
> something -- can it cache and re-use info about the realm to use,  
> and the TGT to use with that realm?   How long can it cache it for?
>
> The only useful way I see to express a time is the TGT expiration  
> time; perhaps the client should be allowed to re-use the  
> information as long as the TGT is valid, and the local KDC should  
> limit the lifetime of that TGT if it wants to limit the caching of  
> the data.  But if the user wants postdated tickets that could be a  
> problem.
>
> * How does a client distinguish a normal case of client name  
> canonicalization at initial ticket acquisition from a man-in-the- 
> middle attack where the name has been modified to a different  
> name?  Well, being able to decrypt the AS-REP eventually acquired  
> might help.  Except, that only proves that the user and KDC agree  
> on the password (actually, the key as derived from the password and  
> principal name and possibly other data) for the principals that  
> each of them thinks is being used.
>
> As with most security analyses, how you define the threat is  
> critical.  Consider a case where an attacker knows that a sloppy  
> user with two principals with different privileges available to him  
> uses the same password for both.  The attacker doesn't know the  
> password.  Should the man in the middle be able to trick the user  
> into using the wrong set of privileges?  I believe he should not,  
> but I don't think we have any protection against that case.   
> Including the requested principal name in the response, protected  
> by encryption or checksum, would fix this, I think.
>
> * Same issue, but with client referrals.  In this case, the KDC  
> issuing the AS-REP does not see the originally-requested client  
> principal name.  I don't have an answer for this one.  (The text  
> makes reference to "validating" the returned client name, but  
> doesn't really explain it.)
>
> * We aren't proposing restricting the initial tickets to only  
> ticket-granting tickets and other very special Kerberos-related  
> services.  So the initial ticket request could be for service host/ 
> foo.example.com, and could get a cross-realm referral.  Similar  
> question to above: If we get back a cross-realm referral with true- 
> principal-name set, how do we know a man in the middle didn't  
> modify the server principal name we initially asked for?
>
> For this, we could add another optional field to ServerReferralData  
> indicating the originally requested principal name.  (Do we need  
> the originally requested server realm too?)  This field would be  
> used when the original request may not have been adequately protected.
>
> * Privacy issue: In the model where the local KDC is contacted for  
> all Kerberos services, to find out if we can authenticate to them,  
> this may put more information into the local logs than the user  
> might want.  For example, depending on one's environment, logs  
> mentioning failed authentication to HTTP/pr0n-world.com.cctld  
> because of a lack of shared cross-realm keys may be a bit  
> embarrassing.  (Then again, we've got other privacy issues, dealing  
> with eavesdroppers, which IMNSHO we should deal with someday.)
>
> Ken

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 20 Mar 2006 09:25:14 -0500

Ken Raeburn wrote:
> I'm not sure why this didn't get through when I sent it a few days ago,
> but it didn't get into the archive, and a couple of people I talked to
> tonight apparently never saw it.  But we're supposed to be discussing
> the draft on Monday morning.  So, just in case anyone checks email
> between now and then....

I didn't see it either. ;-(

>> authentication when each user only knows the NT-ENTERPRISE name of the
>> other.  Alice ([email-masked] => [email-masked]) and Bob ([email-masked]
>> => [email-masked]) want to communicate, and while Alice may be able
>> to get the TGT from Bob to do the u2u authentication, the only name
>> she's gotten in a secure fashion may be [email-masked].  So she sends
>> {client=[email-masked], server=[email-masked],
>> extra-tgt={client=[email-masked],...}} to her KDC, where she should
>> be given a TGT and referred to OFFICE.MS.COM.
>>
>> (This is an easy one.  If there's no objection, I'll add a paragraph
>> strongly recommending this.)

I support this as a SHOULD.

>> [email-masked] (or maybe NT-UID principal [email-masked]).  He
>> wants to talk to [email-masked]; how does he know they're the same?

One option that doesn't require any protocol changes:  Bob could attempt
to obtain a service ticket for [email-masked] and see if after the
referral he ends up with a ticket for [email-masked].

Another option is that Kerberos implements a directory lookup service
but I don't think we want to go in that direction.  It wouldn't be
significantly more efficient than simply obtaining the service ticket.

>> system, which does "kinit host/[email-masked]"; can it get a
>> client referral to the correct realm for that server?

Can you clarify the case you are considering?

We have machine LAPTOP which originally has the DNS name
laptop.newyork.ms.com it belongs to the realm NEWYORK.MS.COM.  LAPTOP
moves to DNS name random.dallas.ietf.org.  In this case the realm is
not going to change.

Perhaps the user is transferred to London and in that case we want
the realm the laptop has a service principal in to change.  It becomes
DNS laptop.london.ms.com with a service principal in realm LONDON.MS.COM.

Under what circumstance would the script be attempting a realm other
than the currently assigned realm?  Are you simply considering a case
in which the script is using the wrong realm because it is configured wrong?

>> whether the right answer is to incorporate the TTL into the
>> cross-realm TGT lifetime calculation or not -- it may depend on the
>> specifics of the environment.  We could make it a MAY and leave it to
>> the implementor to figure out.

When you and I discussed this in Vancouver we concluded that the DNS TTL
SHOULD be used to restrict service ticket lifetimes even if referrals
were not being used.  When using Dynamic DNS with DHCP the DNS TTL
indicates that the binding between the hostname and the host and the
services running on the host is only good for the specified time.  The
Kerberos client should be forced to renew the ticket and the KDC should
reject the renewal if the assignment has changed.

I believe there should be text added to Kerberos Extensions indicating
that service principal lifetimes SHOULD match the DNS TTLs for host
based principal names.

>> foobar.example.com?  Protocol-wise, nothing happens here.  The client
>> can ask for any of the server's names, and the KDC returns credentials
>> with the server name specified by the client.  If the server
>> implementation in such a realm uses principal names to find the key to
>> use to decrypt the credentials, then it has to know all of its names,
>> and the program can't be written to only accept one name.  If it
>> derives keys from a stored password on the fly, then  it may get
>> different keys for different client-supplied names (under a
>> cryptosystem that uses the salt data in key generation), since there
>> is no standard way to pass the "true" server name.
>>
>> I think Larry and I discussed doing something else, but Sam reminded
>> me we had previously agreed that the server name wouldn't be changed
>> by the KDC in this case.  Unless we want to reevaluate that decision.
>>

I think that if were were starting from scratch that we would want the
KDC to return a canonical name via a local referral.  However, I don't
think we can do that today.

>> * If a client wants to get multiple tickets for a service -- perhaps
>> with different authorization data or valid time ranges or something --
>> can it cache and re-use info about the realm to use, and the TGT to
>> use with that realm?   How long can it cache it for?

The client can try to cache the data but it might be wrong.  If the
realm is wrong then a KDC will return an error and the client should
perform the request without using any cached or inferred data.

>> time; perhaps the client should be allowed to re-use the information
>> as long as the TGT is valid, and the local KDC should limit the
>> lifetime of that TGT if it wants to limit the caching of the data. 
>> But if the user wants postdated tickets that could be a problem.

As long as the TGT is valid or as long as the service ticket is valid?

I can imagine that a TGT lifetime might be longer than the service
ticket lifetime.

>> canonicalization at initial ticket acquisition from a
>> man-in-the-middle attack where the name has been modified to a
>> different name?  Well, being able to decrypt the AS-REP eventually
>> acquired might help.  Except, that only proves that the user and KDC
>> agree on the password (actually, the key as derived from the password
>> and principal name and possibly other data) for the principals that
>> critical.  Consider a case where an attacker knows that a sloppy user
>> with two principals with different privileges available to him uses
>> the same password for both.  The attacker doesn't know the password. 
>> Should the man in the middle be able to trick the user into using the
>> wrong set of privileges?  I believe he should not, but I don't think
>> we have any protection against that case.  Including the requested
>> principal name in the response, protected by encryption or checksum,
>> would fix this, I think.

This is a bit of a tangent but I believe it is it came to mind so I
will mention it.

Last week I attended the W3C Workshop on Usability and Transparency of
Web Authentication.  A significant amount of time was spent discussing
phishing attacks.  A major concern of the portals that provide identity
management services is that it will be very easy for passwords of users
to be stolen once principals start to be accepted for use in multiple
domains.  The web portals would love to be able to use something like
Kerberos but given the deployment realities they would need to continue
to accept passwords over TLS for quite some time to come even if they
could deploy a Kerberos based solution today for users that do not
own a computer.

Google presented some somewhat frightening numbers regarding password
quality and re-use.  Based upon a sampling of their user base Google
has concluded that more than 50% of the passwords selected by users
around the world fall into a pool of approximately one million
passwords.  These passwords are frequently reused for multiple services.

If an attacker was able to steal a sufficiently large password database
and launch attacks against its users, there would be a sufficiently
large enough number of users that re-use the password in the database
everywhere that a redirection attack would be profitable.  A user that
mutually authenticates with Kerberos is going to be convinced s/he is
communicating with a trusted service and would be more willing to
provide requested personal information.  I am convinced we have to
take such attacks very seriously.

>> principal name.  I don't have an answer for this one.  (The text makes
>> reference to "validating" the returned client name, but doesn't really
>> explain it.)

...

>> services.  So the initial ticket request could be for service
>> host/foo.example.com, and could get a cross-realm referral.  Similar
>> question to above: If we get back a cross-realm referral with
>> true-principal-name set, how do we know a man in the middle didn't
>> indicating the originally requested principal name.  (Do we need the
>> originally requested server realm too?)  This field would be used when
>> the original request may not have been adequately protected.

I think we need both principal name and realm.

>> * Privacy issue: In the model where the local KDC is contacted for all
>> Kerberos services, to find out if we can authenticate to them, this
>> may put more information into the local logs than the user might
>> want.  For example, depending on one's environment, logs mentioning
>> failed authentication to HTTP/pr0n-world.com.cctld because of a lack
>> of shared cross-realm keys may be a bit embarrassing.  (Then again,
>> we've got other privacy issues, dealing with eavesdroppers, which
>> IMNSHO we should deal with someday.)

We have this problem today without referrals.  This is definitely an
issue we need to address but I believe it has to be addressed as part
of a client-side policy for use of a user's credentials.

Jeffrey Altman