Subject: RE: Proposed Changes to PKINIT

From: "John Brezak" <[email-masked]>
Date: Mon, 19 Feb 2001 18:33:42 -0800

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.

> -----Original Message-----
> From: Matthew Hur [mailto:[email-masked]] 
> Sent: Monday, February 19, 2001 12:39 PM
> To: 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; John Brezak; Brian Tung; 
> [email-masked]
> Subject: Re: Proposed Changes to PKINIT
> 
> 
> Based on the previous comments, we have responses and have 
> made appropriate 
> adjustments to the draft.  Brian Tung is making the final 
> edits to the 
> draft and he will be sending the responses to the list.
> 
> Let's get the DISA comments ASAP, so that we can move forward.
> 
> Perhaps John Brezak could comment to the list as well?
> 
> --Matt
> 
> 
> At 02:22 PM 2/19/2001 -0600, Douglas E. Engert wrote:
> >I received this e-mail and a voice mail concerning PKINIT.
> >I am forwarding it on to the WG list, as we are still in
> >a Working Group Final Call on PKINIT, and awaiting the authors 
> >responses to the other two comments on PKINIT.
> >
> >I would expect a more detailed comment from the DISA people 
> in the next 
> >few days, (Its a federal holiday today), outlining the problems, and 
> >the PKINIT authors to comment.
> >
> >I would also expect that some of them should join the 
> mailing list too. 
> >See http://www.ietf.org/html.charters/krb-wg-charter.html on how to 
> >join the mailing list.
> >
> >
> >
> >"Swatski, Leonard" wrote:
> > >
> > > Hello Doug,
> > >
> > > Some of DISA's folks think changes are needed to the 
> latest PKINIT 
> > > draft. I don't have all the background on this, but I am 
> wondering 
> > > whether it would be OK to point them to you to answer their 
> > > questions on the PKINIT draft?  We in DISA have not been tracking 
> > > the PKINIT effort, but suddenly it has become a hot item 
> because of 
> > > Kerberos support in Windows 2000 and because of potential 
> problems 
> > > with DoD X.509 certificates and Windows 2000.
> > >
> > > If you recall, you and Jim Rome visited me on 20 March 1998 in 
> > > Reston VA to answer my questions on DCE and Kerberos 
> > > interoperability.
> > >
> > > The attached email contains some background, but not the whole 
> > > story.
> > >
> > > Sincerely,
> > >
> > > Len Swatski
> > > Defense Information Systems Agency (DISA)
> > > Joint Information Engineering Organization
> > > Center for Standards
> > > phone: (703) 735-3233
> > >
> > > 
> > 
> ----------------------------------------------------------------------
> > ----------------------
> > >
> > > Subject: PKINIT
> > > Date: Fri, 16 Feb 2001 16:00:49 -0500
> > > From: "Friedrichs, Paul LCDR" <[email-masked]>
> > > To: "Scott, Greg" <[email-masked]>
> > > CC: "Hale, Richard" <[email-masked]>, "Sam Schaen (E-mail)"
> > >      <[email-masked]>, "Rick H Murphy (E-mail)" 
> <[email-masked]>,
> > >      "Samanick, John" <[email-masked]>, 
> "Winnenberg, Thomas LCDR"
> > >      <[email-masked]>, "Vickers, Randal R MAJ"
> > <[email-masked]>,
> > >      "Swatski, Leonard" <[email-masked]>, 
> "Friedrichs, Paul LCDR"
> > >      <[email-masked]>
> > >
> > > Hi Greg,
> > >
> > > I hope you have free cycles to apply to a suddenly very hot 
> > > challenge.
> > > 
> > 
> http://search.ietf.org/internet-drafts/draft->
ietf-cat-kerberos-pk-init
> > -12.tx
> > > t is close to finalization. We just spoke with Microsoft 
> and agreed 
> > > that changes are needed to support static names in certs and user 
> > > mobility. Microsoft will prepare the details, but is afraid they 
> > > won't be successful in getting the changes through 
> (because others 
> > > are suspicious of
> > Microsoft).
> > > Very quickly, we'll need to push this and convince others that 
> > > change is needed.
> > >
> > > Basically, it should be possible that a user's kerberos 
> domain would 
> > > not be in the cert. If it isn't, the INIT server first 
> assumes the 
> > > user is in the local domain. If that proves not to be 
> true, the INIT 
> > > server asks the user which domain they're in.
> > >
> > > So, basically, please become expert on this and get ready.
> > >
> > > Thanks,
> > >
> > > Paul
> >
> >--
> >
> >  Douglas E. Engert  <[email-masked]>
> >  Argonne National Laboratory
> >  9700 South Cass Avenue
> >  Argonne, Illinois  60439
> >  (630) 252-5444
> 
>

