9. SCEP: A Background

So far, we haven’t really talked much about certificates and profiles beyond installing them on a device, and how you need them for enterprise application distribution. We’re going to change that, because although certs and profiles can be some of the biggest pain points an IT administrator faces, they’re also really useful, and Apple has done quite a bit of work to make adding them into your iOS device much easier.

Enter SCEP

All the installation methods we’ve looked at thus far have limitations that we’ve not been able to reconcile. When you want to encrypt your profiles to include passwords or internal certificates that you don’t want installed on just any device, you’ve had to physically connect your iOS device to a computer running the iPhone Configuration Utility (iPCU), or create a separate configuration profile for every device after physically connecting that device to a computer running iPCU.

That’s okay for small deployments, or when you have devices trickling into your company in small numbers. But what about large deployments, or when you must ready a huge numbers of devices in a hurry? We currently have solutions that scale, but don’t allow us to safely include passwords or proprietary information. Or, we have solutions that are encrypted to include passwords and proprietary information, but they don’t scale for beans.

There’s got to be a better way, and there is: SCEP, or the Simple Certificate Enrollment Protocol.

SCEP predates the iOS by quite a few years, and was designed to help sysadmins handle SSL Certificate Management in a way that was scalable, reliable, secure, and usable by any valid network user without the need for IT support. It was created by Cisco as, among other things, a way to make it much easier to enroll in certificate-based VPNs (something Cisco has a bit of an interest in).

The (very!) basic idea with SCEP is that once you have some valid form of network credentials, usually LDAP-based in a modern network, you can log onto a web site with your device, and sign in using those credentials. From there, your device and the web site identify themselves to each other, and you can get a certificate to access VPNs or anything else that requires a certificate.

Note that the device identifies itself to the web site. As part of encrypting a profile, the device must be identified to the iPCU so that the device’s key can be used to encrypt the profile. This ensures that only that specific device can unencrypt and use the profile. That’s secure; but when you’re trying to hand out these profiles on a large scale, that’s painful. SCEP is a way to deal with that pain. (Although as we’ll see in later chapters, SCEP itself can be quite painful.)

For iOS, Apple figured out a way to integrate SCEP with configuration profile distribution so that you could create and install profiles for devices that were secure, encrypted, distributed entirely OTA, and didn’t require any IT intervention. As long as you have valid network credentials, you can get the right profile for your iOS device, and it can even have your username, password, email address, and all the rest. Even better, you don’t have to go to a URL that references a specific .mobileconfig file. You can just go to http://scepserver.mycompany.com/ and SCEP, plus a few other tricks, takes care of the rest.

“A Few Other Tricks”

So about that “SCEP, plus a few other tricks...” thing. I think the biggest problem with SCEP (one that Apple has done a really terrible job explaining) is that SCEP is only there to deal with secure certificate distribution, a.k.a. enrollment. As we’ll see, all the rest of the process happens completely outside of SCEP. But, because of the (minimal, but slowly getting better) documentation on OTA iOS enrollment, it is very easy to think that SCEP actually handles the entire process. It doesn’t, but thinking it does will lead you deep down the rabbit hole. I know that it caused me some major headaches, as I was conceptually way out in left field about what was happening.

Configuring iOS Devices via SCEP

