Subject: Kerberos name constraints I-D

From: "Paul Rabinovich" <[email-masked]>
Date: Mon, 17 Sep 2007 12:05:47 -0400

Hello,

	Attached, please, find the 0th draft of the I-D “Constraining
Kerberos Names in X.509 Certificates”. The I-D was not included in the
Kerberos WG Charter. The chairs recommended that I do an individual
submission. Since it concerns both Kerberos and PKI, I'd like to solicit
feedback from the PKIX WG.
	There are a couple of issues I’d like to draw your attention to:

1) “Other” name constraints applicable to Kerberos names: (a) Is it even a
good idea to apply one type of name constraint to a name of a different type
(RFC 3280 does not do this – with one exception for backward compatibility);
(b) issuing CAs may label names as NT-PRINCIPAL or some such to circumvent
these name constraints; (c) RFC 4120 is ambiguous about certain Kerberos
names (e.g., NT-SMTP-NAME: Name in the form of an SMTP e-mail name (e.g.,
[email-masked]): is it always an RFC 822 name or it only looks like one?
The same is true for NT-SRV-XHST and X.500 names, etc.)
2) I’m concerned about ambiguity of name encodings. E.g., in an NT-SRV-XHST
what is the encoding of the name-string field? Is it a left-to-right DN or
right-to-left? I’d like to make sure the encoding issue is unambiguously
resolved for all name types.
3) In RFC 4120: is it true that domain-style realm names never start with
“.”; it should be true but it’s not stated there.
4) How are X500-style realm names encoded?
5) Should we do any pattern matching for “other”-style real names? My draft
talks only about exact realm name match for them.

I appreciate all feedback.

Best regards,
PR

Paul Rabinovich | Software Architect | EXOSTAR LLC
13530 Dulles Technology Dr., Suite 200, Herndon, VA 20171
PH +1.703.793.7808 | FAX +1.703.793.7741

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 18 Sep 2007 23:56:36 +0100

Hi Paul,

Thank you for posting the draft.

I have looked through it and I have several minor comments on the introduction I may recap in a later e-mail. I'll provide some more general thoughts here:

I general I think the technical approach is reasonable. However I'm a bit confused about whether section 4.2 is contradicting section 5 or not.
Section 4.2. impose exact match full name match in all cases when the PrincipalName is a non-empty sequence, at the same time section 5 seems to suggest some other constraint rules if certain name types are being used. This feels contradicting to me.

The document is not clear on case matching, i.e. in what aspects matching is case sensitive or not.

The document does not disclose the fact that KerberosString is an IA5String (ASCII) and as such there are no direct I18N issues.
However. If one of the attributes expressed in an X.500 style name would originally be UTF8 with international characters. How would that be handled in this situation. Is this described anywhere? and would it affect name constraining?

The document clearly has leading sections being introduction, followed by a normative specification. It would be better IMO if the leading sections were bundled into one introduction section, possibly with subsections.

5.1 talks about service names. FYI there is a new RFC defining a Service Name SubjAltName with name constraining rules (RFC 4985). Would that be a relevant reference?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Paul Rabinovich
> Sent: den 17 september 2007 09:06
> To: [email-masked]
> Subject: Kerberos name constraints I-D
>
>
>       Hello,
>
>       Attached, please, find the 0th draft of the I-D
> "Constraining Kerberos Names in X.509 Certificates". The I-D was not
> included in the Kerberos WG Charter. The chairs recommended that I do
> an individual submission. Since it concerns both Kerberos and PKI, I'd
> like to solicit feedback from the PKIX WG.
>       There are a couple of issues I'd like to draw your attention
> to:
>
> 1) "Other" name constraints applicable to Kerberos names: (a) Is it
> even a good idea to apply one type of name constraint to a name of a
> different type (RFC 3280 does not do this - with one exception for
> backward compatibility);
> (b) issuing CAs may label names as NT-PRINCIPAL or some such to
> circumvent these name constraints; (c) RFC 4120 is ambiguous about
> certain Kerberos names (e.g., NT-SMTP-NAME: Name in the form of an SMTP
> e-mail name (e.g.,
> 2) I'm concerned about ambiguity of name encodings. E.g., in an NT-SRV-
> XHST what is the encoding of the name-string field? Is it a left-to-
> right DN or right-to-left? I'd like to make sure the encoding issue is
> unambiguously resolved for all name types.
> 3) In RFC 4120: is it true that domain-style realm names never start
> with "."; it should be true but it's not stated there.
> 5) Should we do any pattern matching for "other"-style real names? My
> draft talks only about exact realm name match for them.
>
> Paul Rabinovich | Software Architect | EXOSTAR LLC 13530 Dulles
> Technology Dr., Suite 200, Herndon, VA 20171 PH +1.703.793.7808 | FAX
> +1.703.793.7741

