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

From: Ken Raeburn <[email-masked]>
Date: 07 Dec 2000 18:29:56 -0500

Doug tells me this bounced when I sent it....

------- Start of forwarded message -------
Subject: 
            Re: Section 3 (take 2) Kerberos Revisions for comment
       Date: 
            28 Nov 2000 18:55:31 -0500
      From: 
            Ken Raeburn <[email-masked]>
        To: 
            [email-masked]
 References: 
            1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11

Nicolas Williams <[email-masked]> writes:
> >                                                 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 think we are going in circles, yes, between a couple different
points.

We're agreed that using the canonical name is the only way to do it
under the current spec.  That was never in dispute.  My original point
was about text that would mislead someone who didn't know that and was
trying to figure it out for herself.

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

In the AS_REQ case, they're insecure; you can't do them securely
unless a TGS_REQ fits your circumstances.  As long as everyone knows
this, no, there's no "security problem".  (Unless you count not being
able to implement things you want in your security framework because
of this lack, but that's a different topic.)

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

Oh yes, the text in <[email-masked]>.

    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.

I'd rephrase them a little, keeping in mind that some clients (e.g.,
kinit) don't care about validation or access checks, but they're
basically right.  For example, "...MUST perform any desired access
checks...", "clients can validate..."  That's why it took me so long
to get my proposed changes sent out; I can spend forever tweaking the
wording and still not get it quite right. :-)

I thought my original suggestion of deleting half a sentence was
adequate, but maybe there's less information in the context than I
recall.

Ken
------- End of forwarded message -------

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 8 Dec 2000 10:41:08 -0500

I think we're close to putting this to rest. Of course, the issues on
the other thread, re: cgss_canonicalize_name() and so on may not be
dead yet.

> trying to figure it out for herself.

Well, most RFCs are hard to read and understand without having other
sources of information about the subject at hand, such as experience
with existing implementations, natural language descriptions of the
protocols/algorythms, etc...

;)

> of this lack, but that's a different topic.)

Well, yes, but I think we established also that IF one uses only the
canonical name for authorization, and IF TGTs are validated, then an
attacker cannot fool a client, using AS_REP spoofing, into allowing her
access rights she didn't already have.

In this sense there is no new vulnerability in AS referrals.

Use of TCP with strong ISNs should certainly reduce the exposure to KDC
spoofing. KDC spoofing should, at worst, make possible only a DoS
attack. I believe that's the case, even with AS referrals thrown in the
mix.

> Oh yes, the text in <[email-masked]>.

:)

> wording and still not get it quite right. :-)

Hmmm. Well. Hmmm, see, kinit doesn't have to validate TGTs, no, but
that's because kinit doesn't perform any access checks.

How about:

	Clients that request canonicalization MUST perform access checks
	based on the user principal name as canonicalized and MUST
	validate credentials so obtained when the clients are using
	Kerberos for password validation and user authorization.

I'm sure there's a much better way to phrase that. Perhaps:

	Clients that request canonicalization MUST perform access checks
	based on the user principal name as canonicalized and MUST
	validate credentials so obtained when the clients are using
	Kerberos for interactive authentication.

Yeah?

This leaves kinit-type clients unrestricted since kinit is not
performing authentication.

> adequate, but maybe there's less information in the context than I

I'd have to go look at the draft again and I don't have time to do so
today -- gotta go.

> Ken

Nico
--