Welcome. Smart cards and other two-factor authentication sessions. My name is Sean Geddes, security consulting engineer in Apple's enterprise division. What we want to do today is give you a little bit of an insight into, first of all, two-factor authentication itself, how it can help you solve an identity problem that many of you may have in your enterprise space, take a little bit closer look from an enterprise view of the smart card services or the support built into Mac OS X.

potentially choose a particular two-factor authentication solution. Some pick PKI, some pick one-time passwords. There are others out there. We'll take a little bit of a look there. And then I want to bring up some of my customers that we have been participating with in some of their projects and have them share with you a little bit of their experiences, a little bit of their expectations.

So what we hope you will learn from this is, again, find out what those challenges are maybe that you haven't faced yet. Maybe if you're a developer, challenges that you could help solve. Hit a little bit on the DNA of two-factor authentication for those of you that are new to this.

Look closely, again, two-factor authentication OS X, and then how to integrate that into various server and network configurations. So let's get started. First of all, what are the problems we're trying to solve within the enterprise space? First and foremost has kind of arisen to the top, and that is some true form of secure and reliable form of identification. We all realize that after a while, just kind of a username and password tends to not be a real good, strong solution here. So we want to look at something as strong and reliable.

There are a lot of directives that are being kind of bantered about and issued and mandated around the world. Some of those in the U.S. federal government. HSPD-12 was a directive for all federal governments to issue smart cards. A lot of you might be familiar with some of the HIPAA requirements and Sarbanes-Oxley and others. But there's other data directives, data protection.

So this is a very important thing to be sure you have solutions that prove that people are who they say they are. And of course, a single sign-on solution helps you ensure that they're not entering 15, 20 different passwords to have access to all these services. Tied into that, particularly when you're doing some cyber activity, you want to be sure that you're retaining the integrity of that data.

Similar to that is the confidentiality. If you're sending kind of encrypted content, you want to be sure that it's only -- the recipient of that is only that person or that individual that's intended. And then be sure that, again, if that transaction takes place, non-repudiation. You can't deny the fact that you didn't do that.

So this is a statement from Tom Yager back in 2004 at WWDC. I like it because it's so true in this space, and that is none of us really purchase anything unless, first of all, we're going to make money off of it. We're going to save money, or in his words, the government requires it.

So let's take a look, first of all, at two-factor authentication. What is that? First of all, we're all quite familiar with username and password. It's kind of a one factor. It's something you know. Add to that what you have. A lot of us have all kinds of dongles, all kinds of devices. It's physically something you have, separate from something you know here.

Something we're not going to really touch on today, but a third factor there is what you are. Biometrics. Could be fingerprints, could be facial recognition, could be retinal scans, that kind of thing. All of those play into those multi-factors. And just to clear up with the two-factor authentication, or at least a definition of that is, you take any two of those previous factors, just looking at those three, combine them together, and now you've got a much stronger form than just taking one of them by itself.

So tokens, in this space, kind of the reference of tokens tends to get a little-- it's kind of an overloaded term. I just wanted to hit on this a little bit. The reference of token is really kind of an abstraction of all of these-- or it's kind of here serving as a visible or a tangible representation of something abstract. It's something we can refer to. But a token sometimes may be referred to as a physical token device, or a token may be again kind of an abstraction with a one-time password or smart card in this case.

But the other thing, since you're in kind of the enterprise space, the critical point is how in the world do you get these two-factor authentication solutions tied into your directory service, right? We all know that we're not all tied to doing a one-to-one management where we're just authenticating locally to our system. It's back-end directory services. So that's the key point. Thank you. So let's look a little bit about what we can deploy today. We're gonna cover predominantly smart cards here today. We're gonna hit just briefly on one-time passwords, but again, mostly on smart cards. So let's look at smart cards in Mac OS X.

There's a, as I would say here, a typical PKI-based smart card, and I put in quotes typical because many of the deployments, many of the installations have really kind of picked their own form of a profile or environment, and what is the contents of those smart cards. And this is a typical example, really, of a card that is implemented with an identity, both the certificate and the private key, of course, and then for email signing and email encryption. And really what you have then is, in this case, is six items, certificates and the associated private key. Again, protection with a PIN is for protecting that private data. So most people, when they fear the loss of a smart card, what's going to happen if someone can get that? That PIN, that protection of access to that private data, is what prevents folks from gaining access to your keys and all in that case. So smart card uses in Mac OS X. There's been a lot of folks that are unfamiliar with what capabilities are built into OS X with smart cards. First of all, there's login. You can enable smart card login in 10.4, and we've done a tremendous amount of work to make that just take place in Leopard. Login is the first place. Many folks start with that, and then they move into a place of system administration.

