capaths questions

[Nicolas Williams]

On Mon, May 17, 2004 at 05:24:46PM -0500, Matt Crawford wrote:
> 
> On May 17, 2004, at 15:56, Sam Hartman wrote:
> 
> >    Derek> True, but the destination KDC does get to enforce it (as
> >    Derek> you suggest later).
> >
> >And should not do so.  The destination kdc should leave the policy
> >checked flag clear and the application server should reject.
> 
> I've been following the thread quietly until this point, but now I have 
> to disagree.  I want to be able to have my FNAL.GOV deny the service 
> ticket if I choose to, or leave it up to the service to deny access.  

And, believe it or not, that's exactly what Sam said.

The destination KDC should always be free to reject x-realm TGS-REQs as
per its realm transit policy, and applications should always be free to
reject tickets used in AP-REQs as per-their realm transit policies.

So the KDC rejects or issues tickets, but if it issues then not setting
TRANSITED-POLICY-CHECKED doesn't mean that it didn't apply a transited
policy, just that it's not saying "go ahead and accept this ticket" to
the application.  A very subtle distinction.

I think that the TRANSITED-POLICY-CHECKED flag is only useful to
applications which don't care that much about security (e.g., they
server not-really-secret information).  This is because different
applications may have different requirements that render a
single-realm-wide realm transit policy useless (though the KDC could
have a per-target principal custom policy).

Note that for an application to reject a realm transit doesn't
necessarily mean responding to the AP-REQ with a KRB-ERROR -- it could
proceed and send an application-level error message, or it could proceed
and prompt the client for additional authentication (i.e., it could
trust the session key without considering the client principal to be
authenticated by Kerberos V).

Nico
--