So let’s look at what’s really going on at a high level. (This is sourced directly from Apple’s documentation at http://developer.apple.com/library/ios/featuredarticles/FA_Wireless_Enterprise_App_Distribution/Introduction/Introduction.html#//apple_ref/doc/uid/TP40009979. Gotta love Apple URLs.) There are three major phases to OTA profile delivery using SCEP:

1. Authentication

2. Certificate enrollment

3. Device configuration and encrypted profiles

Authentication

The authentication phase is basically what you set up in Chapter 8. You hand out a URL to the user, via email, SMS, or what have you. She goes to that URL and authenticates to it. (For our purposes, we’re going to assume you have an LDAP-based Directory Service handling your user authentication data, but it’s not required.) You can even check against a list of approved devices, so if someone manages to suss out the authentication credentials but doesn’t have the right device, they’re shut out.

Once this is done, the site loads a minimal configuration profile onto the device, which contains a request for certain device-specific information to be used in later steps. This can include the iOS version, the MAC address of the Wi-Fi interface, the product type (such as iPhone 2.1), the IMEI number (if applicable), and/or the SIM card identifier number, or ICCID (if present).

The device returns this information to the server via HTTP POST. (In case it needs mentioning, clearly this web site should only be accessible as an SSL link.) This response is signed by the device with its built-in key via an internal certificate from Apple. So we now have the information we need to start using an encrypted profile.

So far, all the user has had to do is log in to a web site. You can, if you’d like, create a challenge of some kind that the user has to respond to and use that as an additional layer of security. The challenge can also be specific to the device if you like, such as UUID, IMEI, or MAC address. (If you’re going to use a device-specific bit of info, you’ll need to have it ahead of time, so that’s probably not the best strategy if you’re allowing people to enroll their personal devices.)

Certificate Enrollment

The server then sends back a second configuration profile with the information needed to make use of SCEP. This profile installation is done in the background; the user doesn’t need to know about it at all. Obviously, this profile should be signed by the server. It contains the infomation needed to create a certificate signing request, or CSR.

A Quick and (Very) Dirty CSR Explanation

When you create an SSL certificate, you first need to create a request. This request, or CSR, contains information such as the DNS name of the server (if you’re getting the cert for, say, a web site), the company name, the location of the company, the encryption key size, and so on. The information in the CSR can vary depending on need. Basically, the idea is to use enough unique information so that a proper certificate can be generated that identifies a web site, or a device, or even a person. The CSR is then used by the certificate authority to create the certificate you actually use.

For iOS devices, the profile provides information such as company name, the key type, and the UUID number. An example of such a profile is available from Apple, and it looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Inc//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>PayloadVersion</key>
        <integer>1</integer>
        <key>PayloadUUID</key>
        <string>Ignored</string>
        <key>PayloadType</key>
        <string>Configuration</string>
        <key>PayloadIdentifier</key>
        <string>Ignored</string>
        <key>PayloadContent</key>
        <array>
            <dict>
                <key>PayloadContent</key>
                <dict>
                    <key>URL</key>
                    <string>https://scep.example.com/scep</string>
                    <key>Name</key>
                    <string>EnrollmentCAInstance</string>
                    <key>Subject</key>
                    <array>
                        <array>
                <array>
                <string>O</string>
                <string>Example, Inc.</string>
            </array>
        </array>
        <array>
            <array>
                <string>CN</string>
                <string>User Device Cert</string>
            </array>
        </array>
    </array>
    <key>Challenge</key>
    <string>...</string>
    <key>Keysize</key>
    <integer>1024</integer>
    <key>Key Type</key>
    <string>RSA</string>
    <key>Key Usage</key>
    <integer>5</integer>
</dict>
<key>PayloadDescription</key>
<string>Provides device encryption identity</string>
<key>PayloadUUID</key>
<string>fd8a6b9e-0fed-406f-9571-8ec98722b713</string>
<key>PayloadType</key>
<string>com.apple.security.scep</string>
                <key>PayloadDisplayName</key>
                <string>Encryption Identity</string>
                <key>PayloadVersion</key>
                <integer>1</integer>
                <key>PayloadOrganization</key>
                <string>Example, Inc.</string>
                <key>PayloadIdentifier</key>
                <string>com.example.profileservice.scep</string>
            </dict>
        </array>
    </dict>
</plist>

Big Scary Cert Warning

If you are just completely confused by all this talk of certs and CSRs, I highly, highly recommend that you stop reading right now. Run, do not walk, to learn about how all this is supposed to work. Certs and SSL and the like are common ways to make things secure, but they are terribly, almost frighteningly easy to get wrong. Even something that seems minor can create a huge gaping hole in what you think is a secure setup. Certificates and the concepts behind them are necessary, but they’re not the easiest things to learn. Again, entire books are written about this topic, and if you’re dealing with it for the first time, please, please, please stop, and either learn what you need to learn, or employ the services of someone who already understands it.

Remember the SCEP server settings in configuration profiles that we talked about in Chapter 5? Here’s where they come into play, and if you compare the contents of the plist file above to the settings in the SCEP section of the iPhone Configuration Utility’s Configuration Profile setup, you’ll see that they match rather nicely. Once this second configuration profile has been installed, the device then contacts the actual SCEP server with the CSR it now has, and receives a device-specific certificate from the SCEP server.

Device Configuration and Encrypted Profiles

Okay, head hurt yet? No? Lucky you, mine does. So, now, we have a cert from the SCEP server, and the profile server that we initially talked to pages ago has the response from our device that was signed with the device’s internal Apple-provided cert. This response also provided the configuration server with something rather important to this step: the device’s public key. This is the key that will be used to encrypt the third profile we’re about to install. By using the device’s public key, we ensure that the profile can be decrypted only with the device’s private key.

Private and Public Keys

Okay, if you thought the basics of SSL were brain-bending, this entire “keys” thing is just as bad, maybe worse. It’s all part of a concept called PKI, or Public Key Infrastructure. Basically, it is this. You have a public key and a private key. You give out the public key willy-nilly—the willy-nilly-er the better. You never, never, ever give out or allow access to the private key.

So let’s say you have a message that you want to send, and you really want people to know you and only you sent it. Once you have composed the message, you sign it with your private key and send it. People can then use your public key to verify that you signed that message. (When you hear people talking about digital signatures, this is what they should be talking about, not silliness involving scans of their pen and ink signatures.) Conversely, if someone wants to send you something, and ensure that only you can read it, he can encrypt it with your public key, and only you can decrypt it with your private key.

Confused yet? It gets better. Someone can also give you his public key, and after signing that message with your public key, he can then sign it with his private key. So, now you get an encrypted, signed message. You use his public key to verify the sender, and use your private key to decrypt it so you can actually see the message. Not only are you (in theory) the only person in the world who could read this message, but you are sure (in theory) of who sent the message. If you really want to get a better understanding of this, I highly recommend reading the document at www.carillon.ca/library/enrolment_1.1.pdf?page=tutorials. Yes, it is in fact called “PKI Enrollment A Fingerpuppet-Theatre Guide”. It is also a well-done, accurate explanation of PKI, and why it’s useful. You really need to understand PKI for this chapter to be as useful to you as it can be.

The device sends a signed request for the final profile to the profile server. The request is signed with the certificate the device received from the SCEP server. The profile server creates the final profile, encrypts it with the device’s public key, and sends this encrypted profile to the device. The device receives, decrypts, and installs the profile. The device is now configured.

Wrapping Up

So with only two servers, three configuration profiles, certificates, CSRs, public and private keys galore, we have a configured device. You all may be wondering: “Why, oh why, would I ever do this? Is it that much to ask people to enter in a user ID and password?” Well, probably not. But let’s take a look at this.

Without SCEP, you can’t easily encrypt the profiles. So you can only automate the configuration process so far. You could automate the profile creation to include passwords; but without encrypting the profile, it’s a really bad idea.

SCEP helps you encrypt your profiles without manually tethering the device to a Mac or Windows box running the iPhone Configuration Utility. With SCEP, you can further automate the processes we’ve talked about in earlier chapters and do it in a more secure manner. So, iOS device setup becomes even more convenient for users, because if you take advantage of profile creation automation and SCEP’s security, you can integrate profile creation into your infrastructure. Your users can get their devices configured as needed without spending a lot of time entering what is essentially duplicate information. And you don’t have to spend a lot of time creating custom profiles, or attaching devices to a computer (or three). Plus, it’s all done fairly securely. What could possibly be the problem?

As we’ll see, the problem is that setting up all this, especially SCEP, is a lot harder than it should be unless you use one of the many commercial implementations available.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.14.251.128