If I'm going to control access to administering my machine, changing system settings, It's the authentication and then accessing the authorization rights for those of you that attended one of the previous sessions. Screen saver. Unlocking screen saver. You step away from your machine. You come back. You're going to unlock the screen.

Web access. Secure web access for client-side authentication. We've had server-side for quite some time. Now with smart cards built into the services, you can do that client-side authentication. There's many folks that are implementing web access controls and services like that that are now requiring that. VPN. Whether you're doing layer-to-tunneling, point-to-point, whatever, you're now wanting to use that same solution. Remember that single sign-on approach. And finally, we'll look a little bit at mail. Mail, typically, is we're looking at SMIME, and it's really more from a service standpoint and less from a two-factor authentication piece. But again, we wanted to cover this with smart cards.

So what did Apple really do to make this all possible? And that is that we, as we'll show going through this session, smart cards really become key chains. And you're all familiar, or should be familiar, with key chains and how that's implemented in OS X. But that's really kind of the key message you should take away. The simplicity of integrating smart cards into the OS as key chains really is what makes a lot of this possible. So let's go through each one of those items. Smart card login. You've got the potential of using a particular smart card to physically log into the local machine, to log into an LDAP server, to log into Active Directory, to log into-- you name the directory service of choice that you've configured on your system.

But there are a couple different ways of setting up that login, different approaches that people need to take or have taken in the past. And these two methods I've referred to as a cryptographic data exchange and also an attribute matching, just to differentiate to clear that up for you. And we want to just walk you through these and let you see what the differences or the different approaches that these provide to see whether that fits into your environment.

The first one gives you the ability of doing a match or the use of an associated public key hash. What it really is doing is allowing you to map a certificate and a private key that's on that card to use that as your identity. Then you'll end up doing a full cryptographic login. But the first method here allows you to add that to the record, the user's record, in your directory service. There are some environments. This would be typical for doing it locally for net info, adding it to an LDAP server. And then there are some other environments that we've mentioned in some previous sessions. For instance, with Active Directory plugin, if you're utilizing our built-in plugin, authentication authority is done on the fly. So that approach wouldn't work in that environment.

The second method is the ability of doing attribute matching. This is where you can pick certain attributes from-- and this came historically from support for some of these services that were required within the federal government. So they were drawing attributes from the email certificate. In this case, the typical scenario that was being used within the federal government is drawing the NT principal name from the email cert and mapping that to or doing the lookup in the directory service In this case, the attribute name was userPrincipleName. All that is is just identifying what the user is, or who that user is, that's attempting to log in. It's not doing the login yet. It's just identifying. It then requires the pin unlocked to access that private key.

So now let's look at system administration. Many of you have seen the dialogue. You're getting ready to use your username and password. But recall, again, if you've attended some of the other sessions, the associated rights that are required for those various locations or various settings within system preference. Three of them in particular are the broad system preferences, those for accessibility, and then those for the accounts. And if you've done the enablement with smart cards and you have a smart card inserted, that dialog will then switch and display the PIN, realizing that indeed this is the user that you're wanting to authenticate with and asking for the PIN to unlock that card. We're gonna do a little bit of a demo a little bit later.

Okay? We talk a lot about authorization. It's been mentioned briefly here real quick in this session and quite frequently in some of the other sessions. Just wanted to run through this real quick to be sure those of you that are unfamiliar with this get a little bit more comfortable with what's happening here. You've got the application that needs access to a write, needs to take an action. So it's going to request a write from the security server. The first thing the security server does is queries, essentially does lookups, does kind of an analysis of how those policies are set. That would be an Etsy authorization.

Once it has that information, if necessary, it's doing the UI to the user to gather the appropriate information. In the case of a smart card, it may be asking for the pin. In the case of biometrics, it may be getting a fingerprint or a facial recognition. That's all kind of an independent, out of band communication with that user, with that process in some cases maybe, to gather the appropriate authentication to prove who they are.

