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

From: Tim Alsop <[email-masked]>
Date: Tue, 19 Nov 2002 10:51:41 -0000

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

---

From: "David Hemsath" <[email-masked]>
Date: Tue, 19 Nov 2002 13:34:12 -0700

FWIW, there's a fourth implementation, the IBM Version 3.x DCE security 
server which added support from an early PKINIT I-D.  There's a default 
mapping supplied with the software, but the source of the mapping module 
is also provided for installations to tailor for their own mapping 
policies.

Tim Alsop <[email-masked]>
Sent by: [email-masked]
11/19/2002 04:51 AM

To
[email-masked]
cc
"[email-masked]'" <[email-masked]>
bcc

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

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:

authentication vs. stored public keys broken out into separate 
discussions.

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

Dave Hemsath, IBM Corporation