Welcome. Smart cards and other two-factor authentication sessions. My name is Shawn Geddis, 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. HSP D12 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 Yeager 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, kind of a one factor. It's something you know, right? 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, it's kind of a, here, serving as a visible or tangible representation of something abstract, right? 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 our 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 in directory services. So that's the key point. So let's look a little bit about what we can deploy today. We're going to cover predominantly smart cards here today. We're going to 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. The capabilities are built into OS X with smart cards. First of all, there's login. You can enable smart card login in X.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. 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-two 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 kind of 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 it'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 in to the local machine, to log in to an LDAP server, to log in to Active Directory, to log in to--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 kind of referred to as kind of a cryptographic data exchange and also kind of an attribute matching, just to kind of differentiate to clear that up for you.

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 a server.

You could have a server that's a server that's a local server, 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 against-- 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 dialogue 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 going to do a little bit of a demo a little bit later.

We talk a lot about authorization. It's been mentioned briefly here real quick in this session and quite frequently in several 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 were 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, So, what you'll end up seeing is this kind of blurb, right? You actually see the mechanisms. And by color coding there, the orange colors are -- those are the lines that you need to insert. Okay, 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 right 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 in 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 system.

And then once you hit that keychain, 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 -- I'm going to go ahead and hit the keychain. And then once I hit that keychain, we refer to it as identity preference. this identity preference that's added to Keychain. Okay, 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 two 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 two 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. Okay, 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 set up, 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, or I should say single sign-on kind of environment.

So just to be sure you're aware of how to do this within the dialogue of Internet Connect or the configuration of Internet Connect, of course you'd be selecting Layer 2 Tunneling Protocol, and in the configuration itself, 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 are 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 and 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 going to 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 email 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. You notice 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-- dropped this down. That was one of those rights that we looked at. System Preferences Accounts is now available to use with smart cards.

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,

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 Ds 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 416, 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. 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 the 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.

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.

Okay, 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 416 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 lookup. 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 and the 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 seauth, 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.

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 DS attribute type native 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 card. 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 to how they're implementing the smart cards within the government space.

Thank you, Shawn. My name is Ryan McCrone. I am a contractor working for the U.S. Army, the Advanced Technologies Division. My company is Ease 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: Smart Card does provide a strong two-form factor of identification. The DoD leads deployment of Smart Cards in the U.S. federal government, and Apple does have integration of Smart Card 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 SMIME with Entourage 2004 through our Exchange servers, ranging from 2000 to 2003, even up to 2000. We needed to be able to send SMIME with Entourage 2004 through our Exchange servers, ranging from 2000 to 2003, even up to 2000.

We needed to be able to send SMIME with Entourage 2004 through our Exchange servers, ranging from 2000 to 2003, even up to 2000. 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, Shawn. Join me in thanking Ryan.

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 Secure ID 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 secure ID 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 secure ID in the back end for that authentication from 10.3 using secure ID 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 Secure ID 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 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, and 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.