Once that's accomplished, results sent back to security server, security server grants that right to the application. In this case, we were just talking about system preferences would then grant access for that user into that service. So I had mentioned before that we had made this available in 10.4 and we're really making it simple and leopard modifications already there.

If you're on 10.4 today and you want to enable these services specifically for login, you're going to need to do some minor modifications. And if you look at the authorization for the right-- that's named System Login Console-- what you'll end up seeing is this kind of blurb. You actually see the mechanisms. And by color coding there, the orange colors, those are the lines that you need to insert. Those are additional lines. The red line is actually a removal.

There are some ways of generating this once and creating a diff file and applying it to other machines. You can do a manual modification as well. That would give you now the ability-- remember, this is a write for system login console-- to authenticate. This would now do the enablement and actually use, as you see there, Smart Card Sniffer, which then identifies that a smart card has been inserted, and do that as the authentication.

In conjunction with that, you have the rule. Associated with that is your need to authenticate. So just as we did with the write, we need to modify that to enable the use of smart cards. Again, this is on 10.4. And on 10.5, this is done for you ahead of time.

Smart card sniffer, again, we're adding that in the authenticate with privileged. We're adding that, and we're removing the auth internal. So it's for the write and the rule. That's now giving you that ability for authenticating with smart cards for login, system administration. Any dialogue where you're normally going to do that authentication now has the ability to recognize and leverage that smart card. Then there are other services we talked about. Web access. You need to do client-side authentication.

Those of you that have been using Safari, you go to a secure website. You see the little lock in the upper right-hand corner. What ends up happening is you roll over that with your cursor. What that does is that brings up the certificate and the chain that's being passed back from that server. So in this case, this is a U.S. Army website. I can now look at each individual certificate in that chain path, the server cert itself all the way back to the trusted root. And you'll see there, this one indicates that this certificate is valid. We've now validated that according to the preference setting in our certificate revocation that we'll get to a little bit later. So you can walk back through and check the validity of each cert all the way back to the root. And again, we're looking at it from the server side. But what about the client side? So we've got a certificate, whether it's on a smart card or available in a key chain.

You go through the process and essentially you're going to get that challenge. You're going to end up needing to provide access to your identity. In this case, the system is going to automatically provide the first identity that's found in your system. And in some of the recent builds of 10.4, what we did is we elevated kind of the priority of smart cards. So they now appear first in the list. So they're going to be searched first for those identities.

You'd end up having to unlock if it's not already there with your pin, and then you'd be granted access if that right is accepted. But many of us have a growing either a demand or condition that we have multiple identities. How do you handle that situation and still kind of retain the zero configuration environment?

So what we've done at Apple is you follow that same procedure. You're hitting a secure website. You're needing to have the system kind of transparently, behind the scenes, deliver the first identity found. But in this case, it may not be the identity that's accepted in the server. So what ends up happening is it gets rejected. You then get presented with the list of remaining identities that you have available to you in your remaining keychains or maybe even additional smart cards. And then once you select that the first time, we end up sending a hint, setting a hint in your key chain. We refer to it as identity preference. We'll see a quick shot of that in a second. And the next time you hit that secure website, it's always going to use that identity that you've pointed out. So let's take a look at that. What would that look like? I've hit the site, it didn't accept the first one I sent, and now it says here's a list of a whole bunch of them that I have. In this case you see that actually the first one is not even valid anymore. It probably expired in this case. And I could select another one. So the hint that I'm referring to ends up being this identity preference that's added to Keychain. So again, this kind of gives you the whole setup of the zero configuration, where if I only had one identity, I'd never see this. If I have multiple, set it once, done.

Okay. Next service. We've gone system administration, login we started with and we went into web, VPN. A lot of you have some remote access telecommuting needs, whether it's even inside of some of the facilities. A lot of folks will do, set up some wireless networks and require VPN access back in. How do we tie that in with two-factor authentication?

So with remote access, typical approaches are layer 2 tunneling. We provide L2TP over IPSec and then point-to-point tunneling protocol. And there's many more of you now that are looking to or relying on 802.1x, again, for access control there. So let's take a peek on those. Just to make sure that people are aware of how this process flows, let's take a look at a standard layer 2 tunneling protocol over IPSec connection for establishing a VPN. The client is really going to make that request, and the VPN server here could be a concentrator, could be whatever your implementation is here. It's going to do that request, typically through either your enterprise wireless network or through the Internet, maybe broadband connection at a hotel.