---

From: "Paul Rabinovich" <[email-masked]>
Date: Thu, 20 Sep 2007 09:17:09 -0400

Stefan,

	Thank you for your feedback. My comments are inline below.

	Best regards,
	PR

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2007 6:57 PM
To: Paul Rabinovich; [email-masked]
Subject: RE: Kerberos name constraints I-D

Hi Paul,

I have looked through it and I have several minor comments on the
introduction I may recap in a later e-mail. I'll provide some more
general thoughts here:

I general I think the technical approach is reasonable. However I'm a
bit confused about whether section 4.2 is contradicting section 5 or
not.
Section 4.2. impose exact match full name match in all cases when the
PrincipalName is a non-empty sequence, at the same time section 5 seems
to suggest some other constraint rules if certain name types are being
used. This feels contradicting to me.

<pr> Section 4 describes the newly-defined Kerberos name constraints.
Section 5 describes how *other* name constraints currently defined by
RFC 3280 should/may be applied to Kerberos names *in addition* to the
Section 4 constraints. I'm actually inclined against this idea (using
other constraints) but wanted to get feedback from others. </pr>

The document is not clear on case matching, i.e. in what aspects
matching is case sensitive or not.

<pr> I think Section 4 constraints should use RFC 4120's definitions of
name equivalence (which is case-sensitive). Section 5, assuming it's
left in the proposal/standard, should use the rules of the corresponding
name type (e.g., a dNSName constraint applied to a Kerberos name
containing a DNS name in the principal name component will use dNSName
matching rules). </pr>

The document does not disclose the fact that KerberosString is an
IA5String (ASCII) and as such there are no direct I18N issues.
However. If one of the attributes expressed in an X.500 style name would
originally be UTF8 with international characters. How would that be
handled in this situation. Is this described anywhere? and would it
affect name constraining?

<pr> I need to think this one over, and will get to you on this shortly.
</pr>

The document clearly has leading sections being introduction, followed
by a normative specification. It would be better IMO if the leading
sections were bundled into one introduction section, possibly with
subsections.

5.1 talks about service names. FYI there is a new RFC defining a Service
Name SubjAltName with name constraining rules (RFC 4985). Would that be
a relevant reference?

<pr> I've read the RFC. It is related in the sense that it discusses
another type of names/name constraints. As I understand it, services in
RFC 4985 are DNS SRV services, and their name space is different from
Kerberos service names (although I would imagine in theory they may
represent the same service). I won't mind including it as an informative
reference. </pr>

Stefan Santesson
Senior Program Manager

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 20 Sep 2007 18:52:53 +0100

In line;

Stefan Santesson
Senior Program Manager

> From: Paul Rabinovich [mailto:[email-masked]]
> Sent: den 20 september 2007 06:17
> To: Stefan Santesson; [email-masked]

I'm still confused. How can you apply any constraints in addition to those described in section 4. Isn't it either or. You have to either apply the section 4 general rule OR the section 5 applicable rule, unless they are the same. When should you follow section 4 and when should you follow section 5?

> name equivalence (which is case-sensitive).

Fine, I just think it should be written out.

> Section 5, assuming it's

But then again I need to know when I apply section 4 rules or section 5 rules. As it is now I don't

> represent the same service). I won't mind including it as an

Yes RFC 4985 only address DNS RR type service names. Only include it if you think it makes any sense. I seems from your description that it does not.

---

From: "Paul Rabinovich" <[email-masked]>
Date: Thu, 20 Sep 2007 14:46:12 -0400

Stefan,

	To explain Section 4/5 relationship: let's say the EE cert
asserts the Kerb name ("EXAMPLE.COM", (NT-SRV-HST, ("telnet",
"foo.example.com"))). Somewhere up the chain there could be two
constraints:

Section 4: ("Kerb. name constraint", ("EXAMPLE.COM", (NT-UNKNOWN, ())))
[exact realm name match; satisfied]
Section 5: ("dNSName constraint", "example.com") [DNS domain match
applied to "foo.example.com"; satisfied]

	So the asserted name is valid if both name constraints are
