Subject: Re: WG Last Call - krb-wg charter update

From: Martin Rex <[email-masked]>
Date: Wed, 13 Jun 2007 01:17:08 +0200 (MEST)

Paul Rabinovich wrote:
> 
> I'm new to this list so apologize if I don't follow the protocol.
> 
> The A&D industry where I work has a lot of interest in standardizing
> name constraints for Kerberos principal names in X.509 certificates.
> This is because the companies want to use one another's credentials to
> get access to systems across enterprise boundaries (and to do the same
> with their suppliers and customers). The primary vehicle of trust in the
> A&D industry is CertiPath, a PKI bridge cross-certified with the Federal
> Bridge, on the one hand, and with A&D companies, on the other. Currently
> CertiPath puts X.500, RFC 822 and DNS name constraints in their
> cross-certificates.
> 
> The primary form of user name in most cases is the User Principal Name
> from Active Directory. Microsoft Certificate Server is already capable
> of inserting UPNs as otherNames in the subjectAltName X.509 extension
> and name constraints for UPNs in the nameConstraints extension.
> Microsoft's relying parties (CAPI-based) can enforce these constraints.
> 
> There are two (or, maybe, one) problems with this approach: 1) UPNs are
> encoded in a proprietary way although there is a standard encoding from
> RFC 4556 and 2) UPN name constraints have proprietary syntax and
> semantics in the absence of any standard.
> 
> I'd like to propose for this WG to produce a standard for syntax and
> semantics of name constraints for Kerberos principal names. I can work
> on fleshing out this standard based on preparatory work I already did.
> Russ and Tim Polk have already seen some of it and suggested I talk to
> the WG directly.

I am a little confused by this idea/proposal.

It sounds like you're trying to use name-based authentication using
the Kerberos principal names.  Keep in mind that name-based authentication
on Microsoft-Platforms has been notoriously defective and near unsupported
by Microsoft (Microsoft has case-insensitive account names, while
Kerberos principal names are case-sensitive, and Microsoft has serious
bugs in pretty much all of their name-mapping APIs so that it is
near impossible to retrieve the canonical representation of 
Kerberos prinicipal name as known to the KDC (Microsoft Active Directory).

When you're doing name-based authentication, what are the ACLs going
to look like that you're going to use?  Are they going to be name-based
(in which case they're more portable and can be shared with
non-Microsoft platforms) or do you plan on going through a
cert-to-GUID mapping with the help of a Microsoft Active Directory
(in which case I don't see a pressing need for name constraints on the
Kerberos principal name within the certificate.)

-Martin

---

From: "Paul Rabinovich" <[email-masked]>
Date: Wed, 13 Jun 2007 10:05:21 -0400

Martin,

	What I'm proposing is only marginally related to Kerberos in the
technical sense. The idea is: if CAs put Kerberos names in X.509
certificates (which MS does albeit in a proprietary way), you may want
to impose some restrictions on what names a particular CA is allowed to
put.
	Take, for example, e-mail addresses: a root CA may allow a
particular subordinate CA to include only e-mail addresses for @x1.y.com
and another sub. CA, @x2.y.com. There is a standard mechanism (RFC 3280)
that describes syntax and semantics of these name constraints. Same can
and - I propose - should be done for Kerberos names.
	This is done for *any* relying party performing X.509
certificate path discovery and validation. A KDC involved in a PKINIT is
one example of such a relying party but there are tons of others.

	HTH,
	PR

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, June 12, 2007 7:17 PM
To: Paul Rabinovich
Cc: [email-masked]
Subject: Re: WG Last Call - krb-wg charter update

It sounds like you're trying to use name-based authentication using
the Kerberos principal names.  Keep in mind that name-based
authentication
on Microsoft-Platforms has been notoriously defective and near
unsupported
by Microsoft (Microsoft has case-insensitive account names, while
Kerberos principal names are case-sensitive, and Microsoft has serious
bugs in pretty much all of their name-mapping APIs so that it is
near impossible to retrieve the canonical representation of 
Kerberos prinicipal name as known to the KDC (Microsoft Active
Directory).

-Martin