And the server is then going to provide that challenge back to the client and request authentication using EAP TLS. So this is where your certificate comes in. Well, then the client is going to pass that back to that concentrator, the VPN server. And in this case, there's really kind of a pass-through. That VPN server would really be set up in e-proxy mode and really pass that TLS transaction, the whole certificate, to the authentication server. In many cases, some folks might have a Windows IES server for this.

And that authentication server would then do its validation of the cert, make sure it hasn't been revoked, checking on the user, all that validation. It comes back to the concentrator VPN server. That was successful. The user's in, all based on the certificate, in this case, that we had selected on the card. Keep in mind here that all of these services log in with VPN, with system administration. If I have the card unlocked, if I've logged into my machine and I've unlocked the card, if the service doesn't require me to enter a pin to unlock the access again to that card, I will no longer need to enter the pin again when I get to the next service. So if I just logged in my laptop and I need to gain VPN access maybe out here in the hall, I wouldn't have to enter my pin again at this time. Makes it very easy, again, getting back to that zero-- I should say, single sign-on kind of environment.

So just to be sure you're aware of how to do this within the configuration of Internet Connect, of course, you'd be selecting layer 2 tunneling protocol. And in the configuration itself, you What you're doing now is for user authentication in that upper left, you're selecting certificate. And what you'll get is that dialogue you see on the right, and it will show a list of all the certificates that are valid for that usage, whether it's a certificate or an identity that's in my file-based key chain or if it's in my smart card.

Now, associated with that, this is really not from the user authentication level, but some folks are really looking into also doing the authentication on the machine level. So, again, this is a little bit separate. I just wanted to bring it up here. You'll see machine authentication at the bottom has the ability of using certificates as well. And that's where you need to have that in your system keychain. Remember, there's several keychains that are managed by the OS rather than being user-specific keychains. If you don't have one in there, you end up being told that you don't have an appropriate machine certificate that's available. Again, you need that in your system keychain.

The same goes for the other approaches that most people are going to have here, again, with BPTP. Same use, selecting certificates, whether they're on a keychain or on a smart card. Of course, with 802.1X as well, setting up for TLS, and selection either in file-based or on smart cards.

So for mail, there's just some points I wanted to be sure that you're all aware of. So I'm composing an email message here. And I see that there's a little check mark there. That actually indicates that I have an appropriate identity that's available in one of my key chains that maps to the account I'm sending from. And a little bit of verification there. I'm looking in one of my key chains, and I have the identity, the private key in the certificate.

But one thing that seems to have gotten some folks is look close And the key is that that has to be the same email address. It has to be the same case sensitivity. Okay, and there's a lot of folks that have done some various configurations or various entries, capitals, lowercase, and they couldn't figure out why it wasn't coming up in mail. The key is case sensitivity, really everything to the left of the @ symbol there. So that's for me. But if I'm setting this up to send to somebody, Joe user, I'm going to send to him. If I actually have the public cert for that individual, then that kind of grayed out lock then becomes available for me, indicating that I do have a certificate to send an encrypted message to that user. I'm always using a key from their public cert. So let's take a look at some of those in action here on the machine. First of all, keychain access. That's where all of this starts. I had mentioned early on that you've got the various keychains.

And right here, you see that I've got one of my smart cards inserted in one of my USB readers. We're gonna talk about some of the hardware environments and support for things. So there's the six items that I had mentioned. Here is the identity and e-mail certificates and their associated private keys.

Again, this is a key chain. So any application that's leveraging the security APIs within the OS now can utilize my smart card without having to deal with the interaction of the card itself. So let's look real quick on what happens at the login window environment when I have a smart card. It's real quickly here that it still shows me with my name, because that's the account associated with this. But now it's asking me for a pin, because I've got the card available. In this case, I left it in here. It's ready to go.

Do my corresponding pin. I'm logged in. Again, it does that challenge in mapping with the account. Well, the same thing we mentioned was with system preferences. If I'm going to do some alterations, let's say with my accounts, I'm going to unlock. Same thing with dialogues. Now I'm being asked for the right drop this down. That was one of those rights that we looked at, System Preferences Accounts, is now available to use with smart cards.

