Subject: RE: PKINIT, rev 10

From: "Medvinsky, Sasha (SD-EX)" <[email-masked]>
Date: Thu, 28 Oct 1999 17:53:41 -0400

Also, it appears that "the name of each certifier in the certificate chain
must be added to the transited field of the ticket", is not precise enough.

Kerberos revisions draft says: "A realm name ending with a "." is
interpreted as being prepended to the previous realm".  The X500-RFC2253
encoding of a realm name can theoretically end on a '.', but you don't want
it to be prepended to the previous realm.  Kerberos revisions has some other
rules that don't apply to a X500-RFC2253 encoding of a realm, but this is
the only one that appears to be a problem.

> -----Original Message-----
> From:	John Brezak (Exchange) [SMTP:[email-masked]]
> Sent:	Thursday, October 28, 1999 11:40 AM
> To:	'Brian Tung'; [email-masked]'
> Subject:	RE: PKINIT, rev 10
> 
> There is an issue in PKINIT having to do with the use of the transited
> field
> and compatability with existing KDCs.
> 
> From PKINIT-10:
> 
> Since each certifier in the certification path of a user's
>     certificate is equivalent to a separate Kerberos realm, the name
>     of each certifier in the certificate chain must be added to the
>     transited field of the ticket.  The format of these realm names is
>     defined in Section 3.1 of this document.  If applicable, the
>     transit-policy-checked flag should be set in the issued ticket.
> 
> In this case the transited field would contain X500-RFC2253 nametype. Most
> of the widely deployed Kerberos realms are not able to check this nametype
> and will reject any ticket obtained via PKINIT from a realm that does
> this.
> 
> For example the MIT Kerberos 1.0.5 KDC will fail with "Illegal cross-realm
> ticket" when it encounters a PKINIT'ed ticket that implements this.
> 
> If this mechanism is required, then there will be no interop with existing
> deployed Kerberos realms.
> 
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> John Brezak                  * mailto:[email-masked]
> Microsoft Corporation        * 425-936-2602
> One Microsoft Way
> Redmond, WA 98052
> 
> ==========================================================================
> This message was posted through the Stanford campus mailing list
> server.  If you wish to unsubscribe from this mailing list, send the
> message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 29 Oct 1999 10:13:57 -0500

While you are discussing how to add CA names into the transited field, consider
the more general problem of how you would add the transited field into a X.509 extension. 

PKINIT lets you use certificates to get a TGT. There are other systems which will issue
you a certificate based on a Kerberos ticket. (k5cert for example.) And the certificate
chain used on PKINIT may have been delegated as well. 

Our Globus project (http://www.gobus.org) has a GSSAPI built on the SSL protocol. 
We have added delegation, by having the acceptor create a key pair and the initiator sign a 
"proxy" certificate which becomes part of the certificate chain. This allows for the 
equivalent of a Kerberos forwarded ticket. 

These proxy certificate and the chain can be used to get a TGT. We are not using PKINIT 
yet, but SSLK5 which is functional equivalent, using an SSL session to transmit the AS_REQ
to a modified KDC which will accept the SSL authentication and issue a TGT, returned
by the SSL session. 

So it is possible to do the following:

  Smart Card with X.509 certificate use to get a local proxy certificate 
                 (done on PC much like doing a kinit)
  Proxy certificate chain uses sslk5 to get TGT (could use PKINIT here)
                 (so I can do a ktelnet)
  TGT is forwarded across realms.
                 (ktelnet to ktelnetd)
  TGT is used to get a short term certificate at some site k5cert program.
                 (get a certificate to run Globus job)
  certificate is delegated using another proxy certificate
                 (Globus job starts many processes at other sites delegating proxies
		  which are used for process-to-process authentication) 
  Proxy certificates then used to get another TGT.
                 (Need access to local DFS which is using Kerberos)

So it might be time to reexamine the transited field of Kerberos, and look at a more
general structure, which could be carried in a ticket, or as a X509 extension,
and added to as certificates are issued based on the kerberos ticket, or kerberos
tickets are issued based on a certificate chain.  

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: "Douglas E. Engert" <[email-masked]>
Date: Sat, 30 Oct 1999 08:35:34 -0500

(This message is a reposting as the first appears to have not made it to the list. 
Sorry if you have already received a copy.)

--