Subject: pkinit comments - cert->realm/princ determination and other

From: Jeffrey Altman <[email-masked]>
Date: Tue, 19 Nov 2002 0:26:00 EST

As pointed out by Tom, there are concerns related to the use of the
X.500 DistinguishedName to UTF-8 String mappings with regards to
Uniqueness.  This translation is not the only way that a certificate
to Realm or certificate to principal mapping can occur.  The draft
also describes that site policies can be specified to perform these
mappings.  Unfortunately unlike similar documents for HTTPS, TELNET
START_TLS, and FTP AUTH TLS this document does not describe how these
alternate policy specific mapping should work. Or could work.  There
is no discussion of what should be done if there are multiple
subjectAltName extension fields specified in the certificate.

It also seems very unclear to me why the authors simply did not define
a new X.509 v3 extension to allow the REALM associated with the CA
certificate and sub-certs to be specified thereby avoiding this mess
entirely.  

The Introduction of the draft discusses the use of PKINIT for various
things including:

 . TGT retrival from the KDC

 . Service Ticket retrieval without use of a KDC

This second item is not described well or at all in this draft.

I would also like to see the cases where certificates are used for
authentication vs. stored public keys broken out into separate
discussions.  The failure to do so makes section 4 (Logistics and
Policy) a bit awkward since it only addresses a discussion of the
certificates case and not the stored public key case.

My overall feeling about this draft is that it needs a bit of
attention to ensure that all of the desired cases have been
appropriately analyzed and described.

It would be useful if the authors could provide a short description of
the motivations behind some of the decisions.  Use of certificates for
multiple purposes like the use of encryption keys for multiple
purposes is frowned upon.  Therefore, it would be inappropriate to use
an existing deployed S/MIME cert for use as a Kerberos authenticator
in the context of PK-INIT.  Requiring the use of a new x.509 v3
extension to specify the Kerberos Realm or Principal would not seem
burdensome in that light.

PK-INIT has the potential to provide an alternative to PRE-AUTH
methods that might be subject passive attacks without the need to
license patents for EKE,SP-EKE,SRP,PAK,... The notion of using PK-INIT
for direct Service Ticket retrieval (no KDC) would be extremely useful
for authenticating to services in a world with unreliable
communications.  I would like to see this draft get the attention it
requires so that it can move forward.  However, it should not move
forward without the requisite attention.

- Jeff

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 19 Nov 2002 11:38:05 EST

> >>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:
> 
>     >> >>>>> "Jeffrey" == Jeffrey Altman <[email-masked]>
>     >> writes:
>     >> 
>     Jeffrey> I agree that the draft should not contain a MUST
>     Jeffrey> implement mechanism for mapping Certs to Principals.
>     Jeffrey> However, there does need to be a mechanism by which Cert
>     Jeffrey> to REALM mapping is ensured to work.
>     >>  Can you get interoperability without such a must implement
>     >> mechanism?
>     >> 
>     >> 
>     >> 
> 
>     Jeffrey> Define what type of interoperability you expect to have?
> 
> I want to be able to use a client from any implementation from a KDC
> with any other implementation.

The mapping from the cert to the principal is performed by the KDC and
does not involve the client.  The client simply needs to specify the
desired principal name and know how to choose the correct certificate
to use for that principal.

> I might actually want to be able to use one vendor's CA with another
> vendor's KDC as well.

That is not restricted by the current implementation since there is no
Kerberos specific data in the CA Cert nor in the client certs.
However, Certs are supposed to be designated for specific purposes.
Therefore, the creation of a Kerberos REALM and Kerberos Principal
X.509 V3 extension would be appropriate.

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 20 Nov 2002 7:05:12 EST

Lars,

As far as I am aware nobody in this thread is requesting that a MUST
or even a SHOULD be specified.  What I want is a MAY that describes
how mappings could be done via use of X.509 v3 extensions.

 - Jeff

