Subject: Re: Section 3 (take 2) Kerberos Revisions for comment

From: Ken Raeburn <[email-masked]>
Date: 17 Nov 2000 16:14:04 -0500

Clifford Neuman <[email-masked]> writes:

> <H4>3.1.3.  Generation of KRB_AS_REP message</H4>
> If the request had the CANONICALIZE option set and if the AS finds the
> canonical name for the client and it is in another realm, then an
> error message with a KDC_ERR_WRONG_REALM error code and the cname and
> crealm in the error message will contain the true client principal
> name and realm.  In this case, since no key is shared with the client,
> the response from the KDC is not integrity protected and the referral
> can only be considered a hint; the validity of the referral is
> validated upon successful completion of initial authentication with the
> correct AS using the appropriate user key.

Actually, no... strike the last half of the last sentence.

The authenticity of the AS_REQ referral can never be validated as
things stand now.  Successful initial authentication using the new
principal name (including TGT validation by authenticating to a host
service) means only that the user has the right password for the new
principal name.

For example:

	GUI: "Please enter your account name:"
	me: "bcn"
	GUI: "Password:"
	me: "foo

	host->KDC: AS_REQ{bcn@FOO, krbtgt/FOO@FOO, ...}
	spoof-KDC->host: [email-masked]}
	real-KDC->host: AS_REP (ignored)
	host->KDC: [email-masked], krbtgt/[email-masked], ...}
	KDC->host: [email-masked], krbtgt/[email-masked], ...}

(where, of course, I control RAEBURN.ORG's database)

Then the host decodes the AS_REP, successfully uses it to authenticate
to a local host service, and then ... lets me into the account whose
name I indicated in the first place because the mapping from account
"bcn" to principal name "ken" is believed to be validated?  Not good.

If the application attempts to authenticate to the original principal
name as a service, and requests canonicalization, then you might be
able to validate it.  But the KDC may have such "server" uses of user
principals turned off as a matter of policy, so it can't be relied on.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 17 Nov 2000 16:49:48 -0500

> Actually, no... strike the last half of the last sentence.

Right. Replace that text with "...; the validity of the referral is
established by using the TGT obtained this way to obtain a service
ticket which the client can validate."

> "bcn" to principal name "ken" is believed to be validated?  Not good.

The missing step here is:

	host->KDC(RAEBURN.ORG): [email-masked], krbtgt/FOO@FOO, ...}
	KDC(RAEBURN.ORG)->host: [email-masked], krbtgt/FOO@FOO, ...}
	host->KDC(FOO): [email-masked], host/host@FOO}
	KDC(FOO)->host: [email-masked], host/host@FOO}

That is, the host should ALWAYS validate Kerberos credentials (TGTs)
against a local SPN/keytab whenever validating a password against
Kerberos. And that rule should be regardless of wether UPN referrals
are involved.

This makes UPN referrals secure, methinks. Ugly, perhaps, but secure.

Several months back I posted a complaint showing how UPN referrals can
actually lead to confusing situations which, in extreme circumstances,
result in security problems.

So you're right about the text. But UPN canon can be secure.

I myself think that UPN referrals are not necessary. This is a user
education issue. But perhaps it would be during migrations
(mergers/acquisitions) that UPN referrals would shine, like the SID
history feature in Windows NT user profiles...

