RE: Kerberos name constraints I-D

"Paul Rabinovich" <Paul.Rabinovich@exostar.com> Thu, 20 September 2007 20:03 UTC

Return-path: <owner-ietf-pkix@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYSEy-0000sU-VR for pkix-archive@lists.ietf.org; Thu, 20 Sep 2007 16:03:14 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYSEt-0000g4-Gy for pkix-archive@lists.ietf.org; Thu, 20 Sep 2007 16:03:08 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8KIkF60063173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2007 11:46:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8KIkFWC063172; Thu, 20 Sep 2007 11:46:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from Netmail1.exostar.com (netmail1.exostar.com [208.47.83.14]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8KIkDwM063152 for <ietf-pkix@vpnc.org>; Thu, 20 Sep 2007 11:46:13 -0700 (MST) (envelope-from Paul.Rabinovich@exostar.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Kerberos name constraints I-D
Date: Thu, 20 Sep 2007 14:46:12 -0400
Message-ID: <0E2D64FCAEB5C5458A494DC28270548E06DA1064@Netmail1.exostar.com>
In-reply-to: <A15AC0FBACD3464E95961F7C0BCD1FF006A2704CA9@EA-EXMSG-C307.europe.corp.microsoft.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Kerberos name constraints I-D
Thread-Index: Acf0m6FwQRhkNNIdQwKqenHbym7AfAEo9VDAAAA58KAAQSFGAAA4S0kAACIAlTAAASyqYA==
From: Paul Rabinovich <Paul.Rabinovich@exostar.com>
To: Stefan Santesson <stefans@microsoft.com>, ietf-pkix@vpnc.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l8KIkEwM063160
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2


	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:stefans@microsoft.com] 
Sent: Thursday, September 20, 2007 1:53 PM
To: Paul Rabinovich; ietf-pkix@vpnc.org
Subject: RE: Kerberos name constraints I-D

In line;

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Paul Rabinovich [mailto:Paul.Rabinovich@exostar.com]
> Sent: den 20 september 2007 06:17
> To: Stefan Santesson; ietf-pkix@vpnc.org
> Subject: RE: Kerberos name constraints I-D
>
>
>         Stefan,
>
>         Thank you for your feedback. My comments are inline below.
>
>         Best regards,
>         PR
>
>
> -----Original Message-----
> From: Stefan Santesson [mailto:stefans@microsoft.com]
> Sent: Tuesday, September 18, 2007 6:57 PM
> To: Paul Rabinovich; ietf-pkix@vpnc.org
> Subject: RE: Kerberos name constraints I-D
>
> 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.
>
> <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>
>

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?


> 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).

Fine, I just think it should be written out.

> 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>
>

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


> 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>
>

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.



> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
> > -----Original Message-----
> > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-
> > pkix@mail.imc.org] On Behalf Of Paul Rabinovich
> > Sent: den 17 september 2007 09:06
> > To: ietf-pkix@vpnc.org
> > 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.,
> > user@example.com): 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