Okay, so if I enter my same PIN, Now I can do my standard modifications to my system. Do all the screen lock. If I go ahead and lock my screen. Let's also look at Safari. Again, just kind of a quick representation of some of those services that we've just spoken about.

So let's go to a couple of the sites here, and I'll just pull up the AKO site that you saw in my slide. Here's where you see upper right hand corner, you see the lock. If I click on that, here's that whole scenario of the certificate from the server. So in real time, we are looking at that particular certificate, validating it, doing the whole trust path all the way back to root.

If I proceed, then I'm going to be challenged and need to require the access to my smart card. And if I go to another one of these, Again, all of these, every single one, same scenario, is going to do that validation. So before I continue with this, let's look at where that-- those settings are. I'm going to be bringing this up in slides a little bit later.

but we're looking at the certificate revocation validation. We're looking at CRL and OCSP. And in many cases, most of you will want to set things to best attempt. It means that when you've got that network access and most recently have been able to cache that in the case of CRL, you still can validate that certain continue of the process. If I required it and I didn't have network access, that certificate or that identity would have been marked as being invalid. I wouldn't continue with that. Okay?

So again, with Safari, with internet access. Quickly just bringing up the VPN side, the scenario that we just mentioned, we went through the screenshots on. Here's where I'm selecting a certificate. Now what you see is that is that representation of my smart card that I have inserted in my reader. And I can go ahead and proceed to kind of interrogate or look at that certificate that's physically on that card.

Under the hood, for those of you who are interested in this, you see right here, I highlighted. That's one of those token D's that we're going to talk about. And that's the associated process that's communicating with that card and doing that propagation of that all the way up through to keychain. So again, we can get into the mail process, but I think at this point with time, let's move on a little bit further and go back to slides.

So let's look at-- I've been showing you some of the services within the OS, and I've really been using smart cards that are supported within the OS. Again, if you attended the session 4.16, it got into the various tokens support for smart cards that are built in. That'd be the US federal government smart card, Belgian card, and with the Japanese card.

these three, are built-in support within the OS. Okay, that means that if you are in an environment where you're using a card that meets this specification, we already have the software available, the device support, in this case, for those particular smart cards. So the other component is the readers. A lot of people have had questions.

I get mail messages every day asking what reader works, what reader doesn't. The key one to be looking at if you haven't got into smart card reader purchases just yet is be looking for CCID compliant readers. It's kind of the closest thing you'll get to kind of a standard across the board on smart card readers. We have a CCID class driver in the OS to support those readers, no need for additional drivers. We've got several proprietary implementations of PCMCIA, USB, USB dongle readers support as well. But those can change between versions going forward and looking back at previous revs of the OS. So again, the suggestion is continue to move towards CCID compliant readers.

As I had mentioned with these readers, we've got the support, but many of you may have your own devices that you need to start looking at support, bringing on over to OS X. And a good resource for some of the PCSC drivers available for a lot of the kind of legacy readers that have been out there is LinuxNet.com for source drivers. We'll give you a good start. Open source drivers available. Okay?

So now what I want to do is ask Krishnan from Genentech to come up and just spend a couple moments with me here to give you a little bit idea of how some of the folks in the private sector are leveraging the built-in smart card services within OS X.

Hello, good morning, everyone. I'm Krishnan Chalakrai, senior security engineer at Genentech. Today, I wanted to share some of our expectations for our smart card projects, our experiences, and our lessons learned during the project. So when we started off the project late last year, our initial goal was to combine the physical and logical access together.

