Subject: [Ietf-krb-wg] Updates Needed for draft-hotz-kx509-00

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 13 May 2010 18:32:19 -0700

I was able to circulate this draft privately before I had clearance to submit it.  Based on feedback from two implementors of the protocol I can already say:

1) There should be a standards-track version of an update to the protocol which takes advantage of the evolution of both Kerberos and PKI since the protocol was created.

2) The draft, though written to be standards-track, should instead be informational.

I welcome other feedback.  Comments I have so far are:

Should use the kerberos checksum instead of HMAC-SHA1 (IMO bumps protocol version).

Error codes should be standardized, allowing better client failover.

Public Key type needs more specification.  In particular some specification (or negotiation) of minimum key size, and allowable key types.  (Existing client implementations seem to only generate 512-bit RSA keys.  Needs updating, but that doesn't force a version change.)

Certificate encoding needs more specification.  In particular I'm told that the issued certificates should include:

	• KCA  "1.3.6.1.4.1.250.42"
	• KCA AUTH REALM   "1.3.6.1.4.1.250.42.1"
	• Krb5 Principal Name "1.3.6.1.5.2.2"
	• Use of subject Alt e-mail field for principal name
(I think I disagree with the last, since IMO a principal only looks like an email address, and it won't necessarily work as one.  If it's existing practice, then fine, but delete it in the new version.)

Add text to the security considerations noting that there is no proof the requester is in possession of the corresponding private key, which opens up a number of issues.  Shouldn't use these certs for digital signature.  (Need to fix this in the next version.  Isn't there a chicken-and-egg problem with using the PKI key pair for standard digital signatures in advance of having an actual certificate?)

Reference TAGPMA requirements.

Error text should be UTF8String instead of VisibleString  (IMO should change in new version.)

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

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

---

From: Michael StJohns <[email-masked]>
Date: Thu, 13 May 2010 22:20:03 -0400

