RE: [Fed-Talk] SmartCard Login FWD: Interop Event March 2006
RE: [Fed-Talk] SmartCard Login FWD: Interop Event March 2006
- Subject: RE: [Fed-Talk] SmartCard Login FWD: Interop Event March 2006
- From: "Nebergall, Christopher" <email@hidden>
- Date: Fri, 3 Mar 2006 08:45:14 -0700
- Thread-topic: [Fed-Talk] SmartCard Login FWD: Interop Event March 2006
I wanted to forward this message from the IETF Kerberos working group.
Is Apple sending someone to this?
-Christopher
From: email@hidden
[mailto:email@hidden] On Behalf Of Liqiang(Larry)
Zhu
Sent: Thursday, March 02, 2006 12:24 PM
To: krb-wg mailing list
Cc: Jeffrey Hutzelman; Sam Hartman; JK Jaganathan
Subject: Interop Event March 2006
On behalf of the MIT Kerberos team and Microsoft Kerberos team, and with
the permission from the Kerberos chair Jeffrey Hutzelman, I am pleased
to announce the 2006 interop event co-hosted by the MIT and Microsoft
teams. Love @ Heimdal has confirmed he would be attending this event.
Meeting Dates and Agenda:
This two day interop event will be held at Boston starting Monday
3/27/2006 through Tuesday 3/28/2006. The date is arranged right after
IETF65, so that folks out of the states can come to US in one trip. If
you are coming, please plan your itinerary accordingly.
Here are items on top of our priority list for this event.
0) SPNEGO/RFC4178 interop
1) PKINIT-34 interop
2) kerberos IPv6 support interop
3) Kerberos RFC4121 interop
4) Kerberos etype negotiation interop
5) More Kerberos AES interop, we did this during our 2005 interop event,
and we would like to do a refresh.
6) OCSP support for PKINIT
The implementations of these protocols and enhancements will be
available in Vista. We would like to invite anyone, who has a product
that is going to interop with Vista, to participate in this event.
A message from the Microsoft Kerberos team: Vista is the most exciting
release in the history of Microsoft, please come and help us make it
even better.
Meeting Venue: MIT
Hotel Accommodations: HYATT REGENCY CAMBRIDGE, 575 MEMORIAL DRIVE,
CAMBRIDGE, MA 02139, Phone(s) 617-492-1234 / 617-491-6906
Registration: free but we would strongly prefer people let us know they
are coming, please email email@hidden, email@hidden,
email@hidden, or email@hidden if you are coming, excluding those
who has already confirmed with one of us.
-- Larry
-----Original Message-----
From: Timothy J. Miller [mailto:email@hidden]
Sent: Tuesday, February 28, 2006 7:23 AM
To: Paul Nelson
Cc: Shawn Geddis; Nebergall, Christopher; Brian Raymond; Apple Fed Talk
Subject: Re: [Fed-Talk] SmartCard Login
Paul Nelson wrote:
> There is no
> documented way to determine which smartcard certificate should be used
>to attempt the as_req.
I forgot to respond to this before. In fact, this part is easy.
There are three certs on a CAC; one for email signing, one for identity
authentication (little used), and one for email encryption.
Insofar as the PKINIT standard is concerned, any cert with the right key
usage (digital sig) can work. There are two of these on the CAC: the
email signing and the identity certificates.
However, Windows levies additional certificate profile requirements. In
particular, it will (currently) only accept certificates that also
contain the smartcard logon (SCL) enhanced key usage OID
(1.3.6.1.4.1.311.20.2.2) *and* contain the user's AD
universalPrincipalName in the subjectAlternativeName extension.
(Technically, it's an ASN.1 encoded blob stuffed into an otherName type
field in the SAN extension.) There's only one cert on the CAC that
meets both of these requirements: the email signing certificate.
So for now, look for the SCL OID and use that cert. If you need the
user's account (the UPN), it can be extracted from the same cert.
The DoD PKI made a conscious choice to avoid "customizing" certificates
to meet application requirements whenever possible; and when impossible
to avoid, the custom extensions all go into the email signing
certificate.
Toward that end, Vista makes some significant changes regarding SCL, at
the DoD PKI's behest. In Vista Server environments there will be *no*
certificate profile requirements specific to SCL (aside from basic key
usage constraints, of course). This will allow us to map *both* the
email signing and the ID certs to an account, and either will work just
fine. So the cert selection logic will get even simpler; you can even
let the user choose.
The JITC CACs you get will have all this in their certs.
A word about UPNs:
In AD, your UPN is your account name plus your home domain FQDN (frex.,
email@hidden). This is *not necessarily* your email address, so
*don't* use the rfc822Name that's also in the certificate when you need
the UPN.
But we do UPNs a little differently in the DoD. Because of some complex
infrastructure issues, we create user UPNs using the user's electronic
data interchange personal identification (EDIPI) number, with the domain
FQDN portion set to @mil. EDIPIs are 10-digit numbers that (supposedly)
replaced SSNs for ID purposes. (JITC CACs use fake EDIPI numbers, but
the data is present in the email signing certs.)
Yes, this creates cross-forest issues in AD, but we don't do
cross-forest stuff right now, so we avoid those issues. Vista's changes
to SCL certificate requirements completely solve this issue for us: the
certificate will no longer be the source for UPN data. GINA will prompt
the user for an account name as well as their CAC PIN. This opens up
the ability to map one certificate to more than one account, which is an
extremely important capability for us to have.
-- Tim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden