Subject: RE: "The vendor community is anxious to see....interoperability."

From: Tim Alsop <[email-masked]>
Date: Wed, 20 Nov 2002 16:43:00 -0000

Jim,

I am afraid I do not understand your email - what has PKINIT
interoperability got to do with 3D web sites and 128bit DNS ?

Cheers, Tim.

-----Original Message-----
From: Jim Fleming [mailto:[email-masked]] 
Sent: 20 November 2002 16:13
To: Tim Alsop; 'Lars Johansson'
Cc: Tim Alsop; 'Sam Hartman'; [email-masked]; [email-masked]
Subject: "The vendor community is anxious to see....interoperability."

From: "Tim Alsop" <[email-masked]>
"The vendor community is anxious to see....interoperability."

http://www.ActiveWorlds.com
http://www.OuterWorlds.com

Jim Fleming
128-bit DNS is closer than you think...
IPv16...NET...COM...AM...NZ...AE...FM...NR...SZ...AC...DE...FI...JM...NO...P
R...ST...UZ
http://ipv8.dyndns.tv
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au

----- Original Message -----
From: "Tim Alsop" <[email-masked]>
To: "'Lars Johansson'" <[email-masked]>; "Tim Alsop"
<[email-masked]>
Cc: "Tim Alsop" <[email-masked]>; "'Sam Hartman'"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 20, 2002 9:07 AM
Subject: RE: pkinit comments - cert->realm/princ determination and other

> Lars,
>
> Thankyou for this explanation. As you may know we (CyberSafe) are a 
> vendor of Kerberos products and services and we plan to implement both 
> the methods you outlined below + others into our future product 
> release when the final draft of PKINIT is available. Our current 
> product support for PKINIT is based on draft 5 and I believe Microsoft 
> use draft 9. The vendor community is anxious to see the PKINIT draft 
> reach RFC so that it can be implemented at the same draft level by all 
> concerned and give interoperability.
>
> Regards, Tim.
>
> -----Original Message-----
> From: Lars Johansson [mailto:[email-masked]]
> Sent: 20 November 2002 15:01
> To: Tim Alsop
> Cc: Lars Johansson; Tim Alsop; 'Sam Hartman'; [email-masked]; 
> [email-masked]'
> Subject: RE: pkinit comments - cert->realm/princ determination and 
> other
>
>
> Tim,
>
> Sometimes a rule-based mapping from certs to realm/principal name can 
> be useful. I see this as an optional feature that some vendors might 
> provide for the administrators convenience.
>
> However, I don't want to end up in a situation where the only mappings 
> offered to the administrators are rule-based. The most general mapping 
> I can think of is the following:
>
> 1. First the KDC uniquely recognize (and verifies) the certificate.
>     This could be done with information from the certificate such as
>     the Issuer and Subject DN or the Issuer DN together with the
>     certificate serial number. Alternatively, as you suggest, it could
>     be a fingerprint (hash) of the certificate.
> 2. Given the unique value that the KDC have extracted in step 1
>      it uses this value to search through a mapping table and if it
>      finds a corresponding entry it can fetch the realm and principal
>      name from that entry.
>
> Using this method the administrators can decide on any mapping they 
> want. It would be possible to use already deployed third-party 
> certificates and even have certificates from different CA:s for 
> different users.
>
> The requirements on the KDC would be to be able to extract a unique 
> value (e.g. fingerprint) from any certificate and let the 
> administators freely configure the mapping table. If the vendors offer 
> a rule-based method to simply the configuration of the mapping table 
> for the administrators, that's ok with me!
>
> 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
>
> > Lars,
> >
> > I don't think that the standards should mandate the method that an 
> > administrator uses to configure the mapping in a KDC, however the
> standards
> > will clearly determine which capabilities are made available in each
> vendors
> > KDC for the administrator to use to implement his/her mapping
> requirements ?
> >
> >
> > I can see that each administrator will likely have different needs
> for using
> > information from the cert for mapping - for example, using an
> x509.v3
> > attribute containing the principal name, using the CN, based on a 
> > database/directory lookup using the DN as a key, or a combination of
> more
> > than one of these. If the standard does not allow the required
> information
> > to be made available in some way at the KDC either in the cert or
> sent
> > separately by the client to the KDC then the vendor cannot provide
> this
> > information to the KDC administrator to allow them to configure
> their
> > mapping requirements.
> >
> > I would prefer if each vendor was able to implement as many mapping
> methods
> > as possible and the standard should give the vendors the
> capabilities to do
> > this without too many restrictions. This will give the administrator
> the
> > choice they expect, however I recognise that it might be necessary
> to
> > describe a minimum mapping method (and hence determine which
> information is
> > documneted in the standard) to give interoperability. A client from
> one
> > vendor (ie. Microsoft Windows) will then be guaranteed to work (and
> give the
> > same principal in response) with a KDC from another vendor because
> Microsoft
> > and all other vendors involved will need to support the minimum
> mapping
> > capabilities such that the appropriate information is presented from
> the
> > client side to the KDC and the KDC has the appropriate functionality 
> > implemented in a standard way to determine the principal from this 
> > information.
> >
> > 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.
> >
> > As you said it is important to allow an existing deployment of certs
> and
> > private keys on smart cards to be used for PKINIT - this is why I am
> putting
> > so much emphasis on the flexibility of the mapping so that vendors 
> > implementing PKINIT into their KDC's can support each administrators
> needs
> > and not REQUIRE specific attributes to be set in the certs - if the
> common,
> > minimum implementation that is chosen requires certificate
> attributes then
> > this would not be prefered in my opinion since it would effect
> existing
> > smart card deployments.
> >
> > Regards, Tim.
> >
> > -----Original Message-----
> > From: Jeffrey Altman [mailto:[email-masked]]
> > Sent: 20 November 2002 12:05
> > To: Lars Johansson
> > Cc: Tim Alsop; 'Sam Hartman'; Tim Alsop; [email-masked]
> > Subject: RE: pkinit comments - cert->realm/princ determination and
> other
> >
> >
> > 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
>
> > > >
>
> > > >
>
> > > > >>>>> "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?
>
> > > >
>
> > > >
>
> > >
> > >
> >
>
>
>

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 20 Nov 2002 23:20:24 -0500

> interoperability got to do with 3D web sites and 128bit DNS ?

Ignore him; he's a troll, and he's even gotten his posting privileges
to the mail IETF list yanked a couple of times.