---

From: "Friedrichs, Paul LCDR" <[email-masked]>
Date: Wed, 21 Feb 2001 08:40:22 -0500

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

---

From: "Friedrichs, Paul LCDR" <[email-masked]>
Date: Wed, 21 Feb 2001 15:52:43 -0500

Matt, Please see below.

From: Matthew Hur:
> 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).
> 
> 
> This is not currently disallowed.

I had read this, and pointed it out to others. Glad to hear this is your
interpretation of the passage. I agree nothing more specific is
required/desired as long as this is clear to implementers.

> If the employee has a home realm, then why can't this be 
> included in the 
> SubjectAltName. 

The employee may be issued her credential before she is assigned a realm.
Also, realms change. Authentication credential registration can be a very
expensive process, especially on large scales. We want fundamental/static
identity credentials that share no dependencies with relatively transitory
states such as Kerberos realm assignments. 

> Also, the AS-REQ message already has a field for the 
> client's realm.

Perhaps I misunderstand the flexibility already provided by PKINIT. This
scenario would seem to require something like the following:
For the case where the user is logging on within her own realm
1) AS_REQ without realm information
2) KDC discovers that it knows the appropriate realm 
3) AS_REP, completing the PKINIT interaction
 
But for the case where the user is logging on elsewhere
1) AS_REQ without realm information
2) KDC discovers that it does not know the appropriate realm 
3) (modified?) AS_REP (somehow) triggers a user prompt asking for realm
4) AS_REQ with realm information
5) AS_REP, completing the PKINIT interaction

The challenge seems to be that the KDC doesn't know it needs the realm until
after AS_REQ is received.

Certainly a preferable plan would be to have a directory available to the
KDC allowing the KDC to map subjectAltName to a fully qualified Kerberos
name. But this may not be practicable on a large scale. The population of
such a directory would obviate the requested functionality, but having both
in place (assuming the directory is possible) is more robust and flexible. 

Of course, one should be worried about name constraints, but this would
appear to be true of any use of mapping, and not just of the scenario
described above.

> --Matt

Many Thanks,

Paul

---

From: David Kemp <[email-masked]>
Date: Wed, 21 Feb 2001 16:38:51 -0500 (EST)

> Date: Mon, 19 Feb 2001 12:39:20 -0800
> From: Matthew Hur <[email-masked]>
> Based on the previous comments, we have responses and have made appropriate 
> adjustments to the draft.  Brian Tung is making the final edits to the 

Here's the gist of the DoD comments:

* PKINIT permits issuance of Kerberos-specific X.509 certificates
  containing the CertPrincipalName defined in section 3.1.

* PKINIT also permits KDCs to perform a mapping between the Subject
  name of an X.509 certificate and that subject's Kerberos name
  (step 1 of the KDC response decision algorithm, Section 3.2.2).

* The DoD issues general-purpose X.509 certificates to its users.
  These certificates are expected to remain valid for several years,
  during which time the user may change organizations (and therefore
  Kerberos realms, if the gaining organization uses Kerberos) several
  times.

* DoD users may log in at a location away from their current home
  organization, in which case the "host" organization needs to
  know the user's Kerberos realm in order to retreive the user's
  credentials, profiles, etc.

We believe these two conditions (users have non-Kerberos-specific
X.509 certificates, users need roaming access) are of general
applicability, not unique to the DoD.  We are looking for the best
way for PKINIT to accommodate roaming users, presumably by having
the client prompt the user for his Realm (or perhaps his full
KerberosName) and communicate it to the KDC in the client request.