So for our users, they'll use one batch to enter into the building, and they'll use the same batch to access any other corporate network and resources. And our second goal was to reduce and eliminate the multiple passwords that they have been using today to access either any of the web applications or when they do remote access or VPN. VPN, they have a different PIN or passcode depending on the factor that they use. So we want to reduce that as well. And the third important goal was to have a simple and easy user experience. So most of the users, actually, they use laptops the carrier on between meetings. So if you provide them kind of a USB readers versus a PCMCA readers, we wanted to have a very easy, simple user experience for them. During the project, some of our experience was we felt in order to have a seamless and tighter integration between physical and logical access together, if we have one vendor for both physical and logical access, it would make it a lot of easier to have this seamless transition, which will integrate into the existing card management system that's been provided by a physical access vendor and with all our logical solutions that Sean was demoing us before. And second other thing that we initially started off with the POC with 30 users. During the POC, we provided smart card for users to use for login. We asked them to use smart cards for VPN and also for web applications. And then so when the users were using SmartCard, they were able to use it for user authentications against LDAP servers, again, Cisco VPN servers, and for web applications that's been used in Genentech. Our key lessons learned during this process-- implementing SmartCards requires a lot of integration work. So it's always best to involve professional services from Apple, from other solution vendors that's part of your enterprise that you're trying to use smart card with. So it'll make life a lot easier for you to use smart cards. And I wanted to mention that for our-- as Sean was mentioning earlier about the token D interfaces, so we use Siemens. So Siemens developed a token D interface for us, which make it useful for login purposes.

And critical and foremost for our success is to involve a lot of subject matter experts from different vendors so that it can get the expertise and it can leverage that expertise already so that it makes life easier for your deployment. And the last point was Apple Innovations is introducing a lot of new opportunities for us, also basically for other smart card vendors, and a new way of doing things with smart card so that it makes life easy for the users. Please join me in thanking Krishna. Thanks. Thank you.

OK, so we talked a little bit about tying in to other directory services. So this kind of gives you that view that you're facing on a daily basis. How would I use that smart card into whatever back end solution I have? Now, first of all, just to kind of better understand the architecture here, look at the whole abstraction layer with smart cards. We've got the login.

They're on top of our directory services APIs. And some of you may have seen this again in session 4.16 as well. And then below, you've got all your directory access. So when I did my login here, I happened to be logging into a local account on my laptop. But that could have been any of our directory services, any access to an LDAP server or whatever in the back end. And that process is really that look up. Remember we talked about kind of the matching, either with public key hash or the attribute matching.

So let's look exactly how you would do that. I kind of showed you, but let's walk through each one of these. Within the authentication authority in an account, you typically had the shadow hash you see there at the bottom with the authentication authority. And when you use the new command related to smart cards, seauth, you will then be adding the public key hash, or one of, those from the card that you have in this case. That then does that association between the card account. So again, the command is seauth. You've got the ability now of setting it up for accepting that card for that account, removing those, or just physically printing out the hashes for your use here of identifying which hash is identifying the identity key, in this case, email signing and encryption.

There really isn't a requirement of which one you use. In some cases, some folks may particularly focus on maybe the email signing cert. As I mentioned earlier, that's a focus within the government. But with respect to associating this account, it doesn't matter which one of those you use. So if I'm going to bind or link this card to my account, I'm going to do the scauth, accept, designate my user, and dash h to indicate my hash. And again, in this case, I'm actually picking that first one.

But any of these could be used, and I could also have multiple entries. Many of you might know that we all kind of come to work, and we may have our badges, or we may forget our badges. So you may issue a temporary badge, or you may have multiple cards, or the need for multiple individuals to get to a particular account. In this case, with this method, you can add multiple public key hashes to any given account, giving you the ability to log in to that account with multiple cards. So here I'm really just looking at the authentication authority attribute value using DSCL for my local. The bottom there kind of references LDAP, if I'm going to do that.

Okay, just as I mentioned, you can use any of these. You can have multiple cards. So let's look at that attribute matching. Again, within the federal space and even in some cases when some of the commercial space folks that I've been dealing with, they've been wanting to do the attribute matching. It's just another way of doing that lookup for a user. So what we did a few years ago to support some of the requirements within federal space, and that's why you see the CAC, first part of the name of this P-List, is we created an environment where you would be doing, setting up an XML. You would set up that mapping of identification of attributes on a card. You'd be formatting that information and then do that lookup. So let's see what that's like. First of all, the file that you need that isn't there by default is etsy cac login config plist. And when I say it's not there by default, it means that out of the box, we're going to be using the public key hash method unless you create and install this plist.

Okay, this is a typical P list, so it's very short. There's not a whole lot of information in here. The first indicates fields. Those are an array of fields that you're pulling from, and they are the actual attribute name, you're pulling from the email cert on the card. And again, since this is kind of an approach that was drawn from the federal space, there is the drawing from the email cert, and at the moment we don't support any of the other certificates on the card. Then we need to format it. In this case, we're just going to take the value itself. So $1 is we're just going to take that first value. And we need to define what attribute we're looking for in our directory service.

