Subject: draft-ietf-krb-wg-anon-02.txt

From: Ken Raeburn <[email-masked]>
Date: Thu, 15 Feb 2007 20:10:39 -0500

I've looked over this draft, and for the most part it looks good,  
just a few specific areas I had comments on.  I only looked briefly  
at draft-ietf-krb-wg-naming-01.txt that this draft references, though.

Page 4: Is there ever a time when it would be useful to know the  
(partial) transit path for credentials that started off with realm  
RESERVED:ANONYMOUS?  The existing transit path encoding scheme  
assumes that both client and server realms are domain- or x500-style,  
not reserved.  So there isn't a way to encode such a thing.  (Perhaps  
the naming draft should define a way to store reserved as well as  
domain and x500 realm names.)

Page 5, paragraph 4, remove "And" at the beginning of the second  
sentence.

Page 6, I'm not sure that AD-IF-RELEVANT is safe to strip out.  It's  
safe for an application server that doesn't understand it to ignore  
it, but just because the KDC doesn't recognize it doesn't mean an  
application server won't parse it as a restriction.  It may be that  
the anonymous id is prohibited from doing anything interesting, but  
that assumes you're doing both name-based and authz-data-based  
restrictions in the service; I wouldn't simply assume that.  I think  
maybe it should be "fail if unknown".  I could be wrong, but you'll  
have to convince me....

The AD-AND-OR case may have similar issues, but I have to think about  
that some more.  You might be able to remove some elements without  
simply failing.  If you discard too many components of an AD-AND-OR,  
such that the remaining ones are fewer in number than the "condition- 
count" field, you can probably just consider the whole thing to be  
impossible to meet; depending on context, this would mean removing it  
or failing the request.  (I think we don't actually prohibit an AD- 
AND-OR from having a condition-count larger than the number of  
elements, so this would just be a logical and obvious optimization we  
can recommend, not a requirement.)

The transit path options go back to the encoding question.  The  
transit path is only useful if it indicates in some way all the  
parties involved in the authentication path.  If the application  
server (or its local KDC) doesn't like anything it finds there, it  
can reject the request, but if you quietly hide that information,  
you're removing its ability to make that judgement.  "Arbitrary  
unspecified realms" as indicated by NO-TRANSITED-INFO is one way of  
providing information; the server can decide whether or not it wants  
to allow that.  But if a KDC sees NO-TRANSITED-INFO coming in, and by  
policy is going to record transit info in the generated ticket, it  
should have a way of recording that some information about earlier  
hops has been omitted.  Otherwise, you may be incorrectly telling the  
next KDC or the application service, "this anonymous ticket came  
through realms A and B and no others".

Page 7: "If the client is anonymous and the KDC does not have a key  
to encrypt the reply...."  When would this occur?

RFC 4120 notes that some older KDC implementations may reject  
requests with the anonymous flag set.

The server should be allowed to have a policy that rejects NO- 
TRANSITED-INFO.

"The KDC is given the task of rejecting...."  First, I'd phrase this  
in active form: "The KDC MUST/SHOULD reject...."  Second, why?  If  
the service implementation conforms with the naming draft, but  
doesn't understand the anonymous ticket, it'll reject the  
authentication with "reserved name unknown", without the KDC being  
required to interfere.  If the service implementation doesn't conform  
to the naming draft, perhaps the KDC should reject requests for  
tickets for that service from ANY reserved name -- a constraint which  
would be better placed in the naming draft than in the anon draft.

"...the name that pops up..."?  "Popping up" could mean various  
things; a window displayed on the screen, perhaps.  The name is  
returned by the function.

Ken

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 27 Feb 2007 04:12:13 -0800

> domain and x500 realm names.)

You are right, the complexity is not justified.

I would also propose the following paragraph in the naming draft:

    <t>Typically reserved realms are defined to carry special meanings,
and
they are not used to refer to intermediate realms in the client's
authentication path. 
Consequently, unless otherwise specified, a reserved Kerberos realm name
MUST NOT be present
in the transited field <xref target="RFC4120"/> of a ticket.</t>

and in the anonymity ID:

  An anonymous Kerberos realm name MUST NOT be present in the transited
field <xref target="RFC4120"/> of a ticket.

> Page 5, paragraph 4, remove "And" at the beginning of the second  
Done

> to encrypt the reply...."  When would this occur?

this can happen when, for example, the KDC does not support PKINIT<xref
target="RFC4556"/>.

> requests with the anonymous flag set.

This should be allowed. A local policy issue.

>The server should be allowed to have a policy that rejects NO- 

Ditto.

> would be better placed in the naming draft than in the anon draft.

Excellent point. I do not think this paragraph is necessary.

>returned by the function.
To clarify this, I would propose to change the text to:

<t> GSS-API does not know or define "anonymous credentials", so the
(printable) name of the anonymous principal will rarely be used by or
relevant for the initiator/client. 
The printable name is relevant for the acceptor/server when performing
an authorization decision based 
on the initiator name that is returned from the acceptor side upon the
successful security context establishment.</t>