The most straightforward approach may be to include the
PrincipalName in an authenticated attribute of the client request.

---------------- proposed modification ------------
In section 3.2.1, after "3. The Certificates field ...", add:

  4. The signedAttrs field, when non-empty, may contain a krb5Realm
     attribute containing the client's realm.  This attribute may
     be populated by clients when contacting a KDC in a different
     realm.

  The syntax of the krb5Realm attribute is:
  
     krb5Realm OBJECT IDENTIFIER ::= { krb5 3 }
     Realm ::= GeneralString   -- defined in RFC 1510
  
  This attribute is constructed by setting the attrType field to
  krb5Realm and including a single Realm in the attrValues
  field.

---------------- end proposed modification --------

Of course, this is just a suggestion.  Modifications to this
proposal, or suggestions to use a completely different approach
to accommodate roaming users, are welcome.

Dave Kemp

---

From: Matthew Hur <[email-masked]>
Date: Fri, 23 Feb 2001 14:23:56 -0800

I've given this a bit more thought.

First, I made a comment in an earlier email about the client realm in the 
KDC-REQ.  Obviously, I mis-spoke - the KDC realm goes in this 
field.  However, that point is somewhat irrelevant to the discussion.

I am a bit confused by the desire to have the client decide to pass another 
realm to the KDC.  It does not serve a purpose with respect to 
authenticating the client.

In PKINIT, the client realm is that of the CA that issued the 
certificate.  The SubjectAltName in the certificate is an alternate name 
that the CA associates with the client.  The KDC may make a local policy 
decision to map the client to a name within its local realm.

I am ok with the KDC making local policy decisions (i.e. mapping the client 
name/realm).  I am not ok with allowing the client to specify a client 
realm that is different from the realm that is in its authentication 
credentials.  An analogous example would be using non-PK Kerberos.  Say you 
have a client C and two realms 1 and 2.  C gets a cross realm TGT from 
realm 1 for realm 2.  C requests a ticket from realm 2 by sending the cross 
realm TGT, but C adds something to the request to say "hey, I'm not really 
C in realm 1, I'm really someone else".  This is obviously the wrong thing 
to do.  Yet this is equivalent to what we would be doing if the client 
could tell the KDC that it is in a different realm than the one specified 
in its authentication credentials.  Note that there is a difference between 
realm 1 specifying information about C and C specifying information about 
itself, because the cross realm trust relationship is between realm 2 and 
realm 1, not between realm 2 and C.

--Matt

---

From: Matthew Hur <[email-masked]>
Date: Mon, 26 Feb 2001 12:53:22 -0800

At 07:49 PM 2/23/2001 -0500, Friedrichs, Paul LCDR wrote:
>Matt,
>.........
>It's to allow the local KDC to discover the visiting user's home KDC.

When the local KDC discovers the user's home KDC, what is the local KDC 
supposed to do?

> > certificate.
>I guess this doesn't pertain to the question at hand, but why must CAs be
>linked to KDC realms?

A CA is not linked to a KDC realm.  The point that I am making is that the 
CA is equivalent to a separate realm.  It is not a Kerberos realm; it is a 
different domain of trust.