In this case, at the bottom there, you see DSAttributeTypeNative user principal name. I'm now defining that it's a unique attribute that I'm going to map to in one of my directory services. So what would that look like? In the case of actually my card, I think that's the value, or a typical default value. It's going to be a 10-digit number at mil, is the case within the federal space.

So that value is going to be looked at against my directory service, against the attribute value of user principal name. It's then going to find the user associated with that and bring up my login window, much like you saw, asking for a pin. I haven't actually logged in. I'm just doing that association.

And these are just some of the string values and some typical string names and then typical values that you'd find within those attributes in the cart. Again, you can combine that with literals even to generate a longer string or unique information. So we can do mapping. I've been mentioning that this is really predominantly used within the federal space. And I'd like to welcome up Ryan McCrone to give us a little bit of insight as how they're implementing the smart cards within the government space.

Thank you, Sean. My name is Ryan McCrone. I am a contractor working for the US Army, the Advanced Technologies Division. My company is Eaze Technologies. We had three major goals and expectations going into this project. The first was to meet our government mandates, which have been talked about throughout the presentation. The greatest requirement of that was a single federal identity for all forms of access, from building access, federal ID, and computer and network access. Our second goal was tight integration with our Army network. We have a very extensive existing Active Directory system and Kerberos system that needed to be accounted for. We wanted to eliminate all passwords except for the user's PIN. And our third major goal was usability. We wanted to provide a single logon, SMIME and HTTPS, and administration system, an SSO system that was very easy for the user. Some of our experiences. SmartCard does provide a strong two-form factor of identification.

The DoD leads deployment of SmartCards in the U.S. federal government, and Apple does have integration of SmartCard in OS X. However, it didn't meet our minimum requirements, so we went out to a third-party development system of Thursby Software Systems, and they were able to give us the integration that we needed. Unfortunately, the vast majority of the U.S. Army still uses PCs, and we had to learn how to play with them cooperatively. Therefore, we needed to authenticate our users to the Active Directory. We needed to be able to send S-MIME with Entourage 2004 through our Exchange servers, ranging from 2000 to 2003, even up to the new E12 servers. And finally, we needed to be able to have secure web access through Safari to sites like AKO, which was just demonstrated.

Things we learned. When developers and Apple work together, it delivers a product that the customer really needs. We'd like to thank Thursby and Apple for working very tightly with each other and closely with us to develop a program that got most of our requirements done. And we also identified a lot of new requirements along the way. The Army wanted greater control over the individual systems, which we are still working on. And some systems actually need to support two smart cards simultaneously. So when an administrator logs into a machine and needs to perform a higher level command, he has to pop in a second card. Unfortunately, this gives us a new issue where card removal brings up a locked screen, and that is something we are currently working on and hopefully we'll have a solution to soon. Thank you very much, Sean. Join me in thanking Ryan.

So as we're kind of rounding out, we've talked about the use of cards. Again, we're talking about smart cards and kind of a PKI-based two-factor authentication here. And I briefly brought up the preference within Keychain about certificate revocation. And this is that dialogue or the preference panel that you saw. This is where on a system basis here, I'm going to set how I want those certificates, the revocation, the validation of this, really to be set. And in most cases that we found within the user's environments, predominantly in laptops and all, when you're going to be on and off again with the network, setting things up for best attempt is I'm going to get kind of a cache of that last CRL, and if I'm now off the network, I still have the opportunity of having validation of that certificate, even though at the moment I don't have access to that network. If you need the stronger immediate validation at this minute, that's when you end up setting, would be setting this to require for all certs or require if it's indicated, meaning that I need to validate that cert at this very minute rather than looking at the cached contents. It can be done for both OCSB and CRL, and then you can even set the priority of which one would come first. So if it's successful OCSB here, I'm going to go ahead and continue on with that validation.