w.r.t. the unknown authorization data, it becomes clear to me we just
need to remove them. Here is the updated text:

   During the TGS request, when propagating authorization data, care
   MUST be taken by the TGS to ensure that the client confidentiality is
   not violated.  If a anonymous ticket is returned, any authorization
   element that may reveal the client's identity MUST be removed.  The
   authentication attempt MUST be rejected if there is an authorization
   element that is intended to restrict the use of the ticket thus
   cannot be removed or the local policy prevents the removal of an
   authorization element, and this rule MUST be applied to all critical
   and optional authorization data.  An optional authorization element
   unknown by the TGS MUST be removed if it does not potentially convey
   any rights or limit the rights otherwise conveyed in the ticket.  If
there is a
   critical unknown authorization element, unless this element is
   encapsulated in a known authorization data element amending the
   criticality of the elements it contains, authentication MUST fail
   according to [RFC4120].

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Thursday, February 15, 2007 5:11 PM
To: [email-masked]
Subject: draft-ietf-krb-wg-anon-02.txt

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 27 Feb 2007 12:38:16 -0500

> field <xref target="RFC4120"/> of a ticket.

Actually, it wouldn't be in the transited field, would it?  It would  
be the client principal name, and thus used as the starting point in  
the transited field encoding scheme.  The problem is, the one  
existing scheme assumes the starting and ending points (client and  
server realms) are domain or X.500 names.  So unless you want to  
assert that the transited realm list must *not* be built up for  
anonymous client principals, and must instead always be empty, we  
need an encoding scheme (or a change to the current one) that can  
handle a reserved realm as the client realm.

(The change is *probably* simple: Just assert that if the client name  
isn't domain or X.500 style, then the abbreviation forms that build  
on the preceding name cannot be used at the start of the transited  
encoding.  But that's just off the top of my head.)

My inclination would be to preserve the information if possible,  
unless we can convince ourselves that there is never a use for it.   
Hence my question above.  I didn't mean to suggest that I believe  
there is no use for a partial path; I'm just not sure.

> this can happen when, for example, the KDC does not support  

Section 4 describes two approaches to the AS exchange, one using  
PKINIT and one using the client's key.  So, then, is this referring  
to a case where the latter approach is attempted but the client has  
no key in the KDC's database?

Ken

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 27 Feb 2007 12:06:32 -0800

Ken Raeburn wrote
> handle a reserved realm as the client realm.

I'd prefer that the TGS MUST add the previous realm in all cases. Unless
one of the intermediate realm fabricates the transited realms, we should
have the full set excluding the end points.

> encoding.  But that's just off the top of my head.)

This should not be an issue. The transited realm is built based on the
server realm in the ticket, not the client realm. The server realm
cannot be anonymous. But I think it is good to spell out this
explicitly. For that, I would propose the following text in the naming
draft:

   According to Section 3.3.3.2 of [RFC4120], A TGS MUST add the name of
   the previous realm into the transited field of the returned ticket.
   Typically reserved realms are defined to carry special meanings, and
   they are not used to refer to intermediate realms in the client's
   authentication path.  Consequently, unless otherwise specified, a
   reserved Kerberos realm name MUST NOT be present in the transited
   field [RFC4120] of a ticket.  If the server realm of a cross realm
   referral Ticket Granting Ticket (TGT) can be a reserved one, then the
   specification of the reserved realm type MUST define the encoding of
   the reserved realm in the transited field.  This typically means that
   the abbreviation forms that build on the preceding name cannot be
   used at the start of the transited encoding.  In an AS exchange, the
   name of the realm that issues the ticket is not included in the
   transited field.

>there is no use for a partial path; I'm just not sure.

I agree. 

>> larry zhu wrote:

> no key in the KDC's database?

This describes the case where the client is anonymous, thus there is no
shared key associated associated
With the anonymous client.
 
<t> If the client is anonymous and the KDC does not have a key to
encrypt the reply (this can happen when, 
for example, the KDC does not support PKINIT <xref target="RFC4556"/>), 
the KDC MUST return an error message with the code KDC_ERR_NULL_KEY
<xref target="RFC4120"/> and 
there is no accompanying e-data defined in this document.</t>

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Tuesday, February 27, 2007 9:38 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: draft-ietf-krb-wg-anon-02.txt

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 27 Feb 2007 16:09:29 -0500

> have the full set excluding the end points.

Yes.

> explicitly. For that, I would propose the following text in the naming

The transited realm list is all the intermediate realms, and the  
"compression" scheme takes into account that the client and server  
realms are also part of the path, and so could be used in the  
encoding.  For example, a client realm of "EXAMPLE.COM" and a  
transited encoding that starts off with "FOO." means that  
"FOO.EXAMPLE.COM" is one of the transited realms.  If the client  
realm is "RESERVED:WHATEVER", then what does "FOO." at the start of  
the transited path mean?

>    referral Ticket Granting Ticket (TGT) can be a reserved one,  

Drop "referral"; it could simply have been requested by the client.

>    the reserved realm in the transited field.

Do we really want the spec for each reserved realm type that could go  
in the transited path to have to specify, separately, how it gets  
encoded and how the compression works?  I think this is a benefit  
only if there is never such a reserved realm type.  If we define one,  
you've only put off doing the work; if we define a second, then we're  
doing more work than I think we should need to.

>   This typically means that
>    used at the start of the transited encoding.

Also, the null-subfield form (e.g., encoding ending with ",") could  
not be used next to a reserved realm, including potentially at the  
beginning and end where the client and server realm names,  
respectively, are filled in.

>   In an AS exchange, the

Normally in an AS exchange the client and server realms would be the  
same as the realm that issues the ticket, so no transit path is  
needed....

> for example, the KDC does not support PKINIT <xref target="RFC4556"/ 
> >),