satisfied.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, September 20, 2007 1:53 PM
To: Paul Rabinovich; [email-masked]
Subject: RE: Kerberos name constraints I-D

In line;

Stefan Santesson
Senior Program Manager

> other constraints) but wanted to get feedback from others. </pr>

I'm still confused. How can you apply any constraints in addition to
those described in section 4. Isn't it either or. You have to either
apply the section 4 general rule OR the section 5 applicable rule,
unless they are the same. When should you follow section 4 and when
should you follow section 5?

> containing a DNS name in the principal name component will use dNSName

But then again I need to know when I apply section 4 rules or section 5
rules. As it is now I don't

> represent the same service). I won't mind including it as an

Yes RFC 4985 only address DNS RR type service names. Only include it if
you think it makes any sense. I seems from your description that it does
not.

> > [email-masked]): is it always an RFC 822 name or it only looks
like
> > one?

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 20 Sep 2007 20:02:19 +0100

Not as I read your document.

Yes you are safe when it is only a matter of the realm name.
However.

Section 4 states:

   A relying party recognizes an exact full name match constraint when
   the value of the name-string field of the type PrincipalName is set
   to a non-empty SEQUENCE.

Section 5 states:

5.2.  rfc822Name Name Constraint

   If present, an rfc822Name name constraint SHOULD be applied to all
   asserted Kerberos names with the name-type field of the type
   PrincipalName set to NT-SMTP-NAME.  To satisfy the constraint the
   asserted Kerberos name's name-string field MUST be a SEQUENCE with a
   single element that matches the rfc822Name in the name constraint
   according to the rules of RFC 3280 [2].

But. IF "asserted Kerberos name's name-string field MUST be a SEQUENCE with a single element that matches the rfc822Name" Then the name-string value is not an empty sequence, hence exact full name match applies according to section 4.

It doesn't seem to add up

Stefan Santesson
Senior Program Manager

> Sent: den 20 september 2007 11:46

---

From: "Paul Rabinovich" <[email-masked]>
Date: Mon, 24 Sep 2007 15:17:50 -0400

Stefan,

	Now I see where misunderstanding may have come from. The quoted
text from Section 4 tries to convey that a relying party will realize
that the name constraint is an "exact full name constraint" if it sees
(*in the name constraint*) a non-empty SEQUENCE (i.e., if the SEQUENCE
*in the name constraint* is empty, it's a realm-name match). I will
correct the wording in the next version.

	Cheers,
	PR

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, September 20, 2007 3:02 PM
To: Paul Rabinovich; [email-masked]
Subject: RE: Kerberos name constraints I-D

Section 4 states:

Section 5 states:

But. IF "asserted Kerberos name's name-string field MUST be a SEQUENCE
with a single element that matches the rfc822Name" Then the name-string
value is not an empty sequence, hence exact full name match applies
according to section 4.

Stefan Santesson
Senior Program Manager

> > > right DN or right-to-left? I'd like to make sure the encoding
issue
> > is

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 24 Sep 2007 21:01:54 +0100

This is also how I read it. i.e. if the name constraint contain a non-empty sequence.
I also read section 5, other rules if the name constraint contains a non-empty sequence.
It still feel contradicting.

BTW, I think it is suboptimal for a standard to assume what a relying party "recognize". Instead it would be better to exactly define what things means and what implementers MUST or SHOULD do.

I will await a new version and read it again.

Stefan Santesson
Senior Program Manager

> Sent: den 24 september 2007 12:18
> > > <pr> I think Section 4 constraints should use RFC 4120's
> definitions
> > of
> > > Name SubjAltName with name constraining rules (RFC 4985). Would
> that
> > be
> > > a relevant reference?
> > >
> > > another type of names/name constraints. As I understand it,
> services
> > in
> > > > included in the Kerberos WG Charter. The chairs recommended that
> I
> > do
> > > > an individual submission. Since it concerns both Kerberos and
> PKI,
> > > I'd
> > > > even a good idea to apply one type of name constraint to a name
> of
> > a
> > > > certain Kerberos names (e.g., NT-SMTP-NAME: Name in the form of
> an
> > > SMTP
> > > > e-mail name (e.g.,
> > > > 5) Should we do any pattern matching for "other"-style real
> names?
> > My