>(I think I disagree with the last, since IMO a principal only looks like an email address, and it won't necessarily work as one.  If it's existing practice, then fine, but delete it in the new versi…

See RFC4456 - specifically the id-pkinit-san subject alternative name encoding which defines a kerberos centric certificate name encoding.

Mike

---

From: Martin Rex <[email-masked]>
Date: Fri, 14 May 2010 19:09:02 +0200 (MEST)

Michael StJohns wrote:
> See RFC4456 - specifically the id-pkinit-san subject alternative name
> encoding which defines a kerberos centric certificate name encoding.

It seems that Microsoft has been shipping functionality to include
_some_ principal name ("UPN") in X.509v3 certificates, in a
subjectAltName type "other" with the OID 1.3.6.1.4.1.311.20.2.3.

Unfortunately it shares the awkwardness with their APIs in that it
is not a valid Kerberos principal name.  The uppper/lowercasing
of the Realm part is definitely incorrect, and I wouldn't bet on
the correctness of the upper/lower-casing on the part before
the "@" either.  So that entry is a someone unusable unless oneself
happens to be the responsible Active Directory that is cabable to
correctly canonicalize that UPN into a correct Kerberos principal
name for use within Kerberos protocol exchanges.

-Martin

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 14 May 2010 14:09:59 -0400

>is not a valid Kerberos principal name.

That's because it's not a principal name at all.  If you inspect the PKINIT packets Windows emits, they use NT-ENTERPRISE for this identifier.  NT-ENTERPRISE is an arbitrary identifier that maps to a unique principal name.

Windows principal names are [email-masked].

-- Tim

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Martin Rex
>Sent: Friday, May 14, 2010 12:09 PM
>To: Michael StJohns
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: [pkix] [Ietf-krb-wg] Updates Needed for draft-hotz-kx509-00
>
>Michael StJohns wrote:
>>
>> >        * Use of subject Alt e-mail field for principal name
>> >(I think I disagree with the last, since IMO a principal only looks
>like an email address, and it won't necessarily work as one.  If it's
>existing practice, then fine, but delete it in the new version.)
>>
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 14 May 2010 14:02:58 -0400

The X.509 GeneralName field used in the SubjectAltName extension is
called "rfc822Name" rather than "email address" because it can be used
to identify the subject without requiring a provisioned mailbox, as in
an XRI organization-based identifier:

   iauthority = [ iuserinfo "@" ] ihost [ ":" port ]

(Note that RFC 5280 says that an email address MUST be encoded as
rfc822Name, but it does not say that everything encoded as an rfc822Name
MUST be an email address.)

I'm not saying that pkinit-san should not be used, just that there is no
reason to remove or phase out rfc822name.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael StJohns
Sent: Thursday, May 13, 2010 10:20 PM
To: Henry B. Hotz; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [pkix] Updates Needed for draft-hotz-kx509-00

Mike

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 14 May 2010 13:43:42 -0500

> That's because it's not a principal name at all.  If you inspect the PKINIT packets Windows emits, they use NT-ENTERPRISE for this identifier.  NT-ENTERPRISE is an arbitrary identifier that maps to…

When Microsoft started using smart cads the the principal as the
subjectAltName othername MSUPN to the cards. This was a simple way
to map a cert to an AD account using the existing attribute of
userPrincipalName. This would only work if the card is issued by
the enterprise CA.

So over the years things have changed. One can change the account
userPrincipalName attribute to match whatever is on the smart card and

> Windows principal names are [email-masked].

And IIRC, one can still kinit using either [email-masked]
or the userPrincipalName value. So CAC or PIV cards with a MSUPN like
[email-masked] to the cert can still work on W2003 DCs.

With W2008s DC the subjectAltName does not need to be in the certificate,
and some other mapping of certs to accounts can be used. But the damage
has been done, the userPrincipalName attribute is not what one might expect.

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 14 May 2010 15:11:23 -0400

>or the userPrincipalName value.

Yep.  I've done this for kinit w/ both Heimdal and MIT Kerberos clients and Microsoft KDCs.

>                                       So CAC or PIV cards with a MSUPN like

As long as you set the sAMAccountName to 'nnnnnnnnnnnnn' you can use NT-PRINCIPAL in the AS-REQ, but you still must have 'nnnnnnnnnnnnn' in the UPN or the Win2k3 KDC will blow chunks.

>With W2008s DC the subjectAltName does not need to be in the
>certificate, and some other mapping of certs to accounts can be used.

Depending on whether or not the user entered a domain hint or username hint (or both) in the Credential Provider UI and whether or not the UPN is in the selected certificate, the Windows Vista and Win7 clients send either NT-PRINCIPAL with the actual principal name (or the client's guess as to what that principal name should be), NT-ENTERPRISE with the userPrincipalName from the cert, or NT-X500-PRINCIPAL with the certificate subject distinguished name.

Only the Win2k8 KDC can deal properly with NT-PRINCIPAL or NT-X500-PRINCIPAL when the UPN is not also in the PKINIT certificate, and in both cases will attempt discovery of the mapped account (when NT-X500-PRINCIPAL is used) or verifification the certificate mapping to the specific account (when NT-PRINCIPAL or NT-ENTERPRISE is used) using any of 8 methods (upn, subject DN, subject & issuer DNs, subject DN & issuer DN & serial, issuer DN & serial, subject key identifier, sha1 hash of the public key, or rfc822name).

>                                                                       But the damage

Exactly; the userPrincipalName...isn't.

What a mess.

However, I think this is probably way off topic.

-- Tim

>From: Douglas E. Engert [mailto:[email-masked]]
>Sent: Friday, May 14, 2010 1:44 PM
>To: Miller, Timothy J.
>Cc: [email-masked]'; Michael StJohns; [email-masked]; ietf-krb-
>[email-masked]; [email-masked]
>Subject: Re: [Ietf-krb-wg] [pkix] Updates Needed for draft-hotz-kx509-00
>
>
>
>> That's because it's not a principal name at all.  If you inspect the
>PKINIT packets Windows emits, they use NT-ENTERPRISE for this
>identifier.  NT-ENTERPRISE is an arbitrary identifier that maps to a
>unique principal name.
>>
>

---

From: Martin Rex <[email-masked]>
Date: Fri, 14 May 2010 20:24:02 +0200 (MEST)

Henry B. Hotz wrote:
> 
> Certificate encoding needs more specification.
> In particular I'm told that the issued certificates should include:
> 
> 	o  KCA  "1.3.6.1.4.1.250.42"
> 	o  KCA AUTH REALM   "1.3.6.1.4.1.250.42.1"
> 	o  Krb5 Principal Name "1.3.6.1.5.2.2"
> 	o  Use of subject Alt e-mail field for principal name
>
>  like an email address, and it won't necessarily work as one.
>  If it's existing practice, then fine, but delete it in the new version.)

I agree to your disagreement with the last.

The problematic thing with the rfc822Name subjectAltName is
the underlying ASN.1 type:

http://tools.ietf.org/html/rfc5280#page-128

GeneralName ::= CHOICE {
     otherName                 [0]  AnotherName,
     rfc822Name                [1]  IA5String,
     dNSName                   [2]  IA5String,

I don't recall a desision that I18N for Kerberos principal names
was going to use an "ascii compatible encoding"...  8-]

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 14 May 2010 14:29:28 -0700

I should have checked this first, but the third item is identically the kerberos principal name described in RFC4556, section 3.2.2.  I do believe the cert should unambiguously record what it's based on, and I think this is the correct way to do it.