As for SPN canonicalization, I think it's very useful, and certainly
secure. Would any existing clients not aware of SPN canonicalization
break if SPN canonicalization is done by default (instead of at the
client's request) when no referral is incurred?

> principals turned off as a matter of policy, so it can't be relied on.

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: 17 Nov 2000 18:01:29 -0500

> ticket which the client can validate."

Nope.

> Kerberos. And that rule should be regardless of wether UPN referrals

I assumed that that would be done, and that the compromised realm had
exchanged inter-realm keys with the local realm.  Sorry for not saying
so explicitly.

Assuming for the moment that "account" and "principal" are not
equivalent in the system in question, the login procedure needs to
decide somehow whether to let me in to the specified account, and for
dealing with local resources, the account name is what's important.
(Perhaps it sends a request with a type-SMTP principal and requests
canonicalization.)  What has been validated is that I do really have
the correct key for the principal given in the referral.  It does not
validate that the account name given maps to that principal.  Nothing
in the above exchange for validating the TGT ever mentions the name
"bcn" given in the first place.

This can be fixed in application code by verifying that the principal
is allowed login access to the account requested.  But saying that the
referral itself is secure implies that an application might be able to
rely on the referral data for security purposes, and in some cases,
that might imply that no extra access check is needed (e.g., to one's
"own" account).

> client's request) when no referral is incurred?

I would guess that they would not.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Nov 2000 10:23:01 -0500

> > ticket which the client can validate."

?

> exchanged inter-realm keys with the local realm.  Sorry for not saying

Ah. That confused me.

> "bcn" given in the first place.

I see. Your issue is principal->account mappings.

This is an implementation issue... as in how krb5_aname_to_localname()
is implemented.

And it's not the account mapping that matters, but the mapping to
whatever IDs are used by client OS kernels to determine access (i.e.,
Unix UIDs/GIDs, Windows SIDs+RIDs, and so on).

IIUC, Windows 2000 this is handled like so: the user's KDC adds a
"profile" to the user's tickets and in cross-realm situations the
intervening realm's KDCs choose wether or not to pass on the profile.

But I am not an expert on how the Windows 2000 PAC works.

I've been pondering other-names and additional-signatures extensions
and/or authorization data types to help deal with the problem in a more
interoperable way.

I'm thinking of something like:

OtherName	::= SEQUENCE {
	added-by-realm	GeneralString,
	name-type	INTEGER,
	name		OPTIONAL GeneralString,
	fo-application	OPTIONAL GeneralString,
	for-realm	OPTIONAL GeneralString
};

OtherNames	::= SEQEUNCE OF OtherName;

Mind you, I'm a neophyte at ASN.1...

But certainly such an extension would: a) allow a trivial path in
krb5_aname_to_localname() and with reduced administration, and b) allow
a more flexible trust model where realm trusts are explicit about wether
principals in one realm actually have access (and to what) in the other
by validating and passing/not passing the relevant OtherName extensions
in cross-realm tickets at the realm boundaries.

> that might imply that no extra access check is needed (e.g., to one's

I disagree. Even having validated Kerberos credentials is not taken to
be enough to allow access when canonicalization is not in use.

Mapping between a user principal and the other entities representing
the same user are always necessary, regardless of wether name
canonicalization is involved.

But Kerberos tickets do not provide any useful information, other than
user principal names, for establishing the mappings.

"Kerberos is an authentication service, not an authorization service."

Isn't that the mantra usually recited whenever someone offers an
extension to allow Kerberos tickets to carry information that could
assist the mapping of principals to other entities which can then be
used for making authorization checks??

> I would guess that they would not.

I'm not sure. I realize that if name canonicalization results in a
referral then the clients have to be smart enough to: a) relize what
happened, b) follow the referral. But if the service name requested
changed to a different service name in the same realm, I don't think
existing clients would notice the difference.

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: 20 Nov 2000 13:04:02 -0500

> > > ticket which the client can validate."

We have nothing that authenticates that step.  It can be spoofed,
though 

> This is an implementation issue... as in how krb5_aname_to_localname()

Sort of.

A simplistic approach is to take the account name, tack on the local
realm name, and use the result as the principal; that's the way MIT
krb5 login works.  And a simplistic approach to authorization is, if
no special ACL is set up, principal "foo@REALM" always gets access to
local account "foo".  (And if the user isn't to have access to that
machine, the local account isn't created.  Or maybe there's another
access list indicating certain accounts that aren't allowed to log in
at all.)

An obvious but naive way of extending this, based on the text that
hints that the referral itself is validated, might be to allow access
to account "foo" if asking for a TGT for "foo@REALM" gets a TGT (for
anyone) that can be used to authenticate to the local host service.

> Unix UIDs/GIDs, Windows SIDs+RIDs, and so on).

That's effectively what I meant by "account".  It could also be a
mailbox name, for an email service, with no special UIDs in sight.
This isn't necessarily specific to "login accounts", but they're the
most common case where one is prompted for an account name (which we
might canonicalize) and password.

> used for making authorization checks??

Yes, in theory, but sometimes very simplistic models are used for both
mapping and authorization.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Nov 2000 14:17:36 -0500

> We have nothing that authenticates that step.  It can be spoofed,

Sure you do. It's called a keytab. You use the user's TGT to get a
service ticket for a service principal whose key is stored locally. If
the service ticket is valid, after decryption with the service's key,
then the TGT is valid. Kerberos rests on the principle that successful
decryption and validation of authenticators and tickets imply
successful authentication.

> anyone) that can be used to authenticate to the local host service.

