Subject: Re: Need clarification for unknown auth data

From: [email-masked]
Date: Tue, 23 Apr 2002 13:55:50 -0500 (CDT)

[131.107.8.8])
	by dns2.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA28835
	for <[email-masked]>; Tue, 23 Apr 2002 12:39:58 -0500 (CDT)
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by
df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.5255);
	 Tue, 23 Apr 2002 10:40:02 -0700
Received: from 10.197.0.60 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail
VirusWall NT); Tue, 23 Apr 2002 10:39:23 -0700
Received: from DF-SPIKE.platinum.corp.microsoft.com ([10.197.1.14]) by
DF-YURI.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 23 Apr 2002 10:39:23 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Subject: Need clarification for unknown auth data
Date: Tue, 23 Apr 2002 10:39:23 -0700
Message-ID: <[email-masked]>
Thread-Topic: Need clarification for unknown auth data
Thread-Index: AcHq7c3/UPxeXypiQEGcJlYQ/cTeHA==
From: "Yordan Rouskov" <[email-masked]>
To: <[email-masked]>
X-OriginalArrivalTime: 23 Apr 2002 17:39:23.0088 (UTC) FILETIME=[CE360500:01C1EAED]
Sender: [email-masked]
Precedence: bulk

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1EAED.CE30895B"

------_=_NextPart_001_01C1EAED.CE30895B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

------_=_NextPart_001_01C1EAED.CE30895B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.6177.0">
<TITLE>Need clarification for unknown auth data</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier">Recent =
&quot;Kerberos Clarifications&quot; I-D dictates that requests =
containing unknown auth data should be rejected. </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier">What would be the =
TGS response to a TGS request containing unknown auth data?</FONT>

<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier">Obviously the =
request should fail, but with what error code? Can someone please =
clarify. </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Courier">thanks</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1EAED.CE30895B--

--------------InterScan_NT_MIME_Boundary--

---

From: "Nicolas Williams" <[email-masked]>
Date: Tue, 23 Apr 2002 15:30:59 -0400

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

> Obviously the request should fail, but with what error code? Can someone

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

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

In any case, AD not in a AD-IF-*RELEVANT container should cause any
acceptor to reject the AP exchange, and that should go for TGS exchanges
as well as traditional AP exchanges.

Cheers,

Nico
-- 

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.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 23 Apr 2002 16:27:02 -0400

>>>>> "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: Ken Raeburn <[email-masked]>
Date: 23 Apr 2002 19:31:05 -0400

> rather it seems to decrease the utilitye of AD if the KDC has to know

What if we add an AD type that the KDC is supposed to act on (say,
limit issued tickets to all ftp services); ignoring it in older KDCs
would be the wrong thing.

Ken

---

From: Sam Hartman <[email-masked]>
Date: Tue, 23 Apr 2002 20:09:14 -0400

>>>>> "Ken" == Ken Raeburn <[email-masked]> writes:

    Ken> Sam Hartman <[email-masked]> writes:
    >> 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.

    Ken> What if we add an AD type that the KDC is supposed to act on
    Ken> (say, limit issued tickets to all ftp services); ignoring it
    Ken> in older KDCs would be the wrong thing.

    Ken> Ken

I'd be OK adding an AD-KDC-MANDATORY type or something.  However, in
general, rather than limiting the tickets being issued, just include
an AD element for the service; if the service doesn't understand, then
it will refuse the ticket.

The TGS service is a special case because it has semantics that can be
understood at the Kerberos level.  The TGS really isn't useful in and
of itself; it is only useful if I use the ticket along with some
application service.  So I think I want the default behavior to be
that the TGS allows me to add arbitrary restrictions--especially ones
it doesn't know about--so that I can restrict use of application
services.

---

From: "Nicolas Williams" <[email-masked]>
Date: Wed, 24 Apr 2002 09:55:29 -0400

Huh? How would implementations that didn't know about AD-KDC-MANDATORY
behave? Answer: they would ignore it.

AD-IF-KDC-RELEVANT and AD-IF-AP-RELEVANT are very easy to specify. Why
not specify them now?

The TGS could even change AD-IF-AP-RELEVANT containers to AD-IF-RELEVANT
in the non-x-realm tickets it issues so as to maitain compatibility
with applications that are not aware of AD-IF-AP-RELEVANT, and it could
remove any AD-IF-KDC-RELEVANT containers (but no their contents) from
non-x-realm tickets issued for the same reason.

Whatever is decided, I'm arguing for consistency. So use AD-KDC-RELEVANT,
instead of AD-KDC-MANDATORY, and if AD is critical in AP exchanges,
it should also be critical in TGS exchanges.

:)

Cheers,

Nico

---

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

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

    Nicolas> Whatever is decided, I'm arguing for consistency. So use
    Nicolas> AD-KDC-RELEVANT, instead of AD-KDC-MANDATORY, and if AD
    Nicolas> is critical in AP exchanges, it should also be critical
    Nicolas> in TGS exchanges.

I presented a case yesterday (in response to Ken) why I thought that
the situation was different for the TGS than for all other services.
This is why I believe that the TGS should by default ignore unknown
AD.

---

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

>>>>> "Matt" == Matt Crawford <[email-masked]> writes:

    >> TGS.

    Matt> By ignore do you mean "... and preserve"?

Yes.

---

From: "Nicolas Williams" <[email-masked]>
Date: Wed, 24 Apr 2002 13:18:08 -0400

> This is why I believe that the TGS should by default ignore unknown

Yes, but, your point is that ADs are usually meant for APs, not for
TGSs. This is true today. But it might not be true tomorrow.

I think your point about current implementation's handling of criticality
argues for having AD-RELEVANT containers (and AD-KDC-RELEVANT and
AD-AP-RELEVANT).

Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

---

From: [email-masked]
Date: Wed, 24 Apr 2002 12:17:55 +0200 (MET DST)

> it will refuse the ticket.

What do you actually mean by "if the service doesn't understand"?

When I write a service that uses GSS-API to use Kerberos I don't
get to see (and I don't care for) anything besides the authenticated
name of the initiator/client.

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

Even large pure-Microsoft shops seem to diversify on the exact
patch-levels of individual machines rather quickly...

-Martin

---

From: Matt Crawford <[email-masked]>
Date: Wed, 24 Apr 2002 08:48:23 -0500

> point seems to be for application authorization not for TGS.

By ignore do you mean "... and preserve"?

---

From: Sam Hartman <[email-masked]>
Date: Thu, 25 Apr 2002 15:32:14 -0400

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

    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.