Subject: RE: Proposed Changes to PKINIT

From: Matthew Hur <[email-masked]>
Date: Wed, 21 Feb 2001 09:47:36 -0800

Unless I'm missing something, I don't think that any change to the draft is 
required.

PKINIT states that the SubjectAltName to principal name is a local policy 
decision.  Are you looking for wording to explicitly allow the behavior 
that you suggest below?  I'd rather not, as this would start to look a lot 
like the name canonicalization issues that have been raised on the 
list.  Such issues are outside the scope of PKINIT, and the KDC should 
follow the guidelines set forth when the name canonicalization debates is 
resolved.

 From the PKINIT draft:
         2.  If the certificate contains the SubjectAltName extention
             and the local KDC policy defines a mapping from the
             SubjectAltName to a Kerberos name, then use that name.

     Note that a principal name may be carried in the subject alt name
     field of a certificate. This name may be mapped to a principal
     record in a security database based on local policy, for example
     the subject alt name may be kerberos/principal@realm format.  In
     this case the realm name is not that of the CA but that of the
     local realm doing the mapping (or some realm name chosen by that
     realm).

>1) changing the subjectAltName requirement to support the possibility that
>the realm is not included, and

This is not currently disallowed.

>2) adding to the protocol an additional exchange if needed to obtain the
>user's current realm.

If the employee has a home realm, then why can't this be included in the 
SubjectAltName.  Also, the AS-REQ message already has a field for the 
client's realm.

--Matt

At 08:40 AM 2/21/2001 -0500, Friedrichs, Paul LCDR wrote:
>We strongly believe EKU should not be required in the cert (either in the
>standard or by implementations)
>
>Here is the scenario we need supported: When a corporate employee is issued
>credentials (e.g., at corporate headquarters), the employee's employee ID
>number is placed in the cert (as the PKINIT required value of
>subjectAltName). The employee ID number is unique within the corporation.
>The corporation has many Kerberos realms. The employee ID number is used as
>the Kerberos account name. The person transfers to a satellite office, but
>frequently travels among the corporation's various offices. We don't want to
>have to reissue authentication credentials for the person (i.e., we want
>static names), but we want to support user mobility.
>
>The apparently optimal solution doesn't seem to be supported in PKINIT:
>Wherever the employee logs on within the corporation, the cert provides only
>the employee's ID number to the KDC. The KDC sees whether that account is in
>the local realm. If it is, PKINIT continues as before. If it is not, the
>user is prompted to type in his realm. This would appear to have to happen
>during the PKINIT exchange. Additional functionality wouldn't have to be
>included in the standard: The local KDC might cache information on frequent
>visitors, so the visitor would only need to type his realm on the first
>visit. Or the KDC might have a directory allowing it to discover the realm
>based on the employee ID number.
>
>I understand this would involve
>1) changing the subjectAltName requirement to support the possibility that
>the realm is not included, and
>2) adding to the protocol an additional exchange if needed to obtain the
>user's current realm.
>
>Thanks,
>
>Paul
>
>  -----Original Message-----
>From:   John Brezak [mailto:[email-masked]]
>Sent:   Monday, February 19, 2001 9:34 PM
>To:     Matthew Hur; Douglas E. Engert; [email-masked]; Samanick, John
>Cc:     Swatski, Leonard; Hale, Richard; Sam Schaen (E-mail); Rick H Murphy
>(E-mail); Winnenberg, Thomas LCDR; Vickers, Randal R MAJ; Friedrichs, Paul
>LCDR; Brian Tung; [email-masked]
>Subject:        RE: Proposed Changes to PKINIT
>
>I'll comment as soon as I can read the draft with the previous comments
>incorporated.
>
> From the draft-12, I would prefer if it was more consistent with using
>the SHOULD and MUST forms in the different sections. For example, I
>don't have a clear feeling for what is required and how certain features
>like EKU and kerberos principal names in certs are to be required in
>implementations.
>

---

From: Sam Hartman <[email-masked]>
Date: 21 Feb 2001 14:37:53 -0500

>>>>> "Matthew" == Matthew Hur <[email-masked]> writes:

    Matthew> Unless I'm missing something, I don't think that any
    Matthew> change to the draft is required.

    Matthew> PKINIT states that the SubjectAltName to principal name

It sort of depends on what credentials I want doesn't it?  Do I want a
krbtgt for the local realm, or do I want to end up with a krbtgt for
the home realm. 

I was going to ask a minor question but first decided to check and see
if the draft answered it.  In an attempt to answer this, I generated
many more comments.  Here they are; sorry I missed these in my first pass.

1) The document does not clarify how  encryptioncert (line 355)
   interacts with including an encryption certificate in the
   certificates field of the signeddata, described on line   433.

2) On line 574, the text implies that the PKAuthenticator has a field
   to define the KDC's name or realm.  As defined on  line 456, it
   does not have such a field.  We reverify this non-existent field
   again on line 596.

4) On line 607, we check for clock skew.  Shouldn't we do that before
   the replay check?  Also, we check to make sure that the principal
   name is correct?  Which one, client or server, and what cert are we
   comparing against?

5)  On line 628, the text implies that  the KDC may remap the client's
    name based on what is present in the cert and what local
    mappings exist.     I think this text is fairly unclear; I'm not
    exactly sure  how SubjectAltName is used  for client principals;
    what is allowed, and when the KDC is/is not allowed to remap.

More problematic, however, is the fact that the client is not required
to  check the signature of the KDC's data.  This puts us into the same
trust  situation as using name canonicalization for AS replies.  I
think your situation would be much better if you required the client
to verify the signature of  the reply, instead of just extracting the
random key.  I need to understand what mappings are or are not legal
before I can really comment though.

6) On line 865, the draft comments that the previous chunk of text can
   also be used for client names.  Perhaps then it should be pulled
   out of the KDC reply text and something that the user runs across
   earlier.  7) Earlier on line 571, you check to make sure that the
   client name in the request matches the name in the cert.  Does this
   mean that the only legal client name in a pk-init request is the
   encoding of an x500 name specified in a cert as a Kerberos
   principal name.  If so, you should specify this clearly in the
   section  on the client request.