I see, but clearly, the mechanics of mapping a principal name to some
other entity are beyond the scope of this RFC, thus this is not an
issue... :^/

****

You're asking that the RFC have a warning to implementors that
authorization must be done using the canonicalized principal name, not
the name the user actually asked for. This should be self-evident. The
RFC should not say otherwise.

****

> might canonicalize) and password.

Yes, I was thinking of mailboxes and the like as well.

...
> mapping and authorization.

Huh? "Very simplistic models are used for both mapping and
authorization" precisely because no infrastructure is in place to make
principal name mapping, and therefore authorization, simple without
being simplistic. I imagine that this is one of the reasons MS ended up
doing its PAC-in-Kerberos-tickets thing; their approach is certainly
simple, but not simplistic.

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: 20 Nov 2000 14:47:33 -0500

> successful authentication.

That validates that the TGT acquired is a valid one for the client
principal contained in it, and the one for which the password was
given.  It does nothing to protect the referral step itself.  (Though
if you *know* that the user typing the password couldn't possibly be
working with whoever would be spoofing the KDC, then maybe it'd be
safe to rely on that data once the TGT is validated.)

> RFC should not say otherwise.

The "validity of the referral is established" text doesn't say
otherwise, directly, but for someone using too simplistic a model
(i.e., the account name is what you use initially for the principal
name, though it may not be the canonical form, and that principal is
always authorized to log in, so getting a TGT means you get in), they
might interpret it to mean that they can rely on the referral info
itself as being secure and thus something they can base their
authorization security on.  Yet for someone not researching Kerberos
in detail and thinking hard about these issues -- like some of the
application writers who've tried to adopt Kerberos in their protocols,
and including even some of the Kerberos developers -- it may not be an
obviously wrong approach.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Nov 2000 15:06:05 -0500

> safe to rely on that data once the TGT is validated.)

Come on. All KDC responses are spoofable, at the very least whenever UDP
is used instead of TCP. So how do you validate a Kerberos ticket in the
face of that? Clearly, tickets and authenticators are validated if: a)
they decrypt properly using the appropriate service keys and b) their
contents checks out (e.g., HostAddressess checks) and c) the
authenticator is not being replayed.

The question is, can someone spoof a KDC UPN canon referral in such a
way that the client still obtains and validates a TGT and would that be
a security issue. The answer to the latter is clearly yes. The answer
to the former is less clear.

Let's see. An attacker would require the following:

 - control of some realm

 - a trust relationship such that the attacker's realm is trusted by the
   client's realm so the client can validate tickets from the
   attacker's realm

 - knowledge of the user's pre-authentication credentials (e.g., her
   password, her certificate, etc...) so the attacker can forge tickets
   for the user in question

Am I missing something?

Hmmmm, but if the attacker has those things then the attacker is in
anyways and KDC referral spoofing becomes the least of your headaches.

If an attacker controls a trusted realm, the attacker is in.

If an attacker knows users password and/or other such credentials (like
chopped off fingers, for fingerprint readers, say :) then the attacker
is in.

> obviously wrong approach.

Ok, so add explicit warnings. For example:

"
Clients that request canonicalization MUST perform access checks based
on the user principal name as canonicalized.
"

And:

"
Clients must validate TGTs by using them to obtain service tickets for
service principals, local to the client, whose keys can be used to
validate said service tickets.
"

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 20 Nov 2000 18:43:57 -0500

>    password, her certificate, etc...) so the attacker can forge tickets

Yea, the attacker only needs the first two items, not the third.  If
he controls some realm, he can therefore create a new principal in
that realm (for which he would supposedly know the password).  Then
all he has to do is forge the canonicalization response to point to
his new principal in his own realm.

For example, say I control BAR.COM, which has a shared key with
FOO.COM.  I want to break into the [email-masked] account.  I can create
a [email-masked] principle, and the forge a canonicalization of
[email-masked]>[email-masked] when I try to login.  I can then
successfully obtain [email-masked] tickets, which can authenticate to
any "test" put forward (except the fact that FOO.COM != BAR.COM).

This implies that the authorization scheme must be able to
authenticate the canonicalization.  One means of this authentication
is a priori knowledge of the mapping (e.g., via a .k5login).  Or,
there can be some reasonable default (local host checks
<login>@<LOCALREALM> against <principal>@<TICKET_REALM>).

I think it makes sense to be explicit about these pitfalls.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
       [email-masked]                        PGP key available

---

