Hello, everyone. My name is John Wright. I'm from Core OS Software Engineering. My team is responsible for a lot of the base functionality on the iPhone OS, including networking and data security. As such, we've been kind of integral in a lot of the features that are targeted toward the enterprise on the iPhone. Today, I wanna go over some of those features and then talk to you a little bit about how you can use the iPhone in your enterprise environment.

So the iPhone is gaining a lot of traction in enterprise. From hospitals to media companies, to law firms, people are using the iPhone as a new mobile business platform. In fact, in November of this past year, J.D. Power and Associates in their survey of top smartphone, business smartphone devices got the top honor.

So, I'm going to break this session up into three different sections. First, I'm going to talk about integrating into your existing corporate infrastructure. We're going to talk a little bit about deploying the iPhone to your users and then we're going to talk a little bit about developing unique applications for the iPhone.

So let's start with integration. Now, the iPhone integrates in very well with the corporate services that you have in your enterprise. This includes email, calendar, and contacts and networking services such as VPN and secure Wi-Fi, and of course Microsoft Exchange. We continue to update our support for Microsoft Exchange.

We support Exchange Server 2003 and 2007. And since iPhone OS 2.0, we've been supporting push email, calendar and contacts and access to the GAL. Of course, Exchange isn't just about those services, they're also about administration on the device. And so, we also support passcode policies and auto-discovery of the servers on your infrastructure by just putting in the user's user name and account information. And Exchange also has a feature for remote wipe. And this is great because your users can come to you if their iPhone is lost or stolen and using one of the number of interfaces into Exchange, you can have that data securely wiped off that device remotely.

Now, what's new for Exchange and iPhone OS 3.0? First, we're supporting certificates as a means of authentication. Now we'll talk about certificates later in the program, but one of the key benefits of certificates is that they can be tied to the device and not the user, and that gives the IT department a little bit more control over these devices. We've also enhanced our policy support, including passcode policies and IT administration policies.

And we're supporting additional Exchange features such as searching for messages on the server, creating and responding to calendar invites, and push email directly to subfolders. Now, this is a typical Microsoft Exchange deployment. You have your Microsoft Exchange frontend that's hooked up to one or several backends depending on how big your deployment is. And you have your directory services, usually Microsoft Active Directory.

Now, what most customers do is they deploy a Microsoft ISA Server into their DMZ or some other kind of proxy server and put a hole through their firewall, that's a secure SSL tunnel so that users can access all these services from outside the firewall. And this works just like any other Exchange deployment. So if you've already done this for your users, the iPhone will just work on this infrastructure. And new for iPhone 3.0 is you can also integrate in your certificate server for authentication.

Now, not everyone uses Microsoft Exchange and so we try to integrate in with all the different open standards. So for mail we use IMAP and POP. And new for 3.0, we have CalDAV as a calendaring server protocol. And now you can deploy any of the number of CalDAV calendaring servers including iCal server and Oracle Beehive. Also for 3.0, we support LDAP. Now this supports lookups of address information directly in mail, contacts, and SMS.

Now, we also integrate into your corporate network infrastructure. The iPhone supports Cisco IPSec, L2TP and PTPP for VPN access, and this access is built right into the iPhone. There's no need for extra software. And for authentication, we can use digital certificates, we can use hardware tokens, since there's a CRYPTOCard or secure ID, and of course we can use login and password.

And new for 3.0, we have a new feature called VPN on demand which makes VPN seamless to your users. And also a highly requested feature is proxy support for VPN, and that can be configured right in your settings. So VPN on demand, VPN on demand is all about the user experience. We try to create a user experience where the user doesn't even have to know anything about VPN.

Now, we did this by using certificate based authentication. And the reason this is beneficial is because if there's a certificate provisioned on the device, that device can run all the VPN things it needs in the background to access services like mail and calendar. Now it's based on the address domains of your corporate network. So the network stack actually detects whether you're going to the corporate network and automatically starts up the VPN tunnel.

And the big benefits of this is that it not only works just for mail and calendaring, but it works for any network-based application including those from the iTunes store. Now, the iPhone is all about wireless access and in most enterprises that means some kind of secure Wi-Fi access, and we support all the common protocols including WPA2 Enterprise. We also support 8O211, 802.1x authentication including all the EAP, LEAP and PEAP standards.

And new for 3.0, we have support for captive networks. And what this does is it detects whether you're on a network that can't actually access the internet, and it brings up a web sheet so that your users can see the information about that hotspot. And this works in hotels, in coffee shops all around the world. So, when your users travel, they can get on the network more easily.

So, to talk a little bit about integrating into large deployments of iPhone, I'd like to invite Duncan Keefe of Apple's IS&T Department.

I've been at Apple 8 years and it has been an interesting ride when you consider that 8 years ago was just after we started seeing Mac OS X on the front lines at Apple, and we had a little bit of-- a lot of people just prior to when I started had just switched over from many, many years of classic Mac OS and we're sitting here, we had-- apparently we had a little resistance to some of this, you know.

Some of these people were, "You're going to take my Mac OS 7 out of my cold dead hands." But Mac OS X has had two profound effects on Apple internally. One is that it has actually made our support operations a lot easier, and so we have transitioned a lot of our support operations from a much more kind of hands-on approach to a much more self-service approach. So our end-users are sitting here getting a lot of, getting a lot of information off of our intranet and not so much out of calling the helpdesk all the time.

And so I could give you a lot of examples, but probably one of the best examples was actually when we had to hand out iPhones. So, let me take you back to when we actually originally announced the original iPhone. So, Steve Jobs announces the original iPhone and this is obviously very, had a little bit of effect in the press.

And then a few days later, he calls a company meeting and says this is why we're getting into the business, this is what it means to us and, oh, by the way everybody is getting a free top of the line iPhone, pandemonium ensues. About 30 seconds later, my own personal pandemonium subsided because I thought of myself, "Who's going to hand out all those phones? Oh right, me." So bear in mind also, no one had seen one of these before.

Most of these-- most people had not seen one even within Apple. Yes, we do keep this stuff confidential even inside the company.

And so it was a new interface paradigm to everybody. So, the other thing I remember is that not everybody at Apple is an engineer. We have people in HR and Legal and Marketing and what have you, that may not be as quite as technical as all that.

So we had to teach everybody the new interface paradigms because they didn't know how to get on to mail, they didn't know how to get on VPN and also all of these beautiful self-service provisioning profiles and all this other stuff that's come out since didn't exist at the time, so it was, we're going to have to tell you how to do this and you're going to have to do it yourself because I'm not going to do this for 14,000 phones.

Just personally speaking I don't have the staff. So we got an email from Steve a couple of days later and he says I don't care how you do it, but I don't want to see any lines and it all needs to happen in one day.

Yeah, 14,000 phones in one day, got it.

So, we kicked it around and got all the legal and financial, you know, 'cause it's a gift, you have to do tax offsets and all that fun stuff, all that stuff worked out. And so what we decided to do was first we did a thing where we got these little USB devices that plug in and will read your badge and compare it to a database. So we, actually use those at all of our sites for printing out guest badges. That way, somebody can't just walk over and print out a guest badge, you have to have an employee come in and swipe their badge to activate the printer.

So we borrowed those from Security and that solved the problem of getting people through the lines quickly, but the other thing was we told the people who were handing out the phones, you are not going to answer any questions. You're simply going to hand them the phone and hand them a piece of paper and the piece of paper had the obligatory legal boilerplate. Legal has to prove that they have, they had some effect on every process, I think. And I say this with love because I've got lawyers in the family. And a big fat URL that said IS&T web which is our IT department's intranet/iPhone.

And that was it, they were told no questions, just hand them the phone and hand the piece of paper that says all your answers are there. So the helpdesk of course was sitting here going, "Oh my god 14,000 phones in one day, what are we going to do, we're going to die, we're going to be-- " So we worked-- they cancelled vacations, they got in contractors, they just, you know, everyone was on deck. They thought they were going to get crushed.

Well, what happened was, you know, it starts out a little quietly and everything's fine and then people start showing up and, you know, they're happy, they get their phones. And this is across the company and everybody got one. And as you can see here, one of the guys in the lower middle of the shot, here is one of the guys from the cafeteria staff.

So, most cafeteria staff are not noted for their technical depth, so obviously they had to do, you know, use the same services that everybody else did on our intranet. So, the helpdesk it turned out they had a spike alright, but they didn't get crushed at all because people were getting the answers they needed off the intranet. Another thing, if you're an IT person, you're probably accustomed to not getting too much in the way of gratitude from your end-users.

You know their attitude is, yeah, I got on the network today and the sun came up too, so what. We got a ton of email from people saying, "I expected this to be a pain, I didn't know what I was doing, you guys walked me through it, this is fantastic." You know, and that's the thing, you know, this is not special to Apple or anything like that.

People actually took the time to tell us something nice, which is great. So, this is obviously a testament to the ease of use of the iPhone, I mean you know shallow learning curve, but it also you know you can do that sort of self-service approach and it can be very successful and obviously we've done that for quite some time because we did it from day one until now. So, this is a screenshot of the site at the time. We had to walk people also through things like changing their accounts and so on, and what you can't see is what's below the fold which is things about mail and so on.

But, this is how we do support. This is the primary vehicle. We tell people from the day they start as part of our onboarding process, go here because your questions are all answered here, it will save you some time from going to the helpdesk. And of course technical people, they don't want to call the helpdesk.

They are, in some cases they know more than the helpdesk guy, so what they want to do is they just want to say, "What do I plug into these fields to make it work and I'll figure it out from there?" So, that gives you a shot of how we deploy stuff. So, what I'm going to talk about now is how we integrated some of this stuff into our corporate services and how we're continuing to do that.

So the primary ones are mail, calendaring and VPN, may come to you as no surprise that we don't run Exchange within Apple. It's not a slam on Microsoft, it's just that you know long ago we decided open standards is the way to go. And Apple, Apple was one of the first-- if you look up the history of domain name registrations, actually Apple is something like number 34 domain name ever registered or something like that. So, you sort of get the sense.

We've been on the internet and as an IT organization we've been kind of embracing open standards for a long time. So, we just recently actually completed a switch over to iCal for all of our calendar users in the company, and so we wanted to actually bridge that. I heard somebody applaud.

Whoever you are, I love you. And there's nothing like getting a lot of-- because we actually just moved all the data from our old calendaring system. So, just give you an idea. I'm gonna talk generically because this is, I wanted to relate this to things that you can do in your own environment.

So, it was very simple. We've had the mail, you know, since day one as I said when we started handing out the original iPhones. So you have a proxy server, and this could be a proxy server from any one of a variety of solutions you could have. You know Citrix has one, Barracuda has one.

There are some more well-known names and there are less well-known names like Imperva and so on. So you want a web application firewall. In most cases, that's another way of going about it. And you just punch, you know, the standard holes that you would expect into your firewall, use SSL. This is obviously a well known and well regarded method.

And it will talk to your IMAP server and so on. For VPN, and as I said we've been doing this for a long time, so obviously we're pretty happy about it and obviously security is kind of a big deal here. We've got a lot of people who are sort of rattling the virtual doorknobs, if you will, of our network perimeter and so we've always got to keep that bolted down.

Mr. Jobs would be quite upset with us if anybody got in. So VPN, obviously again, pretty much the same things you would expect. You have a VPN server that handles, you know, the initial connection, then it checks with the authentication server and goes on and, you know, it grants access. What is new obviously is the certificate based VPN, so you add in a certificate server and that completes that picture.

And you can-- well, you can use the hardware token, the two factor token, but we are to our end-user's infinite delight, phasing all of that out, we've recently phased it out on our Macs and now we are getting, we are going to be able to get rid of it for the phone.

So, everybody just gets that and obviously VPN on demand will. Something we're very interested in. So integration gets you started because that gets you access to the sort of fundamental core services that everybody wants, mail, calendaring and so on. But then we've gone on from there and added various, started with simple web apps like Directory.

Directory was an interesting story because we had to-- we were developing-- deploying this because we thought, you know, people would want it before you know, technically before you know this was something that was ready to go. And somebody showed it to Steve Jobs and he said, "Oh hey, I'd like to, I'd like to demo this." This was awhile back. And we had 6 weeks left to do this and the demo that he was going to use was two and a half weeks out.

So, we went into frantic development mode and created all the, you know, created a whole bunch of fake entries and so forth. And so I'm sitting here 'cause I'm not a developer. I, you know, let the developers do their thing, so I said, "Well I'll make up all the names and go grab some faces from the graphics people and so on, for the directory." I'm not good at making up names it turns out.

So I'm sitting here finally I'm making up names and I'm finally like, okay, people used to work with, oh yeah. So, right after Steve demos it, I got 3 emails and 2 phone calls from people I used to work with. "Was that my name on the screen behind Steve?" [Laughter] "Yeah." "You owe me a beer." [Laughter] So, I started with Directory and Directory lets you do all the obvious stuff. And bear in mind, none of the tools that you have now existed then.

We were measuring pixels to make it look like a native app, because we didn't have anything else. I mean seriously, I'm watching people, you know, in Photoshop counting pixels. But you tap on the phone number, it dials the number. You tap on the email, it creates a new email message.

And you tap on the location for the building and it call-- it switches views and calls up a map and so on and so forth, the usual stuff.

Then we get into things like business approvals for purchase requests, vacation requests, you know, things like that. And then we get into sort of more business intelligence for executives, various, you know, dashboards, things like that.

And now we're getting into native apps actually for the first time in places-- For example the first one we did was for retail, for handling a lot of the customer appointments. So, we deploy this all over the company, in all variety of ways and up to this point, it's actually all been web stuff.

And so, you can see this is obviously very transformative because we're able to deploy a lot of information that's previously required people to log in with the laptop and haul a laptop around if they wanted to get at it. Needless to say, executives love this because they have it at their fingertips.

But, it isn't-shouldn't just be executives will benefit from it. So, some best practices. Employee self-service is not only something you can get away with, it's something you should embrace because it will make, it will improve your leverage. And by setting some basic rules and investing in the content, this isn't just, you know, point somebody to a web page on apple.com.

This is, think about how much information is specific to how you do business and make sure you communicate that, drive it home with a few emails or some kind, whatever communication you have with your users that they can get the answers there and make sure that you don't deliver the message that, "Oh, I'm giving-- I'm pushing this off on to you," it's more, "Here's how you can help yourself." So the quality of the documentation is key. Editorial voice is key. Do not write your sort of-- one of the things I've always struggled with is a lot of IT people want to think that, you know, they want to communicate, you know their interest in the technology and most users, they don't get it.

You know some of them, you know as far as they're concerned, when they hit send on that email, there's a carrier pigeon running around with a printout of the email clamped in its beak. So, you know, they don't-- they don't know, they don't want to know so just focus on what's going to get them productive and what do they need to know in terms of their business needs. So, you don't need elaborate network services in most case, so authenticated SSL will take care of it.

Certificate VPN, again, will take care of it and, you know, that way you can avoid the need for hardware token if your security needs don't require it for some regulatory or other need. And then as I said, don't stop with just integrating with your core services. Look at all the other services you can provide and you'll find that the development tools will really help you turn these things around quickly. So that's it for me, and so I will hand it back to John.

Thanks, Duncan. So as you can see, the iPhone implements all the standards that allow you to integrate directly into your enterprise infrastructure as it exists today. No need for special services or servers external to your network. So let's-- Oh, so here are some sessions around deploying contact management and calendaring solutions, and there's also a deep dive on 802.1x that I invite you to check out.

So let's turn to deployment. Now, there are few things you have to consider when you think about deployment of iPhone's new enterprise. First, how are these phones going to be activated for cellular service? Which corporate services are they going to need access? And what kind of device policies and restrictions do you want to place on those iPhones before they access your corporate network? And lastly, how do you want to deal with device configuration? Now, there's a-- actually to answer these questions, there's a couple of paths you can take around deployment.

As Duncan talked about, the iPhone is really easy to use, from a user perspective. And it's easy to configure, you know, accounts and preferences right on the phone. So one direction you can take is to give your iPhones out to your users and let them administer their devices.

Just with a few tips, a lot of them do very, very well and I think it's actually a very low overhead solution. Now, if you have a lot of user accounts or you have a lot of policies that you want to implement on the phones, you need to check out configuration profiles. Now we have tools to help you with both of these solutions.

So let's take a look at those. So the first one I want to look at is iTunes. Now, iTunes is a really easy to use UI, and for your users it's very well recognized. They use it at home for all their media and syncing to their iPods. So, they'll be very familiar with this if they have to use this with their corporate phone. Now, there are a few key functions that require iTunes. First is device activation, and also software updates or any in-house app installations are required to go through iTunes.

Now, a lot of the data that they have on their phones is going to be synced with Exchange, but it's really beneficial if they can actually back up their phones to a host computer in case they have to restore later from backup. And new for iPhone 3.0 is the ability to encrypt those backups on the host computer. And that's a great benefit because it really helps prevent data loss off of those host computers.

Now, iTunes and Enterprise, now iTunes uses all the standard installers for both Mac and Windows, and what this really means is it integrates in with desktop management solutions. And we have step by step information on the Enterprise deployment guide online at Apple. You can also configure iTunes into activation-only mode. Now this is very useful if you want to set up a kiosk in your office to just activate a large number of iPhones.

And Enterprise controls. Now, Enterprise controls, really what we usually call those in iTunes is Parental controls, but they really amount to the same thing. And a few examples here that are important to enterprises are the ability to disable network services, such as the iTunes Store or sharing your media libraries over the corporate internet. You can also disable software updates and being able to check for the iTunes version to be downloaded, or for the iPhone OS version.

So, iPhone Configuration Utility or IPCU. Now IPCU is an easy use GUI for making configuration profiles. And it's really set up for IT administrators to be able to configure these profiles and it will provision them directly to a device that's hooked up to that host computer, or you can take those profiles and put them up on the web so your users can download them, or you can send them in email directly to your users.

Now, what's new in the new version of IPCU? First of all we have additional settings, and a lot of these settings reflect all the new account types and new support that we have in iPhone 3.0. We've also implemented some device-side restrictions that you can configure through the configuration profiles. And if you manage tightly the use of your devices, you can also prevent the deletion of profiles off the device.

Now, we deployed a Windows version of IPCU in February of this year, and so now we ship both Mac and Windows versions and they're in complete parity with each other. Also new is the ability to sign and encrypt those profiles, and the important part of that is it ties your account information to your policies, so you can be ensured that those policies are enforced on your devices.

[Applause] So, I want to talk a little bit about configuration profiles. Now, configuration profiles themselves are just XML files, and the great thing about this is they can be edited with a standard XML editor, or integrated into a custom, you know, management solution. And there's a great developer opportunity here to be able to integrate these in to standard device management solutions out there. Now like I said, they contain all the normal settings for all the normal standards that we support on the phone, so Exchange mail accounts, network accounts.

And new for iPhone 3.0, CalDAV accounts and LDAP accounts. Also a new feature is the ability to install web clips directly to your user's device, and these web clips can go off to either a corporate web service or could just point to user documentation so they can do the self-help how-to guides. And also we'd implemented a lot, a set of device-side restrictions.

Now, device-side restrictions, if you take a look at our Parental controls on the device side, they'll look very familiar. But I want to point out one of them explicitly. The last one there is the use of the camera. Now we, we took this request for some of our sensitive corporate environments about disabling the use of the camera. So you can now do that right in the configuration profile.

So also we've enhanced our passcode policies and the credentials that can be used in configuration profiles. So, we implement a flexible set of passcode policies, and there's a lot here and I invite you to take a look at them in the documentation. But I want to talk about one in particular. Now, since we shipped iPhone, we've always had a backup policy around passcodes. And what this is as you enter a wrong passcode, it takes longer and longer to be able to enter the next passcode.

In fact, I think it's at 7 attempts it starts to go to 15 minutes and it goes even beyond that. And this, we implemented this to make it hard for a thief to try to guess your passcode. Well, now we also can set the maximum number of failed attempts. So you can set that maximum number, and when that maximum number is reached, it will actually do a wipe on the device and erase all the data.

So this really helps prevent the loss of data on your users' devices. Now certificates, now certificates are basically a public key and a private key, some information about you and some information about the certificate authority that sign the certificate. Now what they do is they enable secure authentication and communication. So, many enterprises already have certificates used in their enterprise and sometimes they-- what they're using them for is authentication to Exchange or VPN or some other web service.

And you can use these certificates to set up secure SSL communications which is fast becoming the standard way to poke a hole through your firewall for secure communication to outside your internet. So, how do you deploy them? I've already said that, you know, you deploy them in a configuration profile, and just like any configuration profile, you can, you can set them up in that configuration profile and email them out to your users or you can set up a web server and have them downloaded.

And new for iPhone 3.0, we implement a new certificate delivery mechanism called SCEP, and we have a special guest from Cisco to talk a little bit about this new protocol. So Cheryl Madson is the technical leader for Cisco IOS VPN development and has worked on IPSec protocol since 1994. She was involved in the early formation of the SCEP protocol, and we're happy to have her here to tell you about it. Welcome, Cheryl.

Thank you, John. So, what I'd like to do today is to introduce SCEP as a protocol, give a little background on it, how it came about and how the protocol can be used in different environments today. This is really a conceptual talk. It's-- there are various vendors that support SCEP, but this is not intended to be a detailed representation of any vendor's specific implementation. In fact if you want to learn more about the iPhone integration with SCEP, you should go-- There will be a session covering that later this week.

So, the Simple Certificate Enrollment Protocol is a protocol to use for certificate enrollment. It was-- design goal was a lightweight mechanism for deploying certificates. It was never intended to be a full-blown PKI management solution. The protocol was originally developed by Verisign for Cisco, and this was about 11 or 12 years ago now. And at that time, the IETF standards effort had two major competing proposals, one from Microsoft and one from Entrust, and we had a real problem.

We wanted it to be able to ship routers, running IPSec and using certificates. Certificates are scaleable so we wanted to be able to use that And we couldn't really wait for consensus to happen in the working group, so this protocol was developed to more or less bridge that gap. And after all this time, there still is no real consensus.

Both protocols have -- both proposals have advanced on to become proposed standard within the IETF and may go on to Draft standard. In the meantime, SCEP has been maintained by Cisco as an IETF Internet Draft. So the original problem that SCEP was intending to solve was to supply certificates to routers running IPSec. And if you think back, routers didn't ship with any certificates at that time.

There was no concept of manufacturing certificates. There was-- they didn't come with pre-installed trust points of any kind. And a router isn't a host that where you can more or less download Safari or Firefox and magically get sort of trust points that way. So you have a bit of a bootstrap issue.

Basically, how do you obtain device certificates when you don't have any kind of pre-established trust relationship? And so if you look at the specification, it does talk about a couple ways of approaching it, you know passing, more or less passing like public keys and doing fingerprint verification et cetera.

There are various ways to approach a problem which I'm not going to really talk about here. So, if you looked at the SCEP specification, it's defined to run on top of HTTP mainly because of the bootstrap issue we talked about in the previous slide. Now in the case of the iPhone, it's going to run SCEP over HTTPS because it doesn't have that same bootstrap problem. What's needed is the-- certificates that are issued by a trust point that is already installed on the iPhone.

And so the certificates are used to secure the HTTPS session between the iPhone and the SCEP server, and then you run your SCEP protocol messages through this pipe, basically your certificate request and your-- and you know, your certificate reply. And obviously this is not the same. This third party CA is not the same as the enterprise CA 'cause what you're trying to do with this is obtain certificates that can be used to grant you access into an enterprise network.

So SCEP is a protocol. As I said earlier, it doesn't recall-- doesn't require secure transport and that's because it's using PK-- the messages themselves are secured using PKCS#7. There are a couple layers of wrapping. There's one layer that basically takes and wraps the message in PKCS#7, which is encrypted to the recipient. Then there's another wrapping which takes-- another PKCS#7 wrapping which takes and wraps the message and that's-- that is signed by the sender.

Now the payload itself of the message is there's a variety of messages if you look SCEP, but the important ones here are PKCS#10 certificate request, and x.509 certificate response or an SCEP control message, you know, indication of success or failure or hang on, I'm in the process of working on your request, so wait a little bit and ask me again later. So SCEP, as a protocol, operates under two infrastructure models, and this really has to do with how this server is structured.

So the first model is-- on the SCEP server is the certificate authority, and the CA takes on all of the functionality that's needed. This is involved, and it gets involved in authorizing the clients, it validates the enrollment requests and issues the certificates. While on the second model, the tasks are split up where the CA is still responsible for issuing certs, that's its main job in life.

And then there's this other party called the registration authority, and in this particular model, the registration authority is the intermediary between the client and the CA and so the communication goes from the client to the RA. The RA is involved in the authorization and validating of the enrollment request. With this model, it's possible to place an RA then in the DMZ and then have a secured connection from the RA to the CA which will live in the corporate network.

And just as an aside, the CISCO IOS CA Server supports both models of C only, CA only model and the CA/RA model where the Microsoft CA server--

Actually their server does support SCEP as well as extensions, but their model is really only an RA/CA model. So, the purpose of all this is to basically come up with some credentials for our client, you know, either a device or user. And so it becomes really important for SCEP to integrate with existing authorization services.

Because in effect, you're trying to come up with certificate credentials that will replace another set of credentials as this user ID/password. And so what you're wanting is after all is said and done, you know, using either the user ID/password or using the certificate that you come up with the same authorization result, so that integration becomes very important. And so there are a variety of authorization models out there.

We're going to focus on two of them that are likely going to be supported with the iPhone. The first one is one time password, and the other one is username password. Now this is, this is involved in getting the certificate in the first place. And introduce a concept here of a profile web service, and it has two major tasks. The first task is involved in the authentication of the iPhone client initially, and the other part it's responsible for is there is something which we'll call an SCEP profile.

Its job is to construct that profile and send that profile to the client. And that profile, the client then takes that profile and constructs a certificate enrollment request to the CA.

Excuse me. So, we talk about the one-time password model. I'll start out by saying that the certificate services icon here, you can view it as a CA or a CA/RA, it doesn't make any difference.

I'll say CA for simplicity here. So anyhow, the client gets a-- has to authenticate with the profile web service. Profile web service may interact with the Directory Service to perform some validation. If the validation is successful, it is responsible for obtaining a one-time password from the CA. You could view this one-time password sort of as an authorization token, a short-lived authorization token. And so profile web service constructs the SCEP profile, puts the one-time password in that profile and sends it back to the client.

The client then takes this profile, turns around and constructs the certificate enrollment request, includes that one-time password and sends it to the CA. The CA can perform the necessary validations, if it's happy, it issues a certificate, sends it to the client. The username password case is somewhat different. There are a couple of points here. One of the points is that with this particular scenario, you can construct a certificate and the certificate will contain the username which may become meaningful in certain scenarios.

So this is one way to go about it. And so, similar to the previous one, the client authenticates the profile web service. Now, the profile web service validates with the directory services and if it's happy, it constructs information in the SCEP profile and part of the information is an encoding of user name 'cause SCEP itself expects the username to be either part of the SubjectName or SubjectAltName fields.

And so it basically encodes things appropriately so the profile-- you know, so the client doesn't have to know what to do, so that information is then passed in the profile back to the client. Now in this particular case, there is a user name but there's not a password. And so what happens is that the user, the iPhone user is prompted for a password.

Now this is really an enrollment password conceptually similar to the one-time password that is sent in, you know, in the previous exchange where its job in life is to be an authorization token for enrollment. So, once that password has been entered, the client will take the information, construct a certificate enrollment request, take the information including the username, takes the password, sends it to the CA.

CA takes the username and password, validates with Directory Services. And if that validation goes okay, it issues the cert, sends it back to the client. As you notice in this particular scenario, there's a lot more interaction with the Directory Services as part of authorization or authentication and authorization than there is in the previous scenario.

So, I'm going to touch a little bit on the pilot for Cisco IT. There is a whole bunch of people that want to be able to use iPhone to connect into the Cisco VPN network. This is really conceptual, you know, kind of the 500,000-foot view of the world. There's a lot of details that aren't on the slide. But the main thing to remem-- the main point out of this particular slide is that this is actually a combination of the previous two scenarios.

There will be a certificate issued with username and so the, you know, taking the piece of the username stuff from the previous slide, but there's still the one-time password similar to that first scenario. So both of those are munged together in the exchange and so there is no specific prompt that the user has to enter in a passcode.

So this is all, you know-- Once the initial authentication is done, this all just runs on its own. And so the purpose of this is to issue certificates that can be used for Cisco IPSec VPN connections. And so once the client has a certificate, it can then present that certificate when it tries to connect, you know, as part of the [inaudible] exchange.

It could present a certificate to the VPN server. Cisco VPN Server can validate it. If the validation succeeds, it will take that username and validate the user within the Directory Services, and if that succeeds it'll allow the connection to happen. As an aside here, this is besides being conceptual, this is still in fairly early phases. We're still doing some design, some planning, some testing.

We've just received some iPhones for testing. So, this is more or less the way we think this is going to play out but, you know, like I said this is still in early stages, so some of the details may change over time. So for more details about the SCEP protocol, as I said earlier it's been maintained as an internet draft in the IETF. So there's a current draft out there. If you go to the internet draft database and enter SCEP, you'll find it.

There will be a new version of the draft available soon. You know, this spec is an individual submission. It's not a standards track. It's not a working group submission, and that's because it was submitted to the [inaudible] group and was rejected mainly because there were already these two other proposals that the working group is working on and they were focusing on that.

And so, we've been treating this as an individual submission, excuse me, all this time. So the goal is to publish this as an RFC, hopefully an informational RFC, but it won't be a standards track document. However, even though it's not a standards track document, the document has undergone recent review from the IETF Security Area Directorate.

So, you know, in order to clean things up and clarify things, and so we're hoping with that that we'll be able to soon look at actually publishing this as an RFC. So I'd like to end this by saying that at Cisco, there are a lot of us that are really excited about the iPhone and excited that we're going to be able to use the iPhone to connect into the corporate network, and we're happy that we're able to contribute some technology to allow that to happen.

So, thank you.

Thanks Cheryl. So at Apple we're really excited about providing support for SCEP, but I want to put it in context of what we're trying to do here for the iPhone. So, we have the user authentication and this ensures that your user is authorized to get the certificate enrollment. We have the certificate enrollment itself and this is using the SCEP protocol, you can get a standard certificate signing request and you get-- you can receive an identity for that particular iPhone.

But this all leads up to one particular feature which is over the air device configuration. And this is a service that you have to build yourself in your infrastructure, but the idea here is that you can deliver seamlessly an encrypted configuration profile with the settings for all your enterprise environment directly to an iPhone.

Now, what the user experience here is, is that the user goes in, logs in with a name and password and all this happens in the background. You get a certificate through the enrollment process provisioned down to the device, and then you can go back to a profile web service, and that can give you a generated configuration profile, securely down to the device as well. And then the user hits one button to install that configuration profile, and they're off and running.

Now, there are some pieces to this infrastructure that you have to build yourself, and I just want to point them out. So Directory Services, that's when a-- authenticate your users. Now, you have to hook this up to some kind of web service, and I'll get to that in a second. Your certificate service, now this could be an internal public key infrastructure or an external hosted one.

It needs to support SCEP, so you need to check with your vendor whether they do that. And if you haven't deployed one, I think checking out Cisco IOS is probably a good place to start. And then the profile web service. Now this is the glue that binds the whole workflow together.

It hosts the HTTPS session, it generates the configuration profiles, it signs and encrypts those profiles. And then often, what you also wanted to do is provide a proxy back into the corporate infrastructure to where your certificate service actually lies, so that it's protected behind the firewall. So there's a detailed session that goes over creation of configuration profiles and creation of these types of services, and there's a lab to go along with it. Those are on Thursday. There are also a couple sessions up here around good practices of security with the iPhone that I want to point you to.

So with that, I want to get into a little bit about development. Now, the applications for the iPhone have been fantastic. We now have over 50,000 applications on the iTunes Store, and many of those applications are dedicated to enterprise use. Now we couldn't do this without having created a secure ecosystem to host these applications. And we did that by leveraging a bunch of technologies from Mac OS X. Now, all applications on the device are signed.

The ones from the store are signed by Apple and the ones from in-house deployments are signed by the enterprises themselves. Now, that ensures that the user knows that that application hasn't been tampered with. Additionally, we sandbox each application so it cannot-- it restricts itself so it can only see its data and not another application's data, and it can't muck with the system data either. And this ensures that you can deploy secure applications without having to worry about all the other applications on the device mucking with that data.

And of course in the iPhone OS, we've implemented all the security framework that you need. We've-- for all the standards for certificate key and encryption and we also have our secure keychain services so you can safely store credentials. And as a neat new feature for iPhone 3G S, we also support hardware encryption.

Thank you.

Now this happens in the hardware to the data on the fly, and it's completely transparent to the user. And one of the great side benefits of this is that remote wipe becomes almost instantaneous. Because you don't actually have to erase any of the data, it's all encrypted by key and you can just throw that key away. Now, your business is unique and some of your users have specialized needs or just really appreciate a custom workflow.

And this is especially true in the mobile workforce. And so, putting together in-house apps can really enable these mobile workers. The idea here is that you give the data to the user exactly when he needs to use it. And what I encourage you to do is design these things so that you have the minimal amount of input and the exact output in data right in front of the users that they need. It's really important for these applications to be designed for mobile use. They need to run fast and they need to be streamlined for the workflow of their users.

Now, you should follow good UI practices. And if you want to follow the UI practices that are already implemented on the iPhone, that's probably best because it really shortens the learning curve. And integrate these applications in with the data in your corporate infrastructure and also integrate them in with applications like Safari so they can reach out into the network and get that data for your users. So our customers have put these iPhones in some really incredible environments and I want to invite Dean Moore, Sunbelt Rentals, up to share some of his experiences with iPhone.

Hi everyone. I'll spend a little bit of time today telling you about our experience with application development with the iPhone and the SDK and doing some nice in-house applications. Before I do that, I'd like to give you a little history or tell you a little bit about who Sunbelt Rentals is, as well as explain to you why we decided to develop our own application.

Sunbelt Rentals is a wholly owned subsidiary of Ashtead Group plc, and we are traded on the UK Stock Exchange. We're the third largest equipment rental company in the country, and when you combine the entire group with our European counterpart, we're the second in the world. We have over 400 locations in 34 states and th4e District of Columbia, and 5500 employees and a sales force of 800.

We also have two iPhone developers. Now, where we were. I'm sure some of you when you look at these, you might be able to relate to one or two of them but unfortunately, we really had the perfect storm at Sunbelt. We fit into all these categories. We had a primary communication device for our sales force which was a Sprint/Nextel two-way radio. They used it for everything, communication with their customers. They used it to-- two-way radio back to a branch to look up equipment availability rates.

We had very poor communication out to our field. As procedures changed, we used to have to have quarterly conference calls, that information was usually late in getting to them. Customer data, this is an interesting thing. We actually printed the customer data quarterly and bound it into a book. Fortunately, by the time that stuff hit the printer, it was already old and it also cost us a lot of money to distribute that data.

We had very, very limited access to our operational data while on the sales calls and really tough time getting leads and information out to our field. Again, we printed that quarterly and by the time they got it, it was too old. About the only technology you see there is that calculator that we put into their notebook which didn't help them too much. So when we took a look at where we were, we decided we need to change, we need to really make some changes with how we do our business.

We needed to improve communication within the company. We needed to move our sales force from a manual procedure to something that was technology based. I wanted to provide that sales force with live pertinent information at the point of sale. And you know point of sale for our reps isn't sitting in an office somewhere. These guys are on the job site in the job trailers or in the dirt, they're right there with the contractors.

We also had a lot of different systems that we had to, you know, we had to integrate in to get that data to the sales reps, so we always want to provide better customer service. Now, there are other rental companies out there and we all pretty much rent the same equipment. But what really sets us apart at Sunbelt is our customer service and we really pride ourselves on that.

So, how did we get there? The iPhone. We were able to leverage our current Microsoft Exchange infrastructure to give us push mail, calendar, contacts, and the address lookups, so this is real key. This is information that we just couldn't get out to a timely manner to our users. They were, you know, stopping at one of the branches on the way to work or possibly, you know, after the day they were going and checking their email. Now they have it all day long.

We're able to instantly communicate with them. We then took the device, put a nice hardened case around it, give it that nice construction look and ruggedized it a little bit, and we wrote our own custom application Mobile SalesPro.

Now Mobile SalesPro, it is truly a complete mobile workflow. Our sales reps are able to plan their week by having a daily task planner right at their fingertips. They can add new tasks, they can edit tasks, they're able to look at new sales leads, as well as share those leads with other reps.

And the key to it, it's all integrated with our Microsoft CRM solution. So all the data they're entering into their iPhone is going right into our backend system. So before, when they were using handwritten notes and keeping track of their customers on paper, we now have that data in our backend system. So if a sales rep is to move on to another position or leave the company, the next person that comes in can pick up right where they left off and our customer doesn't have to sacrifice.

We're able to prepare for that sales meeting as they're pulling up to the job site and getting ready to get out of their truck. They can review their customer account detail. They look at their current AR status. Is this customer paying their invoices on time? Could look at rental history as well and see what current equipment they have on rent, so that they can change really the way that-- the way they're going to speak to that customer, possibly what they're going to try and help that customer accomplish.

They're able to fulfill the customer request right there on the job site by having real-time access to our inventory. They're able to see where our equipment is, whether it be at the local branch district level, their territory region, with all the way up to the company and it's all real time.

They give a better level of service by having at their fingertip access to email credit applications as well as to review open invoices and contracts with the customer, as well as email right from the device and they can request equipment to be picked up. So Mobile SalesPro, it truly is an end to end solution. Whether our sales reps are planning or preparing for their sales call, fulfilling requests or adding to their customer service, they're able to do everything anywhere with Mobile SalesPro and the iPhone. Let me just talk a little bit about our development process.

Since there are only two of us, it is kind of simplified. We kind of shrunk the project lifecycle, but we did define some goals up front, some milestones. We wanted to makes sure we got the key features included and we had to put some milestones on that because, you know, you have to keep, we have to keep ourselves moving towards something. Created some rough screen layout so we got a feel for how the app should flow, and we had direct communication from developer to sales force.

So this is real key. This is what kept us developing what our users needed rather than us developing what we thought they needed. We were able to have instant communication with them. In fact, we even went out on sales calls. We put on our steel tips and our hardhats and we drove out and went on sales calls, so we could see exactly what they needed and how they were going to use the app.

Just to go over the timeline a little bit. As you can see, we have some milestones set up there. We started the application kind of as a sideline project shortly after the SDK was released. And in November timeframe, we added our first 10 users. These ended up being really our base.

We got a lot of feedback from them. As you can see, we progressively added more users. We got more feedback, we developed more features and then we just kept on repeating that process. We just had a really large milestone about a week here. We added an additional 1100 iPhones so we now have total of 1300 iPhones deployed, and the feedback has been phenomenal. So, how do we get this data? We have a lot of different systems. At the base of it, we have an AS/400 which is really our backend system. It handles AR, AP, GL, our complete inventory, our rental counter, our point of sale.

It really is the heart of our business. We have some Microsoft SQL Servers, HRIS system, data warehouse. We have a Microsoft CRM Server. What we do is we have a .Net Server kind of in the middle and it handles all the communication between the back office and our iPhones. Everything is requested through that .Net Server.

We handle it via web services. Now, if we have to get data from SQL Server it's handled through stored procedures. If we have to get it from CRM, we'll use their approved API. And for the 400, it's a little bit of stored procedures as well as some RPG programs. The data is then transmitted from the .Net Server to the iPhone via XML over HTTPS, so it's all encrypted. Now to get that data, we make an HTTPS GET request to the web service.

That data is then transmitted down as I said as XML. We wrote a custom wrapper for XML parsing that basically goes through the XML, creates objects, uses key value coding, fills those models in that we displayed in the UI. We do just the reverse when we have to post data.

We have a SOAP class. We go ahead and we get a list of all the properties for our objects. We serialize those out to XML. We then put some SOAP patterns on it. We do an HTTPS post. So we can do that both for single objects as well as array of objects.

And again, the data is all encrypted. Now to do all this, we needed to have a security model. So the way we architected it is the device asks for an employee ID, everybody knows their employee ID, and it asks for a password. We then pass that through our system, we hit our HRIS system, we validate there that they're a current employee. If they are, we basically use a token or a GUID.

We store that in the database. We shoot it down to the iPhone and we cache it on the iPhone for a period of 24 hours. Any data quest that-- data request that happens from that iPhone must have that token and that token must be valid, otherwise we don't give it any data. So here are some best practices. Involve your users early in the development process, listen to them. They generally know what they want, and by involving them, you make them part of the process, you empower them.

When they're empowered, they will make sure you are successful. Have a well defined and agreed upon feature set, but be ready for change. This is a new mobile platform. You're going to make changes throughout the process because it's new. Develop and deploy in phases, and that will help you keep on track with making sure you're meeting that feature set. Follow the UI guidelines. Can't stress this enough, if you make your app, work like the built-an apps, there will be no training for your users, whatsoever.

Architect once, leverage often. This is kind of an interesting story. As we were getting ready to deploy an additional 1100 phones, up until that point it was kind of onesie-twosie, maybe 20 at a time, very manual. We started to say, "Well you know, we got to get Exchange on there.

How are we going to get that config file down to the users?" Well, best practices says that you go ahead and put a website up. Have a, you know, login and then you can download the provision file to the device and set your email up. And the light went off and we said, "You know, we did that already, we built it into the app." So what we do is when you're setting up, put your user ID in, your password in, then would give you a GUID. You know, you verified your user.

We then open up another row in the table that's to set up email, and we simply just launch an HTTPS request with our GUID to our backend server and request for the mobile config file to come down. It can't be simpler than that and it's completely integrated. They don't have to type a web address in, they don't have to do anything but set up the application.

So, what's next for Sunbelt Rentals? Literally the sky is the limit. This is a new mobile platform for us. We've added a feedback feature right into our application so that our users can easily give us feedback as far as enhancement requests, possible bugs, it's all entered right into our CRM system, and the feedback has been phenomenal.

We're getting requests probably faster than we can code them which is obviously a good thing because it helps us keep going. We're also finding that we're getting people from other business units that are coming to us and saying, "Wow, you see what you did for the sales force, what about service?" So, it's just going to continue to grow. Mobile SalesPro as well as the iPhone is definitely changing the way we do business at Sunbelt Rentals.

Thank you everyone for your time.

So when we created the iPhone, we knew we had something special. But as we put these devices in our customers' hands and giving them an SDK, I'm just really blown away with what they've been able to do with it.

That's a great story Dean, thank you. So we covered integration of the iPhone into your existing enterprise infrastructure. We covered deploying the iPhone out to your end-users and we've covered developing in-house applications for your specific business needs. I'd like to thank all of you for attending the session and I'd really like to thank our guest presenters, and can you give them a round of applause.

Duncan Keefe from Apple, Cheryl Madson from Cisco, and Dean Moore from Sunbelt Rentals, thank you and enjoy the rest of the week.