> > The SubjectAltName in the certificate is an
> > alternate name
>Perhaps I misunderstand, but isn't this "local" policy that of the KDC to
>which the traveling user authenticates (and isn't this KDC the one that
>manages the user's account), not the one nearest to the client used to
>logon? If this is the case, then  it appears consistent to me that this is
>only a question of discovery for the local KDC.

To continue my first question above...  Are you saying that the local KDC 
should relay the request to the home KDC?

> > credentials.
>Possibly not changing your argument: I'm proposing that there would be no
>realm in the credential.
>
>I'm confused by the below example. I don't see how exchanges that occur
>before a TGT is provided to the user could be comparable to how TGTs are
>used afterward. If I am C, whose account is in 1, but I am logging on within
>2, isn't it 1 that initially authenticates me? Let's say this was just
>USERID and password. Wouldn't I have to type in my realm if I were a visitor
>from another location? (I do this all the time.) Isn't Kerberos relying on
>nothing other than the string I typed in to find the KDC that can
>authenticate me using the USERID and password? (Again, perhaps I have
>misunderstood how this works.) If so, why is it necessary that the realm be
>in the certificate?

Sorry if my last email was a bit confusing.  I am not saying that the 
Kerberos realm should be in the certificate.  I am saying that the "realm" 
(trust domain) of the client is that of the CA (which is not a Kerberos 
realm).  This is the reason that the name of the CA is placed in the 
transited field of the ticket - because it is equivalent to cross realm 
Kerberos.

> > An analogous example would be using non-PK
> > Kerberos.  Say you
>Again, my understand is that C would tell 2 that 1 can authentic C. 1
>authenticates C and issues the TGT. 2 trusts 1's TGT. Am I off base?

This seems to imply that you want the local KDC to give a referral to the 
client for its home KDC?

>Thanks Again,

I'm not sure why you want what you are requesting, but from what I can 
gather, we do not have to change anything in PKINIT to support it.

Regards,
Matt

---

From: David Kemp <[email-masked]>
Date: Tue, 27 Feb 2001 15:15:26 -0500 (EST)

Matt,

This discussion presupposes that KDC-1 (the user's home KDC) and KDC-2
(the KDC which issues tickets to access services at the location where
the user is attempting to log in) are operating under some sort of
mutual cooperation agreement; organization 1 and 2 have agreed in advance
to extend services to each other's users, or KDC-1 and KDC-2 are operated
by different divisions of the same organization.  The services aren't
just generic "guest" accounts, they actually depend on user-specific
account state maintained in the user's home organization.

The answer to your question depends on where the access control
decision is made.

           KDC-1
            :
           :
          :
 1)    KDC-2
         |                      Realm 2
       User ---<KDC-2 tkt>--- file server

                                           ----- Kerberos protocol

                                           . . . Access control info
           KDC-1.                                (non-Kerberos protocol)
            /        .                 
           /              .
 2)       /                    .
         /                      Realm 2
       User ---<KDC-1 tkt>--- file server

We are assuming (picture 1) that a resource within Realm 2 only accepts
tickets from KDC-2 as the basis for providing services.  In that case, KDC-2
needs to know the realm for KDC-1 in order to collect whatever information
it needs before deciding to grant a ticket.  The KDC in this case is not
just a cryptographic engine, it is the administrative controller for
deciding who gets to do what.

In an environment where each resourse can be individually configured to
make its own access control decisions (picture 2), then you are correct
-- there is no need for PKINIT protocol changes.  The user's client could
contact the remote KDC directly, and the resource would accept a ticket
from the remote KDC and contact the remote administrative database itself.

I don't know how realistic picture 2 is, but that is not our planned
environment.  We expect to be operating in picture 1, where the local
KDC makes all the decisions about how local resources are used.  The
details of how that decision is made and what data needs to be exchanged
between realms aren't pertinent; all that PKINIT needs to be concerned
with is that KDC-2 knows how to find KDC-1 using some (non-Kerberos)
back-end protocol.

Regards,
Dave

---

From: "Paul Leach" <[email-masked]>
Date: Wed, 28 Feb 2001 10:34:34 -0800

> From: Douglas E. Engert [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2001 6:48 AM
 
> 
> One of the problem is that UNIX does not have a concept of a 
> global userID. It only
> has local userID. i.e. the realm is not kept with the userID. 
> Where as W2K,
> DCE/DFS, AFS (to some extent) do.
  
Actually, WIn2k doesn't really keep the realm in the user ID; it just
tries to make the user ID global, and then use some mechanisms to locate
the "real" realm of the user from the global userID. (It can use
structure with the userId as a hint to those mechanisms.) Those
mechanisms currently only extend so far.

What Paul is interested in a _really_ global ID -- so much so that the
user will sometimes need to inform the workstation being logged into
what realm their account is in (i.e., where the AS-REQ should be sent).

Paul