Subject: Re: Need clarification for unknown auth data

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Apr 2002 12:55:26 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Are you sure that expecting services to look at or even
    Martin> honor any authorization is a reliable solution.

The consensus among working group members who had expressed an opinion
up to this point was that authorization data was mandatory.  No one
currently implements this, and there is an implementation note in the
clarifications draft that relying on the behavior may lead to security
problems.  The belief is that for extensions, AD will be considered
critical.

I don't know how other implementers plan to handle this, but I suspect
MIT will provide ways to register handlers for various AD data types,
and will provide default AD handlers for data types (if any) that can
be handled in the the library.  For example, if there was an AD
element that said the ticket could only be used on a particular host,
we'd handle that in the library.

If you want to write portable (mechanism-independent) GSSAPI
applications, you should not use any AD elements that cannot be
handled in your implementation libraries that you're likely to
encounter.

I suspect that the application of AD outside of the AD-IF-RELEVANT
container  will be fairly limited.

I was involved in an attempt at SLC to change the default to have
non-critical AD.  Even then, we were going to allow a critical
container.  But most of the working group felt that defaulting to
critical was more appropriate for a data type that was intended to
restrict use of tickets.  After it became obvious that the only issue
was the default and that everyone who had expressed an opinion wanted
the ability to have both critical and non-critical AD, it didn't seem
like arguing over a default was a productive use of the working
group's time.  So I and the others who wanted default non-critical AD
withdrew our objections.

--Sam

---

From: "Yordan Rouskov" <[email-masked]>
Date: Tue, 23 Apr 2002 16:11:22 -0700

Is this the final decision? If so, can the I-D be updated to reflect it.

Right now, the most likely I-D interpretation is that TGS should fail.
tx

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Tuesday, April 23, 2002 1:27 PM
To: Nicolas Williams
Cc: [email-masked]; Yordan Rouskov
Subject: Re: Need clarification for unknown auth data

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> [NOTE: what's up with the malformed headers I see on most
    Nicolas> posts to this list?]

    Nicolas> On Tue, Apr 23, 2002 at 01:55:50PM -0500,
    Nicolas> [email-masked] wrote:
    >> Subject: Need clarification for unknown auth data From: "Yordan
    >> Rouskov" <[email-masked]>
    >> 
    >> Recent "Kerberos Clarifications" I-D dictates that requests
    >> containing unknown auth data should be rejected.=20
    >> 
    >> What would be the TGS response to a TGS request containing
    >> unknown auth data?  Obviously the request should fail, but with
    >> what error code? Can someone please clarify.=20
    >> 
    >> thanks
    >> 

    Nicolas> Isn't this covered by the AD-IF-RELEVANT container?

    Nicolas> Personally, I think we need AD-IF-KDC-RELEVANT and
    Nicolas> AD-IF-AP-RELEVANT containers as well, this way AD types
    Nicolas> unknown to a TGS need not prevent ticket issuance, if
    Nicolas> that AD type is critical only to apps.

I actually proposed that TGS ignore AD it cannot understand.  The point
seems to be for application authorization not for TGS.  OR rather it
seems to decrease the utilitye of AD if the KDC has to know about
everything.

---

From: [email-masked]
Date: Thu, 25 Apr 2002 16:22:15 -0400

Fine.

I do think that ADs that target the TGS are imaginable: think
forwarding restricted TGTs (no, that idea is not going
anywhere, it's just an example).

But then, at least for extensions, we might as well specify
AD-KDC-RELEVANT.

Cheers,

Nico
--  

> Sent: Thursday, April 25, 2002 3:32 PM
> To: Ken Raeburn
>     Nicolas> Yes, but, your point is that ADs are usually meant for
>     Nicolas> APs, not for TGSs. This is true today. But it might not
>     Nicolas> be true tomorrow.
> I'd actually like to go back to the arguments about why we  consider
>     Nicolas> criticality important for authorization data.
> 
> First, remember that  for other typed holes we don't have critical
> elements.  The party participating in the exchange needs to check the
> results of the request and see if the option was understood.
> 
> However, authorization data is a case where a the KDC (or a client
> decreasing privileges of a ticket) is sending a restriction to the
> application server.
> 
> In the case of the KDC the party applying the restriction does not
> directly communicate with the application server, so the application
> server needs to enforce the restriction rather than relying on the
> client.  In the case of privilege reduction, the client communicating
> with the application server may no longer desire the privilege
> reduction, so agin it needs to be enforced at the application server.
> 
> Even if  ADs tend to be used targeted at the TGS, ignoring them at the
> TGS causes no harm.  They will also be interpreted at the application
> server, where they will not be understood and will cause the request
> to fail.  
> 
> However, failing requests at the TGS if AD is not understood creates
> an interoperability problem.  It means that applications will (in
> practice at least) have to wait for KDCs to be upgraded even when the
> client and server are both known to support restrictions.
> 
> 
> I just don't see anything we gain by requiring the TGS to fail unknown
> AD even if TGS-targeted AD become more common.
> 

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.