Subject: [Ietf-krb-wg] Kerberos name constraints I-D

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

Hello,

	Attached, please, find the 0th draft of the I-D “Constraining
Kerberos Names in X.509 Certificates”. 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 your 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

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Sep 2007 12:01:24 -0500

> The same is true for NT-SRV-XHST and X.500 names, etc.)

I assume you mean Kerberos V name types.

(a) No, probably not, because krb5 name types are hints (they do not
    partition the name space, they are not part of krb5 names).

(b) If the answer to (a) is "no" then this is not an issue.  BUT, IMO
    x.509 name constraints on krb5 names should apply only to realm
    names.  That is, a CA for a realm should be able to issue certs with
    any principal name in that realm, and, possibly, sub-realms, as per
    the associated constraints.

(c) What's the difference between "is ... an RFC 822 name" and "only
    looks like one"?  That e-mail sent to that address will not bounce
    in the first case but will in the second?  That's not enough of a
    difference IMO.  But in any case, (c) is irrelevant if x.509 name
    constraints on krb5 names apply only to krb5 realm names.

> resolved for all name types.

DN?  I think there's no ambiguity about NT-SRV-XHST:

   NT-SRV-XHST       4    Service with host as remaining components

   ...

                                                    ...  If the separate
   components of the host name appear as successive components following
   the name of the service, then the name type SRV-XHST SHOULD be used.

I think "successive" here quite clearly implies left-to-right domainname
label order.

> “.”; it should be true but it’s not stated there.

Why?

> 4) How are X500-style realm names encoded?

As a KerberosString formatted as per-section 6.1 of RFC4120.

> talks only about exact realm name match for them.

Hmmm, I think we might want to limit these name constraints apply only
to domain-type realm names and leave name constraints on X.500 and other
realm types to some other spec.

Nico
--

---

From: "Paul Rabinovich" <[email-masked]>
Date: Mon, 17 Sep 2007 13:52:42 -0400

Nico,

	My answers/comments are inline.

	-PR

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Monday, September 17, 2007 1:01 PM
To: Paul Rabinovich
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] Kerberos name constraints I-D

On Mon, Sep 17, 2007 at 12:07:26PM -0400, Paul Rabinovich wrote:
> 1) "Other" name constraints applicable to Kerberos names: (a) Is it even a
> (RFC 3280 does not do this - with one exception for backward
compatibility);

	[PR] Correct, something may look like an e-mail address but not be
one. I'm curious about RFC 4120's spirit: it states that the name has format
of an e-mail address but does not state explicitly it is an e-mail address.
Does anyone know the current practices for using these names?

> 2) I'm concerned about ambiguity of name encodings. E.g., in an
NT-SRV-XHST
> right-to-left? I'd like to make sure the encoding issue is unambiguously

   ...

                                                    ...  If the separate

	[PR] There are two issues with NT-SRV-XHST: a) From 4120 it looks
like it's just a multi-part host name, not always a DN (distinguished name);
b) If it's a DN, say, CN=foo.bar.com, CN=Hosts, O=U.S. Government, C=US is
it encoded as ((CN= foo.bar.com), (CN=Hosts), (O=U.S. Government), (C=US))
or ((CN= foo.bar.com), (CN=Hosts), (O= U.S. Government), (C=US)). Different
systems convert DNs to strings differently.

> "."; it should be true but it's not stated there.

Why?

	[PR] I would expect domain-style names not to start with dot. Is
there a precedent or a standard when the dot in front is needed? I made the
assumption that the answer is no, and proposed to use the dot as a suffix
match indicator. Of course, any other character allowed in KerberosString
but not used for domain-style realm names will do.

	[PR] Again, I didn't see an explicit RDN order statement. I assumed
it's the same as BER-encoded DN but would like to find a confirmation.

> 5) Should we do any pattern matching for "other"-style real names? My
draft

	[PR] It seems to me pattern matching for "other" realm names may be
left out but for X500 realm names there is enough info in 4120 (with small
caveats) to use them. Exact match constraints for *all* realm name types
seem within reach.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Sep 2007 14:47:57 -0500

> 	My answers/comments are inline.

Does Outlook still not have a proper e-mail quoting feature?

Nico> (c) What's the difference between "is ... an RFC 822 name" and "only
Nico>     looks like one"?  That e-mail sent to that address will not bounce
Nico>     in the first case but will in the second?  That's not enough of a
Nico>     difference IMO.  But in any case, (c) is irrelevant if x.509 name
Nico>     constraints on krb5 names apply only to krb5 realm names.
> Does anyone know the current practices for using these names?

I think RFC4120 means what it says: "[n]ame in _form_ of SMTP email name
(e.g., [email-masked])," emphasis added on the word "form."

But RFC4120 should really have given a normative reference for "form of
SMTP email name"...

> PR> 2) I'm concerned about ambiguity of name encodings. E.g., in an
> NT-SRV-XHST
> PR> what is the encoding of the name-string field? Is it a left-to-right DN or
> PR> right-to-left? I'd like to make sure the encoding issue is unambiguously
> PR> resolved for all name types.
> 
Nico> DN?  I think there's no ambiguity about NT-SRV-XHST:
Nico> 
> systems convert DNs to strings differently.

But NT-SRV-XHST has nothing to do with distinguished names.  RFC4120
does say this in the context of NT-SRV-XHST names:

   This type might be used to identify servers on hosts with X.500
   names, where the slash (/) might otherwise be ambiguous.

which, IMO, is quite odd and might be what led you to think that the
components of NT-SRV-XHST names are a DN's RDNs, but I don't read it
that way: I simply don't know what to make of that note.

> PR> 3) In RFC 4120: is it true that domain-style realm names never start with
> PR> "."; it should be true but it's not stated there.
> 
Nico> Why?
> but not used for domain-style realm names will do.

Can you point out what specific text in RFC4120 you're referring to
here?  Section 6.1 does impose some requirements on domain-style realm
names that may be adds with DNS (except that I'm pretty sure that while
DNS lables can generally contain any ASCII char other than '.' and NUL,
domainnames may not contain ':').

> PR> 4) How are X500-style realm names encoded?
> 
Nico> As a KerberosString formatted as per-section 6.1 of RFC4120.
> it's the same as BER-encoded DN but would like to find a confirmation.

It's a human-readable string representation of DNs.  Section 6.1 says:

   X.500 names contain an equals sign (=) and cannot contain a colon (:)
   before the equals sign.  The realm names for X.500 names will be
   string representations of the names with components separated by
   slashes.  Leading and trailing slashes will not be included.  Note
   that the slash separator is consistent with Kerberos implementations
   based on RFC 1510, but it is different from the separator recommended
   in RFC 2253.

See RFC2253 for more details.

> > talks only about exact realm name match for them.
Nico> Hmmm, I think we might want to limit these name constraints apply only
Nico> to domain-type realm names and leave name constraints on X.500 and other
Nico> realm types to some other spec.
> caveats) to use them. Exact match constraints for *all* realm name types

They do seem within reach, but I wouldn't object to dealing with each
style via a separate RFC if it made things easier (others might not
agree).

Nico