From: Ken Raeburn <[email-masked]>
Date: 20 Nov 2000 19:28:49 -0500

> <login>@<LOCALREALM> against <principal>@<TICKET_REALM>).

Well, it's not quite authentication of the canonicalization; it'd be
verification that *whatever* principal it winds up with is allowed
access to the revelant resources.  (I.e., if the user@FOO->user@BAR
mapping isn't something the FOO realm KDC knows about, you can't
validate it, but if user@BAR is explicitly allowed to log in as user
then it really doesn't matter.)

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Nov 2000 10:23:50 -0500

> his new principal in his own realm.

Hmmm. DOn't think so. The attacker's realm has to issue a ticket after
all and the ticket has to be encrypted in the user's key. So the
attacker's realm has to know the user's key else the user's client
can't decrypt the ticket, much less validate it. I assume the attacker
would not require the user to pre-authenticate.

> any "test" put forward (except the fact that FOO.COM != BAR.COM).

Again, the client has to be able to decrypt those [email-masked] tickets.

> <login>@<LOCALREALM> against <principal>@<TICKET_REALM>).

While I would prefer that the referral be authenticated, perhaps with a
signature in the key of an SPN on the client host, I don't believe you
can easily abuse the un-authenticated referral. Remember, UDP AS_REPs
and TGS_REPs can be spoofed even if referrals are not involved; I think
the situation wrt spoofing is the same regardless of wether referrals
are involved.

> I think it makes sense to be explicit about these pitfalls.

Oh, absolutely. My experience with UPN canon referrals in Windows 2000
release was that there were consistency issues in the implementation. I
posted about this back in September. The issues I pointed out were
implementation specific, though I also think they are likely to hit
other vendors as well.

See http://www.mit.edu:8008/menelaus.mit.edu/kprot/506

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 21 Nov 2000 10:59:20 -0500

> would not require the user to pre-authenticate.

Right, and the attacker, who is trying to break into <user>'s account,
knows the password to <[email-masked]>.  This is not an attack trying
to spoof the user, it's trying to spoof the login system.  So, the
attacker is acting as the user-meat; they are not expecting the real
user-meat to be involved in this attack.

> Again, the client has to be able to decrypt those [email-masked] tickets.

And since the attacker _is_ the "user" in this case, they can decrypt
the [email-masked] tickets, because the person sitting at the keyboard
is the attacker, and the attacker controls [email-masked].

> the situation wrt spoofing is the same regardless of wether referrals

The difference is that I can check that the ticket I receive is for
the principal I requested.  If it is not, then I know someone is
spoofing me.  Let's follow this example.  Let's assume realms FOO and
BAR, and an attacker is trying to login as "user" in the FOO domain.
The attacker forges the TGS_REP for user@BAR with a known password.
Obviously they can get a ticket.  However, the login host knows that
user@BAR != user@FOO, so it's an error.  If the host doesn't perform
this check, then yes, this attack is completely open.

Let's assume the attacker actually generates a ticket for user@FOO
instead of user@BAR, in order to get around that check.  Fine.  The
next step is to try to get a service ticket for a local key.  We can
presume the attacker doesn't know this key (otherwise they could just
print themselves any ticket they wish).  This means that the
validation ticket must be obtained through the FOO KDC.  But when the
client tries to get host/fqdn.foo@FOO using the ticket from FOO, it
will return an error because the TGT would be invalid for the FOO
realm.

The security of the system is based upon knowing the name of the
authenticated entity.  And that's the problem.  Unauthenticated
referrals imply that you CANNOT perform this name check, which leaves
you vulnerable to spoofing attacks.

-derek

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Nov 2000 11:05:42 -0500

> is the attacker, and the attacker controls [email-masked].

The _CLIENT_ needs to be able to decrypt and validate the ticket. That
means that the _CLIENT_ needs to know the password for [email-masked] BUT
the client only knows the _real user_'s password. Thus, if the client is
to decrypt and validate the ticket for [email-masked] then the key for
[email-masked] must match the password that the real user actually typed
in.

...

> this check, then yes, this attack is completely open.

Again, if the keys for user@BAR and user@FOO don't match the gig is up
as well. This is because the client needs to validate the ticket for
user@BAR but only knows user@FOO's password.

> will return an error because the TGT would be invalid for the FOO

The user@BAR ticket also has to be validated by obtaining a ticket for a
service principal local to the client (and for which the client knows
the key). But first the user@BAR ticket has to be decrypted by the
client.

> you vulnerable to spoofing attacks.

