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

From: Jeffrey Altman <[email-masked]>
Date: Tue, 19 Nov 2002 10:23:55 EST

I agree that the draft should not contain a MUST implement mechanism
for mapping Certs to Principals.  However, there does need to be a
mechanism by which Cert to REALM mapping is ensured to work.

> In reference to Jeffrey's comments (see below) I would like to point out
> that I am aware of 3 implementations of PKINIT that are being used today and
> they all use different certificate owner to principal name mapping
> techniques - These are (a) The CyberSafe TrustBroker product, which uses a
> field in the principal database record which contains the DN of the cert
> owner, (b) The Microsoft implementation which uses certificate attributes
> and the DN to determine the account name and (c) The PacketCable solution,
> where the MAC address of an MTA device, which is included in part of the
> certificate X.500 name is mapped onto a principal at the KDC using a mapping
> server. 
> 
> I suggest that the PKINIT draft/RFC should not explicitly enforce the
> implementation to map in a particular way because there will likely be more
> examples in the future where individual implementations require a different
> mapping approach - the best approach (in my opinion) is for the draft to
> suggest a method, and not make this suggestion sound like it must be done in
> that way. 
> 
> Perhaps the various vendors should document the mapping approaches supported
> in a separate IETF draft so that they can be implemented in a standard way
> by other vendors, or alternatively the mapping to principal name can be
> something that is left completely open to specific implementations, as long
> as basic guidelines are followed ?
> 
> Regards, Tim.
> 
> -----Original Message-----
> From: Jeffrey Altman [mailto:[email-masked]] 
> Sent: 19 November 2002 05:26
> To: [email-masked]
> Subject: pkinit comments - cert->realm/princ determination and other
> 
> 
> 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
> 
> 
> 
> 
> 

 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: Sam Hartman <[email-masked]>
Date: Tue, 19 Nov 2002 10:53:01 -0500

>>>>> "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?