Those of you that implement this, if you're doing OCSP side, there are the two implementations on the server for OCSP validators from both Tumbleweed and CoreStreet that are OS X server-based, particularly in the government space. These are ones that have even been kind of certified as some of the major vendors there. So you have kind of that end-to-end solution. So as I started out this discussion, we talked very much about that abstraction of smart cards into the keychain environment. So the important takeaway from this is that what you have now is you've got certificates and keys available across the board to applications, regardless of whether it's a file-based or a smart card-based implementation. So in this case, my app's looking for the certs and the keys. You need to go to file-based or to smart cards. But I'm going to typically be using that card for two-factor authentication, so I'm going to have that.

So I had mentioned smart cards. We want to just take a very brief look at one-time passwords. Many of you may have what many of we have as well is other tokens, one-time password tokens. This happens to be a crypto card token. You may have a secure ID token. Those are giving you those one-time passwords. Again, we're trying to solve the problem of the standard what you know of a username and a password and solve that secure and reliable form of identification.

So in this case, how much or where has Apple incorporated the one-time password support built into OS X? And in this case, we really have provided it in the VPN services within the remote access. And if you look closely, within 10.4, you have both the identification of RSA SecureID and with CryptoCard in the VPN settings. So you can use those one-time password tokens right in OS X's Internet Connect.

There is a KBase article that's available to actually set up manually the OS X server to allow it to provide authentication back to a SecureID server. I know we've talked about a RADIUS server being on Leopard. In this case, folks are also looking into doing a little bit of use of SecureID in the back end for that authentication from 10.3 using SecureID tokens. Then, of course, the server administration guides, in this case, network services, go up to server documentations, and you'll find this is a very helpful guide, both in understanding the architecture and step-by-step setup of that service.

So from a standpoint of a complete end-to-end solution, one of the solutions that's available to you today, and has been for literally a year and a half, I believe, is CryptoCard's one-time password. With their solution, you can also add the login with that token. So if you have the RSA secure ID or your CryptoCard token, you can also do the login with a one-time password.

We've been talking an awful lot about smart cards, but you could be doing it as well with a one-time password. And in their case, they do also support the use or the ongoing use of the SecureID tokens as you migrate from one to the other. And the various tokens you see there were smart card form factor, pin pads, and the key fobs.

Just a quick-- this is really kind of an overview showing you what the product is, but it provides you kind of the end-to-end solution for token-based authentication from the client all the way to the server for login, VPN, web. They've got some management tools and some deployment components as well. But that gives you the use of, again, those one-time password tokens on OS X today.

So in summary, we've been going through this discussion of two-factor authentication. We've been going through the use of smart cards, one-time password tokens. Hopefully you're starting to see that this is giving you some options, some good solutions for providing that secure and reliable form of identity. You've got users. Many of you have lots of users. That really, the manageability of knowing for sure that they are who they claim to be is very critical in your day-to-day jobs. And that this is actually going to help you solve the solutions of the two-factor within your enterprise architecture. And hopefully between the session 4.16 and this session, you've actually gotten a really good glimpse both at a high level and down at the API and service level of the support of smart cards that are built in. In this case with the government cards, the Belpick and the Japanese cards. That service is already available shipping out of the box. And with third parties, as Krishnan mentioned, with Siemens, they had their card very quickly supported on the platform. If you've got other developers, other smart card vendors, that you want to use their card in your environment, and they haven't brought it over yet, please encourage them to talk with us to expedite their deployment on OS X.

And hopefully we've covered a fair amount of the scenarios. It's very hard to cover every little situation, but hopefully we've given you a very broad understanding and hit a couple of the points of integrating with some of your network solutions that you're going to face on a regular basis.

And we think that the architecture environment really enables some new solutions that haven't been implemented before. And I don't have the hardware available with me this morning, but by design with the architecture within OS X, with the token environment, and with smart cards specifically here, I could go much further than just having my single smart card. I could have the situation, much like Ryan had mentioned, with a need for two smart cards. I can literally have additional smart cards added to my system, and my applications don't need to manage that. It's a very significant difference architecturally than other platforms.

So in this case, with a little bit more information, standard location for content up on the WWDC website, I think we're going to try to include in an additional document some of the slides that we needed to remove just due to time because things got shortened a little bit here.

And from a contact standpoint, if you're a developer, key contact is Craig Keithley that covers all the security technology evangelism here. And I included my information because an assortment of you all in various environments, whether it's enterprise or in the government space, either need some additional guidance or direct working. And so my contact information is available to you as such. you