Please re-read my response. Am I correct in stating that the client
knows only user@FOO's password and must be able to decrypt the user@BAR
ticket using that password, implying that the attacker must know
user@FOO's password for the attack to work?

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: 21 Nov 2000 13:05:33 -0500

> would not require the user to pre-authenticate.

Nico, you need to be more paranoid. :-)
The user at the keyboard is *also* out to get you.  Everybody is.

For this attack, we (Derek and I, at least) are assuming that the user
and the KDC admin are working together to try to compromise some
random account.  So the user will know the correct password for the
principal to which the software is redirected.  If the authorization
model is a broken one, that may be enough to compromise the machine,
and the text I complained about leads one to believe that the referral
is authenticated once the acquired TGT has been validated, and that it
therefore might be relied on in building the authorization model.

Attacks on genuine users just trying to log in also need to be
considered, but I don't see one here, other than the obvious denial of
service.

> the situation wrt spoofing is the same regardless of wether referrals

For AS_REP, we tell everyone that the decoded results have to be
checked against a local secret key in order to be validated.  (Yes,
likely involving one or more additional TGS_REQ exchanges.)  The text
I was complaining about claims that once this is done, the referral or
canonicalization is validated too, which is not the case.

(A spoofed TGS_REP won't decrypt properly unless the user has leaked
her TGT session key, so it's "just" a denial of service.)

Ken

---

From: Derek Atkins <[email-masked]>
Date: 21 Nov 2000 13:05:57 -0500

> [email-masked] must match the password that the real user actually typed

How does the _CLIENT_ know the user's password?  Is it stored in a
keytab somewhere?  In my scenario, the person sitting at the keyboard
is the attacker (or a bad-guy in collusion with the attacker), not the
real user.  So, the bad-guy (sitting at the keyboard) _DOES_ know the
password to "[email-masked]" (although they do not know the password to
the real id, "[email-masked]").  The _CLIENT_ asks the person for a
password, and the _PERSON_ types in the password.  In this case, the
_PERSON_ is the bad-guy.

> user@BAR but only knows user@FOO's password.

No, the real person, 'user', only knows user@FOO's password.  The bad
guy, the person sitting at the computer trying to break into 'user's
account, DOES know user@BAR, so they CAN type in the correct ticket.

> the key). But first the user@BAR ticket has to be decrypted by the

Right, and the bad-guy, typing at the keyboard, can supply the correct
password for user@BAR.  That decrypts the user@BAR ticket, which will
then be able to obtain the local service ticket.

> user@FOO's password for the attack to work?

I have re-read it, but you're still wrong.  Go re-read mine.

You need to differentiate the client (computer program/code) from the
user or person (a homo sapien sitting at some I/O device).

The client knows whatever password(s) the user sitting at the client
knows.  In this scenario, the person sitting at the client is the
attacker (or someone colluding with the attacker).  So the attacker
knows the password to user@BAR (but not user@FOO).

The goal of this attack is to get the client to accept tickets for
user@BAR as an equivalent to user@FOO.  This can be done by forging
the unauthenticated canonicalization response.  The attacker can then
supply the password for user@BAR, and then the client will dutifully
decrypt it (because the user is the bad-guy).

Perhaps I should be more careful choosing names.

The good guy is named "god" and has an account on host "pearly-gates"
in the realm "HEAVEN".  Normally, this user would log into
pearly-gates (pg) with the credentials god@HEAVEN.  Let's assume there
is a bad guy, satan, who controls his own kerberos realm, HELL.
HEAVEN and HELL have shared keys, so in essence they trust each other.
This implies that satan@HELL can obtain a service ticket for
host/pearly-gates@HEAVEN.  Are you with me so far?

Now, satan a bad guy.  He want's to log into pearly-gates, breaking
into god's account.  What he can do is try to log into pg as 'god',
but forge a canonicalization response from the HEAVEN KDC such that
god@HEAVEN->satan@HELL.  So, pg will now attempt to get a TGT for
satan@HELL.  Obviously satan knows that password, and can supply it to
pg when asked.  Next, pg, trying to be smart, will attempt to obtain a
ticket for host/pearly-gates@HEAVEN, using the TGT it just decrypted.
As stated above, this will work.

There are only ways to protect against this attack.  The first is for
the client to know a priori that satan@HELL is _NOT_ a valid
canonicalization of god@HEAVEN.  The second is to authenticate the
canonicalization.