Okay, that makes sense.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 27 Feb 2007 23:51:35 -0800

> realm is "RESERVED:WHATEVER", then what does "FOO." at the start of  

Excellent Points.

Done

> same as the realm that issues the ticket, so no transit path is  

This is removed now.

> respectively, are filled in.
Good points again.

Thanks,

--Larry
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Tuesday, February 27, 2007 1:09 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: draft-ietf-krb-wg-anon-02.txt

Yes.

Okay, that makes sense.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 27 Feb 2007 23:55:18 -0800

in the transited path to have to specify, separately, how it gets
encoded and how > the compression works?  I think this is a benefit only
if there is never such a reserved realm type.  If we define one, you've
only put off doing the > 
> work; if we define a second, then we're doing more work than I think
we should need to.

I would prefer putting off the work for now till we have a good scenario
to work on. We can update this spec when the need of encoding arises,
and the encoding does not have to be specific to the reserved name types
at that point. I am not convinced that significantly more work is needed
in that case. Thanks.

--larry

-----Original Message-----

Yes.

Okay, that makes sense.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 28 Feb 2007 11:23:34 -0500

On Tuesday, February 27, 2007 04:09:29 PM -0500 Ken Raeburn 
<[email-masked]> wrote:

> realms are also part of the path, and so could be used in the  encoding.
> For example, a client realm of "EXAMPLE.COM" and a  transited encoding
> that starts off with "FOO." means that  "FOO.EXAMPLE.COM" is one of the
> transited realms.  If the client  realm is "RESERVED:WHATEVER", then what
> does "FOO." at the start of  the transited path mean?

Aside from the heirarchical meaning of a null subfield, 
DOMAIN-X500-COMPRESS appears to treat realm names as strings.  So, "FOO." 
at the start of the transited path would mean "FOO.RESERVED:WHATEVER", 
which is a "reserved" (illegal) realm name, since it contains both a colon 
and a dot before the colon.

Hm.  It would probably be good for -extensions to define how to represent a 
domain-style realm name where the domain name in question contains a color 
or slash.

BTW, on reflection, I think -naming needs to choose terminology other than 
"reserved".  A "reserved" realm name is one that is not domain-style, 
X.500, or "other"; overloading the terminology is going to cause confusion.

> Do we really want the spec for each reserved realm type that could go  in
> the transited path to have to specify, separately, how it gets  encoded
> and how the compression works?

I don't think so.  RFC4120 defines how compression works, for realm names 
of all types, and I don't think it is necessary to change this.

> Also, the null-subfield form (e.g., encoding ending with ",") could  not
> be used next to a reserved realm, including potentially at the  beginning
> and end where the client and server realm names,  respectively, are
> filled in.

That's right; the null-subfield optimization can be used only where the 
realms on both sides are domain-style or X.500.  I don't see a problem with 
this.  I wonder if there are even any implementations which produce this 
encoding.

-- Jeff

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 28 Feb 2007 15:23:56 -0500

On Feb 28, 2007, at 11:23, Jeffrey Hutzelman wrote:
> Aside from the heirarchical meaning of a null subfield, DOMAIN-X500- 
> COMPRESS appears to treat realm names as strings.  So, "FOO." at  
> the start of the transited path would mean "FOO.RESERVED:WHATEVER",  
> which is a "reserved" (illegal) realm name, since it contains both  
> a colon and a dot before the colon.

Yes, you're right.  It looks like it's described for any strings,  
it's just optimized for domain and X.500.  Since you wouldn't want to  
be describing invalid realm names, there are just some places where  
you couldn't apply the optimizations (and some encodings that  
wouldn't represent lists of valid realm names).  No need for a new  
encoding description.

> BTW, on reflection, I think -naming needs to choose terminology  
> other than "reserved".  A "reserved" realm name is one that is not  
> domain-style, X.500, or "other"; overloading the terminology is  
> going to cause confusion.

Maybe "special" or something?

Ken