> Dear Tim and all,                                                     
>                                                                       
> I strongly recommend NOT to mandate any mapping method                
> from X.509 certificates to Kerberos principal/realm name.             
> IMHO this mapping should be decided by the Kerberos                   
> administrator, not by the vendors or standard setting bodies.         
>                                                                       
> It should especially be avoided to specify any requirements           
> on the X.509 certificate content in PKINIT.                           
>                                                                       
> I can forsee situations where the client principals already           
> have certificates (sometimes with the private key stored              
> on a smart card), issued by a third party that had no idea            
> of what Kerberos realm the certificate holder should become           
> part of or even his/hers principal name. It should be up to           
> the Kerberos or (internal) network administrator to decide            
> whether or not to accept the client's (third party) certificate       
> and to set up the mapping from the certificate content to the         
> Kerberos realm/principal name.                                        
>                                                                       
> Kind regards!                                                         
> _________________________________________________                     
> Lars Johansson | Consultant                                           
> [email-masked] | www.omegapoint.se                      
> phone +46 70-915 88 40 | fax +46 8-517 008 29                         
> Omegapoint AB - din säkra punkt i tillvaron                           
>                                                                       
> > May I suggest that each KDC and client vendor who allready has      
> support for                                                           
> > PKINIT and all vendors who implement PKINIT in future products need 
> to adopt                                                              
> > a consistent and interoperable method for cert to principal/realm   
> mapping,                                                              
> > but also have the capability to support other mapping methods. It   
> would also                                                            
> > be great if the KDC could determine, based on information in the    
> AS-REQ                                                                
> > which mapping method to use before returning the appropriate AS-REP.
> If the                                                                
> > KDC does not support the mapping method requested at the client then
> an                                                                    
> > appropriate error response can be sent to the client and the        
> authentication                                                        
> > request denied.                                                     
> >                                                                     
> > With this approach it would be possible (for example) for a KDC to  
> be                                                                    
> > configured to support the mapping from PKINIT code provided in      
> Win2k/XP                                                              
> > clients and also the same KDC could support a different form of     
> mapping for                                                           
> > other clients/devices in the same network. Would it be possible (or 
> is it                                                                 
> > allready considered) to have some code in the KDC that determine the
> PKINIT                                                                
> > draft version used by the client and could a mapping type indicator 
> be                                                                    
> > transferred in the AS-REQ in some way to provide this functionality 
> ?                                                                     
> >                                                                     
> > The draft should describe a consistent baseline mapping approach,   
> but should                                                            
> > also clearly state that there is a capability for alternative       
> mapping                                                               
> > methods to be supported by some KDC's. If this is possible and      
> desired then                                                          
> > the mapping determination method for the KDC should be documented.  
> >                                                                     
> > Cheers, Tim.                                                        
> >                                                                     
> > -----Original Message-----                                          
> > From: Sam Hartman [mailto:[email-masked]]                         
> > Sent: 19 November 2002 15:53                                        
> > To: [email-masked]                                            
> > Cc: Tim Alsop; [email-masked]                                  
> > Subject: Re: pkinit comments - cert->realm/princ determination and  
> other                                                                 
> >                                                                     
> >

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 20 Nov 2002 9:14:04 EST

I do not believe that it would be possible to enumerate all of the 
possible methods for mapping from certificates to principals.  In my
products I always provide hooks for two functions

  X509_to_user(cert, userbuf, buflen)

and 

  X509_userok(cert, user)

so that sites can decide for themselves what the mapping algorithms
should be.  As an extreme example it is possible to provide a cert to
principal mapping function that ignores the informational content of
the cert entirely and simply relies on the cert fingerprint as a means
of uniquely identifying the cert.

As was pointed out at the session yesterday, using the DN, CN, or
extensions as a means of mapping the cert to an identity assumes that
the CA that is issuing the certs understands the mapping model being
used and ensures that certs containing inappropriate data for that
model are never issued.  Therefore, it is extremely important that the
draft detail the information that should be made available for the
purposes of mapping.  Otherwise, CAs will not understand their
obligations.

Tim wrote:
> I also feel that ideally, if the above is agreed by all concerned then a
> client that support PKINIT should be able to pass information to a KDC and
> ask the KDC to use a particular mapping method. I am not sure if this is
> possible or practical however. Does anybody have any view on this ? It would
> certainly be useful to maintain backwards compatability so that an existing
> Win2k client could tell the KDC which version and mapping method it is
> expecting to use.

 Jeffrey Altman * Sr.Software Designer     Kermit 95 2.0 GUI available now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP, and 
 [email-masked]               OpenSSL.

---

From: Tim Alsop <[email-masked]>
Date: Wed, 20 Nov 2002 14:38:35 -0000

Jeffrey,

Thankyou for the update from the IETF session. Anyway, I understand the
reason why the draft must contain details for cert identity mapping.
However, I think that Lars highlighted that with existing PKI deployments,
where certs are allready issued it should not be necessary to conform to
anything documented in the standard and cause certs to be reissued. How do
you suggest the proposed PKINIT approach positions itself against this need
?

Perhaps I was a bit hopeful suggesting that the different mapping methods
could be enumerated :-)

Regards, Tim.

-----Original Message-----
From: Jeffrey Altman [mailto:[email-masked]] 
Sent: 20 November 2002 14:14
To: Tim Alsop
Cc: Lars Johansson; Tim Alsop; 'Sam Hartman'; [email-masked]
Subject: RE: pkinit comments - cert->realm/princ determination and other

and 

  X509_userok(cert, user)

so that sites can decide for themselves what the mapping algorithms should
be.  As an extreme example it is possible to provide a cert to principal
mapping function that ignores the informational content of the cert entirely
and simply relies on the cert fingerprint as a means of uniquely identifying
the cert.

As was pointed out at the session yesterday, using the DN, CN, or extensions
as a means of mapping the cert to an identity assumes that the CA that is
issuing the certs understands the mapping model being used and ensures that
certs containing inappropriate data for that model are never issued.
Therefore, it is extremely important that the draft detail the information
that should be made available for the purposes of mapping.  Otherwise, CAs
will not understand their obligations.

Tim wrote:
> I also feel that ideally, if the above is agreed by all concerned then 
> a client that support PKINIT should be able to pass information to a 
> KDC and ask the KDC to use a particular mapping method. I am not sure 
> if this is possible or practical however. Does anybody have any view 
> on this ? It would certainly be useful to maintain backwards 
> compatability so that an existing Win2k client could tell the KDC 
> which version and mapping method it is expecting to use.

 Jeffrey Altman * Sr.Software Designer     Kermit 95 2.0 GUI available
now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP,
HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP,
and 
 [email-masked]               OpenSSL.

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 20 Nov 2002 9:43:42 EST

An RFC can never dictate what is done in the world by users.  It can
only determine the mandatory items that developers must do in order
for their products to be compliant whether they be software or certs 

- Jeff