If this is still unclear to you, I will be more than happy to sit down
with you in San Diego and explain in front of a large white board.

-derek

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Nov 2000 13:43:42 -0500

On Tue, Nov 21, 2000 at 01:05:57PM -0500, Derek Atkins wrote:
> How does the _CLIENT_ know the user's password?

The user types it in when the client prompts him.

>                                                  Is it stored in a

Aha! Thank you. Now I see your point. The attacker is the user. But read on.

> account, DOES know user@BAR, so they CAN type in the correct ticket.

Right. Thank you. But read on.

> I have re-read it, but you're still wrong.  Go re-read mine.

I have and I get it now.

And the attacker doesn't even need to own the trusted realm (BAR). It
suffices that the attacker have a normal account on BAR.

BUT, if the client authorizes the attacker based on the canonicalized
UPN then the attacker will not have achieved greater access than she
would have obtained by logging in as herself (user@BAR).

So we're back to square 1. Which is: if the attacker is the user, he
gets has no way to abuse referral spoofing and thus obtain additional
access and if the attacker is not the user then the attacker needs to
know the user's password and have access to the BAR realm (or must be
able to spoof BAR responses but also must know BAR's TGS key).

> user or person (a homo sapien sitting at some I/O device).

I was looking at the attacker as not being the user because I had
discounted that the attacker-as-the-user could abuse referrals. See
above.

> user@BAR as an equivalent to user@FOO.

Ok.

>                                         This can be done by forging
> the unauthenticated canonicalization response.

Only if the client authorizes the user based on the original name and
not the canonicalized name. Arguably that's the wrong thing to do and we
have already established this.

>                                                 The attacker can then

> host/pearly-gates@HEAVEN.  Are you with me so far?

Sure, though I don't understand why HEAVEN would trust HELL :^)

> canonicalization of god@HEAVEN.  The second is to authenticate the

The third is for the client to authorize satan@HELL as satan@HELL and
not as god@HEAVEN as originally requested. This is not hard to do and is
the RIGHT thing to do anyways.

> with you in San Diego and explain in front of a large white board.

LOL!

 - I'm not in San Diego. Will you come out to the East Coast? ;)

 - I get your point.

 - I still think there's no hole here.

 - Your scenario had already been discussed (previous posts discussed
   the need for text that requires the client to authorize users based
   on canonicalized UPNs when canonicalization is used).

What next then?

I think UPN referrals are as secure from attack as AS/TGS exchanges.

I'm open to the possibility that I'm wrong. Again, am I missing something?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Nov 2000 14:21:00 -0500

> The user at the keyboard is *also* out to get you.  Everybody is.

Yes. But if the client authorizes the user using the canonicalized UPN
then there is no problem.

Which brings us back to: the RFC should have a warning that
authorization decisions should be made based on canonical UPN names.

A statement that makes sense in any system, don't you think? :)

...

>                                                 If the authorization
> model is a broken one,

We're going around in circles. We've agreed about authorizing based on
canonical names only.

I'm interested in knowing if there's a security problem with referrals.

Since we've settled on the authorization issue, is there any other
problem?

I think there is not.

This thread has dragged on. Let's end it here. I've proposed text
changes to the draft.

...

> considered, but I don't see one here, other than the obvious denial of

Right. Same here. So two issues down. Are there any left?

> canonicalization is validated too, which is not the case.

Right. We're in agreement.

...

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 21 Nov 2000 15:17:13 -0500

> would have obtained by logging in as herself (user@BAR).

The problem is that the client authenticates the attacker based on the
canonicalized name (does this user have a password that obtains a TGT
that can obtain a service ticket for a key the client knows), but
AUTHORIZES the attacker based upon the original username requested.
To do otherwise implies that the client knows a priori all the
potential canonicalizations that are allowed to login to a particular
account.  If you have to know ahead of time, then what is the point of
canonicalization at the KDC?  Why not just let the user choose the
principal name directly?

> have already established this.

Well, I think the client needs to authorize the client based on BOTH
the original name _AND_ the canonicalized name.  In other words, the
client authorization needs to go something along the lines of:

	user wants to access account 'god'
	client makes TGT_REQ for 'god@HEAVEN'
	kdc returns canonicalization 'god@HEAVEN->satan@HELL'
	client makes TGT_REQ for 'satan@HELL'
	KDC responds with TGT_REP for 'satan@HELL'
	<user password obtained and TGT decrypted>
		[obtain cross-realm TGT]
	client makes AS_REQ for 'host/client.name@HEAVEN'
	KDC responds with AS_REP for 'host/client.name@HEAVEN'
	client verifies AS_REP against keytab
	client verifies user principal (satan@HELL) against list of
		known principals for account 'god'

It is this last step that implies that user-name canonicalization is a
bad (or at least extrememly challenging) proposition.  It implies the
client must know, for each account, the list of valid canonicalized
names that are authorized to use it.  If that is the case, then why
centralize the canonicalization?  Why not localize it to the
account/client?

> the RIGHT thing to do anyways.

Right.  Indeed, this is what happens (as for as authentication is
concerned).  The TGT obtained is for principal satan@HELL, so that is
the authenticated name.  However, the client is also authorizing
access to account 'god' based upon successful authentication, which
we've shown can be done.  Alternatively, to do what you say, the
client would have to know a priori what the canonicalization should
be, so what's the point?  If the client already knows what it should
be, then the client should just ask for that in the first place.

>  - I'm not in San Diego. Will you come out to the East Coast? ;)

I meant in San Diego at the IETF; I'm on the East Coast, too, most
of the time.

-derek

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Nov 2000 15:44:46 -0500

> canonicalization at the KDC?  Why not just let the user choose the

I don't understand. Why can't the client authorize based on the
canonical name? The client surely DOES find out what the canonical UPN
is.

...
> client authorization needs to go something along the lines of:

Why? The original UPN is just a place holder, a marker, and therefore
is not a security entity and so cannot and MUST NOT be used for
authorization.

...
> centralize the canonicalization?  Why not localize it to the

I disagree. Once the client knows the canonical UPN it can forget the
original name, IMO. Therefore the client doesn't have to confirm that
the original name was indeed a valid alias for the canonical name.

The fact that the client validates the TGT obtained for the canonical
name is proof that all is ok and that the referral was good anyways.

The only way that the referral can be bad is if the attacker knows the
user's password (wether the user and the attacker are the same entity
does not change this) spoofs the AS_REP and has priviledged, perhaps
illegitimate access to the other trusted, realm.

If an attacker has control of a realm trusted by yours then you've got
big problems. The attacker can abuse any number things. To analyze the
security of UPN referrals we have to assume that the realms haven't been
cracked.

So then can we agree that the client can verify that the referral was
good if it can get a TGT for the canonicalized UPN and can validate
that TGT? I think so.

> we've shown can be done.

Are you saying that there is a client implementation which authorizes
based on the requested UPN instead of the canonical UPN? That would be
a bug. Take it up with the vendor. Any such bug does not make referrals
inherently weak in theory, only in practice.

>                           Alternatively, to do what you say, the

See above. I don't think the client has to know alis<->canon UPN
mappings a priori.

> I meant in San Diego at the IETF; I'm on the East Coast, too, most

Ah. I'm not planning on attending the IETF meeting.

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 29 Nov 2000 10:44:47 -0500

> canonical name? The client surely DOES find out what the canonical UPN

The client needs to authorize access to the requested name using the
authentication of the canonical name.  Namely, does 'canonical name'
have the authority to access 'requested name'?  Yes, the client does
find out what the 'canonical name' is, but the client cannot know for
sure that that particular canonical name really is a canonical name
for the requested name, because the name-canonicalization response can
be forged.

Think of it this way, you ask for god, you forge a response that says
"try satan".  You know satan's password (you _are_ the bad guy, after
all), so you can supply satan's password.  However, the client doesn't
know whether or not 'satan' is a real canonicalization of 'god'.  All
it knows is that the user sitting at the keyboard knows the password
to 'satan', but that doesn't tell the client whether or not user
'satan' can access the account of 'god' (which was the original
requested account name).

> is not a security entity and so cannot and MUST NOT be used for

See, that's where we disagree.  I'm envisioning a Unix 'login' process
here, where the original UPN is certainly NOT a place holder, but is a
real security entity, an account name.  The question you need to ask
is, "does the authenticated user have access to the requested object?"
where the authenticated user is the canonicalized UPN, and the
requested object is the account of the ORIGINAL UPN.

Does 'satan' have the authority to login to the local account 'god'?

> name is proof that all is ok and that the referral was good anyways.

No, you are confused.  The fact that the client validates the TGT
obtained for the 'canonical name' proves that the client knows the
password for the reffered name.  There is no proof that the referred
name is REALLY canonical to the requested name.

> illegitimate access to the other trusted, realm.

Not true.  According to section 5.9.1 regarding the checksum on a
KRB_ERROR message:

     If the error is in response to an AS request, then the checksum
     should be calulated using the client's secret key ONLY if there
     has been suitable preauthentication to prove knowledge of the
     secret key by the client[33]. If a checksum can not be computed
     because the key to be used is not available, no checksum will be
     included.

This implies that the client cannot necessarily trust the
KRB_ERR_WRONG_REALM error message from as AS_REQ.  An attacker against
a client can forge a KRB_ERR_WRONG_REALM error response with a NULL
checksum and the client has no way of knowing whether it is real.
According to the spec, the client, on receipt of the
KRB_ERR_WRONG_REALM, is supposed to retry the request with the
principal and realm name specified in the error message.

So, basically, an attacker against a host could forge such an error
message WITHOUT knowledge of the real key used by the real user.

> security of UPN referrals we have to assume that the realms haven't been

Once PKCROSS comes into play, this will certainly become a major
issue.  So, you need to limit what another trusted realm can do.

> good if it can get a TGT for the canonicalized UPN and can validate

No, we cannot.  All that you can verify is that the user knows the
password for the canonicalized UPN.  You still have no verification
that the KRB_ERR_WRONG_REALM wasn't forged.

> inherently weak in theory, only in practice.

You're not authorizing BASED on the requested UPN; you authorize
ACCESS to the request UPN (using the authenticated name, which in this
case is the canonicalized UPN).  I'll say it again, 'does "satan" have
access to account "god"'?  The fact that satan can authenticate as
satan does not imply that satan can access account god.  I've already
shown how satan could get the client to believe a referral of
god->satan by forging a KRB_ERR_WRONG_REALM message.

In any case, I've reached my time limit dealing with this topic.
Anything else is just a waste of time, so I will ignore any further
replies.

Have a nice day,

-derek

---

From: Ken Raeburn <[email-masked]>
Date: 29 Nov 2000 18:34:33 -0500

Nicolas Williams <[email-masked]> writes:

> You are confused. The client should let the user in to the account named
> by the canonical UPN, not that which the user asked for.

Actually, at this point, I'd disagree.

In a UNIX environment, I'd take the name typed in as the local account
name, and see if the user is authorized.  Using Derek's example, I'd
say the user/intruder should be logged into the "god" account, but
only if the principal "satan" is on the right access list.

You could define your interface otherwise, but then what you're asking
the user for isn't an account name, it's some other sort of
authentication name or nickname, and you're deriving the account name
from the authenticated identity.  But depending on the application and
environment, mapping from principal to account may be much harder than
the other direction.

> Why do you insist on authorizing access to the requested resource
> instead of the resource named by the canonical UPN? I don't get it. If
> the referral is legitimate then the requested UPN name should just be a
> place-holder anyways, not an actual account.

Not necessarily.  If the local account names and principal names
aren't tightly bound, the local account name is probably what matters
to the software outside of the authentication step.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 30 Nov 2000 09:44:55 -0500

> only if the principal "satan" is on the right access list.

As long as the access check is secure and you're not relying on UPN
canonicalization as your access check then you're ok.

BTW, it is possible for a PAM module to change the user item in a PAM
handle. PAM applications have to honor such changes though (some
PAMified /bin/login's do, such as FreeBSD's). And it doesn't make sense
for more than one change to occur, and it should be the first module
that makes any such change, IMO.

> environment, mapping from principal to account may be much harder than

Ok. Look, UPN canonicalization means just that: that the original UPN is
an alias, a nickname of the canonical UPN.

Kerberos does nothing to help you map UPNs to actual Unix accounts, or
POP3 accounts, or Windows accounts, or...

But don't say that this is a problem with UPN canonicalization. It
isn't. It's a problem with Kerberos itself, that PN->other names
mappings are not part of Kerberos and therefore it's up to the
implementors to design secure mapping systems.

MS dealt with it by putting the Windows user profile info right into
the ticket. How do you propose to deal with this problem.

> to the software outside of the authentication step.

So you need a secure mechanism for mapping a canonical UPN to an account
name, and in the case of Unix/PAM auth you may already know the account
name and therefore you just need to validate the mapping.

Again, this has nothing to do with UPN canonicalization.

And again, as long as you lookup/validate the mapping where the LHS is
the _canonical_ UPN then you're safe from attacks based on spoofed
referrals. If you use the alias UPN and a referral is involved then you
have a serious implementation flaw.

Nico
--