"“'“"'“":§ Building and Managing Virtual Private Networks
`by Dave Kosiur
`Wiley Computer Publishing, John Wiley & Sons, inc.
`ISBN: 0471295264 Pub Date: 09i01l98
`
`{Previous Table of Contents lhlextl
`
`Protocols and Their Algorithms
`
`Each of the VPN protocols we’ve discussed in this book—lPSec, PPTP, and L2TP—specify their own
`list of allowed algorithms for encrypting data.
`
`Although PPTP can use PPP and its negotiable encryption options (including DES and Triple DES) to
`encrypt data, Microsoft has incorporated an encryption method called Microsqfi‘ Point-to-Point
`Encryption (M PPE) for use with PPTP tunnels. MPPE uses the RC4 algorithm with either 40-bit or
`128-bit keys, depending on export restrictions. Similarly, L2TP can use PPP to encrypt data, but the
`preferred method is to use IPSec for this task.
`
`Within IPSec, the default encryption algorithm for use in ESP is DES with an explicit initialization
`vector. IPSec allows alternative algorithms to be used. These include Triple DES, CAST-128, RC5,
`IDEA, Blowfish, and ARCFour (a public implementation of RC4).
`
`The choice of supporting algorithms other than DES is left to vendors, so you may find that a vendor’s
`products do not support the alternative algorithm you had planned on using. DES and Triple DES seem
`to be the most common algorithms supported thus far. There’s a definite benefit to having a choice of
`encryption algorithms: Would-be attackers not only must break the cipher, but they also must determine
`which cipher they are attempting to break.
`
`Recalling the Oakley modes used in IPSec (Chapter 5), main mode negotiates the encryption method,
`hash, authentication method, and Diffie-Hellman group between VPN endpoints. The Difiie-Hellman
`group determines the strength of the keying material; there are 4 Dift'ie—l-Iellman groups. Diff1e—Hellman
`Group 1
`is strong enough for DES, and Groups 2 and 3 should be used for Triple DES. Because main
`mode might require six packets, if you’re using high-latency satellite connections, for example, it would
`be better to use the stronger Diffie-Hellman group, even for DES.
`
`Oakley’s quick mode also negotiates the algorithms and lifetimes for IPSec. These lifetimes determine
`how often, based on time or data, another quick—1node negotiation is required. The main—mode lifetime
`controls the Oakley SA, and the quick-mode lifetime controls the IPSec SA. As an example, the
`quick-mode lifetime could be set to 15 minutes, or 10 MB, and the main mode lifetime set to 1 hour, or
`40 MB, when DES is being used for IPSec. These lifetimes would be increased for Triple DES, because
`it’s more secure than DES, or decreased for ARCFour, because it’s less secure than DES. The idea is to
`balance the strength of the IPSec services and the strength of the underlying cryptographic algorithms
`against the cost of ISAKMP/Oakley packet overhead; too many changes in keys could affect the
`efficiency of your network.
`
`217
`
`Petitioner Apple Inc. - Exhibit 1024, p.217
`
`

`
`Key Lengths
`
`Back in Chapter 8, “Designing Your VPN,” we suggested that you determine the sensitivity of your data
`so that you could calculate how long it will be sensitive and how long it’ll have to be protected. When
`you’ve figured that out, you can select an encryption algorithm and key length that should take longer to
`break than the length of time for which your data will be sensitive.
`
`As a starting point, take a look at Table 13.1, which is a condensation of information from Bruce
`Schneier’s book, Applied Cryptography, which we also used in Chapter 4, “Security: Threats and
`Solutions.” The table does a good job of illustrating that many of the key lengths currently in use can be
`broken with a relatively small outlay of funds. This table also helps emphasize this point: know your
`attacker. If you expect that highly skilled and well—funded industrial spies will be attempting to intercept
`and decrypt your data, then long key lengths and frequent rekeying are an absolute necessity.
`
`TABLE 13.1 Comparison of Time and Money Needed to Break Different Length Keys
`
`Cost
`
`$100 K
`
`$1 M
`
`$100 M
`
`$1 G
`
`$100 G
`
`i40
`
`2 sees.
`
`.2 secs.
`
`2 millisecs
`
`.2 millisecs
`
`56
`
`35 hrs.
`
`3.5 hrs.
`
`2 mins.
`
`13 secs.
`
`2 microsecs
`
`.1 sec.
`
`Length ofkey in bits
`
`64
`
`1 yr.
`
`37 days
`
`9 hrs.
`
`l hr.
`
`32 sees.
`
`80
`
`128
`
`70,000 yrs.
`
`7000 yrs.
`
`70 yrs.
`
`7 yrs.
`
`24 days
`
`1019 yrs_
`
`1013 yr-s_
`
`1016 y1~5_
`
`1015 yrs_
`
`1013 yrs_
`
`These estimates are for brute—force attacks, that is, guessing every possible key. There are other methods
`for cracking keys, depending on the ciphers used, which is what keeps cryptanalysts employed, but
`estimates for brute-force attacks are commonly cited as a measure of the strength of an encryption
`method.
`
`Remember that this is not a static situation either. Computing power is always going up and costs are
`falling, so it’ll get easier and cheaper to break larger keys in the future. Off-the-shelf processing power
`(costing around $500 thousand) can crack the 56-bit DES code in 19 days; hackers choosing to invest in
`custom chips could break the code in a few hours. A student at UC Berkeley used a network of 250
`workstations to crack the 40-bit RC5 algorithm in three and a half hours.
`
`Key Management for Gateways
`
`A number of keys are usually required for secure communications between two gateways. First is the key
`pair that identifies two gateways to each other; these keys might be hard-wired, exchanged manually, or
`transmitted via digital certificates. Second are the session keys required for authentication and encryption
`of the packets transmitted between the gateways, using IPSec’s AH and ESP headers, for instance.
`Different keys are required for each IPSec header and are negotiated via security associations (see
`Chapter 5). If both AH and ESP are used to process packets, for instance, then two SAs are negotiated
`
`218
`
`Petitioner Apple Inc. - Exhibit 1024, p.218
`
`

`
`between the gateways or hosts.
`
`Identification of Gateways
`
`Before a secure tunnel can be established between two security gateways, or between a remote host and a
`gateway, these devices have to be authenticated by each other and agree on a key. First, let’s look at
`exchanges between two gateways. This authentication is not the same as the authentication of packets
`using the AH header; here, we are authenticating the devices themselves.
`
`‘Previous [Table of Contents ‘Next
`
`219
`
`Petitioner Apple Inc. - Exhibit 1024, p.219
`
`219
`
`Petitioner Apple Inc. - Exhibit 1024, p.219
`
`

`
`Building and Managing Virtual Private Networks
`by Dave Kosiur
`Networks Wiley Computer Publishing, John Wiley & Sons, Inc.
`ISBN: 0471295264 Pub Date: 09t01!98
`
`lPrevious Table of Contents |Next
`
`Gateways using public-key pairs can be authenticated manually. In such cases, the key pairs are usually
`hard-wired into the device before it’s shipped. The network manager then registers the new device with
`other security gateways on the VPN, giving those gateways the public key so that they can exchange
`session keys.
`
`If a security gateway isn’t shipped with hard-wired keys, the gateway would be Set to randomly generate
`its own key pair. A digital certificate then would be signed with the private key and sent to the
`appropriate certificate authority, either an in-house certificate server or a third-party CA like VeriSign.
`When the certificate is approved, that certificate is available from the CA for use by other security
`gateways and remote clients to authenticate the site before any data is exchanged (see Figure 13.2).
`
`Although these certificates do not need to be standardized (using the X509 standard, for instance) if only
`one vendor’s products are used for the VPN, interoperability between products is possible when X.509
`certificates are employed. More vendors are adopting this approach, which also makes it easier to utilize
`an outside certificate authority for storing the necessary certificates. This might be a necessity if you’re
`expanding your VPN to include partners in an extranet.
`
`Other gateways and remote hosts usually will obtain the appropriate certificate from a CA to authenticate
`the destination gateway by using mechanisms such as LDAP or HTTP to retrieve certificate information
`through a pubtic key infrastructure (PKI) Existing PKIS also require checking certificate revocation lists
`(CRL) to ensure the validity of an existing certificate. However, because the CA hierarchy for verifying
`certificates that we described in Chapter 4, “Security: Threats and Solutions,” can become ungainly, and
`CRLS can become complicated to handle, other mechanisms for verifying certificates are being
`developed and most likely will become available starting in 1999. In particular, the IETF PKIX working
`group has been working on definitions for an interoperable PKI and Onlfne Certificate Status Protocol
`(OCSP). OCSP aims to provide an efficient method for handling compromised or revoked certificates
`(see “Hardware—Based Security” later in this chapter).
`
`IO
`lTCU_I'{_lE1—lTfl<.'.’ey exchanges between gateways.
`
`These systems are based on assigning a public-key pair to each security gateway, and the public key is
`published in a directory that’s accessible to all VPN sites. At the start of each encrypted session, the
`session key is scrambled by combining the security gateway’s private key with the recipient’s public key.
`
`220
`
`Petitioner Apple Inc. - Exhibit 1024, p.220
`
`

`
`Handling Session Keys
`
`If key exchange (such as in IPSec and LZTP) is required between sites, the most basic method is to
`exchange keys manually. An initial session key is randomly generated by one security gateway and then
`the network manager has to deliver the key to the administrator of the second device, by telephone,
`registered mail, or bonded courier, for instance. The second administrator inputs the key to the second
`security gateway, and a secure session between the two gateways can take place. New keys are generated
`as required (perhaps once a week) and distributed in the same fashion as before.
`
`This approach is rather cumbersome and not particularly secure; phone lines can be tapped and mail can
`be intercepted. Dynamic key management, using IKE for instance, is much easier and better suited to
`frequent key changes and large numbers of sites. Session keys are randomly generated, either by the
`initiating security gateway or a key-management server, and distributed over the network. The session
`key itself is scrambled using the recipient's public key before transmission on the net.
`
`Hardware-Based Security
`
`Hardware-based encryption products are less vulnerable to physical attack, which reduces the chances
`of compromised device keys and, therefore, the need to exchange new keys between gateways.
`Whether keys are hard-wired or entered from a management workstation, most hardware encryptors are
`strongly sealed against physical prying and usually erase any stored keys when disturbed.
`
`If session keys are compromised, you’ll need a way to revoke a key pair and assign a new one. The
`procedures for key revocation vary from product to product. How security gateways respond to a revoked
`key also varies among products. The best, most secure method is to drop the session and log the failed
`attempt as soon as a revoked key is detected. Some products wait for a session to be completed before
`denying any fiarther access with that key.
`
`If you’re in a situation where your VPN is restricted to shorter length keys than you would like (due to
`export restrictions, for example), then you should try to improve the security of your VPN sessions by
`increasing the frequency of rekeying. If keys are used for shorter lengths of time, then any attacker will
`have less time to acquire the information he needs to break a key; also, the amount of data that could be
`obtained with a compromised key will be reduced.
`
`Key Management for Users
`
`Generating and distributing keys for LAN-to-LAN VPNS can be a relatively simple process to manage
`when the number of sites is not very large. Even if the number of sites is in the hundreds, a dynamic
`system using an outside certificate authority or in-house certificate server should not involve a great deal
`of management overhead. On the other hand, managing keys for remote users, if they number in the
`thousands, needs to be as scalable and automated as possible. An automated system also is required if
`you plan to use the antireplay protection in IPSec. Distribution of the keys and associated information, in
`particular, may be especially tedious and time-consuming.
`
`Back in Chapter 5, “Using IPSec to Build a VPN,” we pointed out that a pair of IPSec devices has to
`establish a security association with each other in order to communicate. If you’re planning to support a
`large number of remote users with a security gateway, then you’ll need to generate the client security
`
`221
`
`Petitioner Apple Inc. - Exhibit 1024, p.221
`
`

`
`associations centrally and probably in large numbers. The most practical way is to set up a central site to
`generate all IPSec SA parameters needed and to provide a mechanism to import them into the client. For
`example, a central site could generate SA data in S/WAN format and send the appropriate information to
`each client user.
`
`The IPSec architecture is based on the assumption that hosts assign the Security Parameter Index (SP1)
`for inbound lPSec headers, but the essential requirement is simply that inbound SPIS be unique. If you
`set up a central site for generating keying material and assigning the SPIS to use them, then the client
`software can use those SPIs for communications without having to generate any on their own.
`
`‘Previous [Table of Contents |Next
`
`222
`
`Petitioner Apple Inc. - Exhibit 1024, p.222
`
`222
`
`Petitioner Apple Inc. - Exhibit 1024, p.222
`
`

`
`Building and Managing Virtual Private Networks
`by Dave Kosiur
`Networks Wiley Computer Publishing, John Wiley & Sons, Inc.
`ISBN: 0471295264 Pub Date: 09i01!98
`
`‘Previous Table of Contents |Next
`
`Protecting Clients Against Theft
`
`Because laptops are particularly susceptible to theft, they pose a special security risk to your VPN
`because the keys stored on a stolen laptop could be used to access corporate resources via the VPN.
`
`There are essentially three techniques for protecting keys from theft:
`
`1. Store the keys on a removable device like a disk or smartcard and carry it separately from the
`clients.
`
`2. Encrypt the keys with a secret password or phrase and require the client to verify the
`password before IPSec can be used (some smartcards can do this as well).
`
`3. Encrypt the keys with a secret password or phrase and let IPSec processing fail if the wrong
`password is used.
`
`Of these options, the third is the most secure. But, it also can be the most annoying to a legitimate user
`if he accidentally enters the wrong password because he may not be able to discern the reason for a
`communications failure.
`
`Remote VPN users have to be authenticated by security gateways in much the same way as security
`gateways have to identify themselves to each other and be authenticated. The number of options for
`authenticating users are greater, though, and will be covered in the following section. Since the use of
`digital certificates for user identification is becoming more popular and is now being supported by more
`VPN products, we’ll discuss the details of managing certificates for users in “Managing an In-House
`CA” later in this chapter.
`
`Authentication Services
`
`As we discussed in Chapter 4, a variety of ways exist to authenticate users: simple passwords, one—time
`passwords, ehallcngefresponse systems using RADIUS or TACACS+, or two-factor systems using
`tokens, as well as digital certificates. If you’re already supporting remote access via a modern bank and
`remote access server, for instance, then you already may have an authentication system in place and
`you’ll just need to link it to your security gateway to control the authentication and access rights of your
`VPN users.
`
`If you're using PPTP, L2F, or L2TP to create tunnels, you might be using your ISP as a tunnel endpoint,
`as we discussed in Chapters 6, “Using PPTP to Build a VPN,” and 7’, “Using L2TP to Build a VPN.”
`Should that be the case, the ISP should be running its own authentication server, which, in turn, is a
`proxy to your authentication server (see Figure 13.3). This enables you to maintain control over setting
`
`223
`
`Petitioner Apple Inc. - Exhibit 1024, p.223
`
`

`
`authentication parameters and access rights but lets the ISP use that information to provide access to your
`remote users.
`
`Assuming that you may be setting up an authentication system for the first time as you roll out your
`VPN, you can choose from any of the different approaches we mentioned earlier. (See Chapter 4,
`“Security: Threats and Solutions,” for more details.) The better systems are RADIUS, token-based
`authentication, and digital certificates.
`
`RADIUS has three advantages. It’s been standardized by the IETF, and many vendors offer products that
`interoperate. RADIUS also is used by the majority of ISPs for authenticating their customers. Lastly,
`RADIUS can act as a centralized authentication database, drawing on rights defined for users from
`various network operating systems such as NT’s user domains and NDS trees, making it a good platform
`for integration.
`
`Both RADIUS and TACACS+ let you define how to authenticate and pass session variables, such as
`protocol types, addresses, and other parameters. An important feature in both of these systems in the
`capability to define server-based access control policies. These policies can include time-of-day
`restrictions, usage quotas, simultaneous login controls (each user can use only one session at a time), and
`login threshold violations (accounts are looked after X number of consecutive failed logins). RADIUS
`also can be used for accounting purposes, although quota enforcement requires constant tracking of each
`user’s time online and can become a relatively complex task.
`
`‘H
`
`U‘-
`'li‘I'(_}iU_I_5llILI.;-5.I'!o' '_l\_/Iain and proxy authentication serve.
`
`A RADIUS server usually consists of three main files: a database of authorized users, a file of client
`access servers that are authorized to request authentication services, and a set of customized options,
`called dictionaries, for each remote access server or security gateway. If you were configuring RADIUS
`for use with an ISP and PPTP, for instance, you would add the name or address of the ISP’s proxy server
`to the file of client access servers and define a new dictionary for that server, describing any special
`authentication and authorization features for the server. (TACACS+ does not include dictionaries in its
`architecture.)
`
`Token-based authentication usually requires using a special reader attached to the workstation or laptop
`and a token card that generates special passcodes that are checked by a secure server on the network
`before access is granted to the user. Before users are permitted to authenticate themselves, token devices
`request a PIN. Two of the more popular mechanisms for verifying users are a challenge—response system
`(see Chapter 4) or time synchronization, which depends on synchronized clocks and a frequently
`changing secret key that the user has to enter when logging in. Although tokens are a very secure method
`for authentication, because they use a two-factor method (i.e., something the user has—the token
`card—and something the user knows—the PIN), they can prove to be awkward to use because of the
`additional hardware that’s required.
`
`It’s also possible to use digital certificates for authenticating users, although these systems aren’t nearly
`as widespread as RADIUS servers. That’s likely to change with time. Some of your employees already
`may be using personal digital certificates with their Web browsers or e-mail clients. If you’re already
`
`224
`
`Petitioner Apple Inc. - Exhibit 1024, p.224
`
`

`
`sending secure e—mail that requires digital certificates and a public—key infrastructure (see Chapter 4),
`then you could use the same system for issuing and storing the digital certificates required for
`authentication on the VPN. If not, you’ll have to set up an appropriate certificate authority for your users;
`this could be either a commercial CA like Verisign or an in—house certificate server that you maintain.
`
`Using a third-party certificate authority can make certificate management easier, because it’ll be
`accessible via the Internet and would be more readily accessible to any extranet partners. But, if you’re
`supporting only internal users (i.e., corporate employees), an in—house CA should work just fine. Since
`your security gateways will be performing authentication of the VPN’s users, outside access to the digital
`certificates isn’t necessary. But, you’ll still need to secure the computer used for issuing and storing
`digital certificates, as well as any backup files or tapes (see the next section).
`
` IFFBVITEUS
`
`
`Of‘ O1"ll6l'llS lfiext
`
`225
`
`Petitioner Apple Inc. - Exhibit 1024, p.225
`
`225
`
`Petitioner Apple Inc. - Exhibit 1024, p.225
`
`

`
`Building and Managing Virtual Private Networks
`by Dave Kosiur
`Networks Wiley Computer Publishing, John Wiley & Sons, inc.
`
`‘ ISBN: 0471295264 Pub Date: o9ro1r93
`
`{Previous Table of Contents |Next
`
`Whichever course you choose, you’ll need a way to initially distribute to each user the approved digital
`certificates and the private keys they contain. Outside CA5 normally handle certificate distribution via
`e—mail or HTTP. If you’re running your own certificate server, you can do the same, but you also might
`choose a physical means, such as a floppy disk or smart card. Many companies are employing smart
`cards for distributing and storing digital certificates because of their portability and the fact that they also
`can be further secured with a user-specific PIN that makes the card useless if lost or stolen. Plus, these
`cards shut down after a series of failed login attempts.
`
`Managing an In-House CA
`
`Digital certificates have a limited lifecycle (see Figure 13.4); after they’re issued, they should be expired
`after a reasonable period of time (6 months, for instance) or may be revoked if the owner changes jobs or
`his private key is compromised. Certificates also can be renewed and need to be backed up in case keys
`need to be recovered at a later date. If you want to I'l.ll1 your own certificate authority in-house, managing
`the system will involve not only creating key pairs and issuing certificates but also managing those keys
`and certificates. Certificate management includes maintaining a certificate repository, revoking
`certificates as needed, and issuing certificate revocation lists (CRLS). Key management involves key
`backup and recovery, automatic updates of key pairs (and their certificates), and management of key
`histories.
`
`As you plan the deployment of a private certificate server, keep in mind that the infrastructure for digital
`certificates and certificate management is still in a relatively early stage of development. The use of
`CRLs for monitoring revoked certificates is also inadequate for dynamic situations, such as you’re likely
`to encounter with remote users accessing a VPN. But, new solutions, like Online Certificate Status
`Protocol (OCSP), are also under development. Furthermore, commercially available certificate servers
`still need improvement of their support for administrative tasks. In-house CA systems can be purchased
`from Certco lnc., Entrust Technologies lnc., GTE CyberTrust lnc., Microsoft Corp., Netscape
`Communications Corp., Security Dynamics Technologies lnc., and Xcert Software Inc. Some VPN
`product vendors include a CA as an option, although many of these products are software-based CA3
`installed on a workstation. Radguard offers a sealed hardware-based CA for use with clPro.
`
`226
`
`Petitioner Apple Inc. - Exhibit 1024, p.226
`
`

`
`OCS P: A Dynamic Way to Track Certificates
`
`There currently is no practical way to revoke a certificate if the password that unlocks a user’s
`certificate is breached or when the user’s private key is compromised. The only solution certificate
`servers offer right now is the CRL. Ultimately, we’ll be looking to the PKIX standard and OCSP for a
`real solution.
`
`The only way you can use CRLS is by laboriously matching up two lists (the list in your local storage
`and the one in the CRL) and deleting certificates by hand. OCSP moves away from this static—list
`model toward a more dynamic one. OCSP defines LDAP and HTTP status queries that are designed to
`provide fast response time and high availability. In response to a client query, an OCSP server sends a
`simple status message—valid, invalid, revoked, not revoked, or expired. Using this model, the load is
`balanced between the client and the server, and it becomes possible to do real-time certificate checking
`on a per-transaction basis.
`
`Despite these problems, a private certificate server can be installed and managed within your corporation
`to authenticate both security gateways and users on your network. Let’s take a look at some of the
`features that a useful certificate system should include.
`
`The basic task of a certificate server is to accept requests for new certificates, queue them for their
`review by the system administrator, and issue the certificates for client retrieval (see Figure 13.5). In
`general, certificate servers accept certificate requests from a certificate-management workstation, when
`an administrator is performing batch issues of certificates, or from individuals themselves via HTTP or
`e-mail. Whenever new requests for certificates are received, they should be matched against certificates
`held in the directory to prevent accidental obsolescence of valid public keys. The user‘s certificate can be
`presented to its owner via HTTP or e-mail as well, or transferred to a disk or smart card for manual
`distribution.
`
`The private keys of each public-key pair that’s issued should be stored within a central repository that’s
`secured against unauthorized access. This repository also should be backed up in a secure fashion
`(usually as encrypted files), because it becomes part of the key-recovery system should older messages
`need to be decrypted if a key is lost or compromised and revoked. Backup tapes must be carefully
`guarded and strictly accounted for.
`
`Since you’ll be signing all issued certificates as a certificate authority, a special, dedicated workstation
`will need to be set up for storing the private keying material (your root certificate, as it’s called); this
`Same workstation also will include any of the software (and any special hardware, if it’s required) for
`collecting, signing, distributing, and revoking certificates. This workstation should be physically secured
`against unauthorized access; it should not be treated as a multipurpose computer.
`
`‘Previous [Table of Contents {Next
`
`227
`
`Petitioner Apple Inc. - Exhibit 1024, p.227
`
`

`
`Building and Managing Virtual Private Networks
`by Dave Kosiur
`Networks Wiley Computer Publishing, John Wiley & Sons, Inc.
`ISBN: 0471295264 Pub Date: 09i01!98
`
`lPrevious Table of Contents |Next
`
`Because one of the purposes of digital certificates is to distribute a public-key pair, the certificate system
`needs a way of making the public key available to those who need it. The usual method is to store the
`public keys in a directory. Although large-scale master directories for certificates may be based on
`X500, there’s been a significant move to use another protocol, Lightweight Directory Access Protocol
`(LDAP), to utilize much of the structure of X500, but over TCP/IP. Many certificate servers now offered
`for use at corporate sites are based on LDAP. The increasing popularity of LDAP for directory access
`also will make it easier for you to link other directory-based services to your digital certificates.
`
`u
`
`I
`_
`-.—..-1--1
`Fl-C:URl':‘. 13.5 Generating and certifying a public key.
`
`Certificate servers also have to maintain and make available a Certificate Revocation List which lets
`
`users know which certificates are no longer Valid. Certificates may be revoked because they were lost,
`stolen, or because an employee left the company, for example.
`
`For small numbers of digital certificates, a single centralized certificate server will most likely suffice.
`But, if the number of certificates that the company requires is large, using multiple certificate servers
`arranged in some sort of hierarchy (perhaps based on departments) will be more manageable and more
`reliable because the system no longer has a single point of failure. Some certificate servers support
`multiple levels of administration; one group can perform certificate approval and revocation tasks, for
`instance, and another group can perform these functions as well as assign certificate authority to
`subordinate CA3. This makes it possible to set up distributed administration by assigning responsibility
`for a portion of the directory tree to another CA and set of administrators.
`
`You also should be able to set certain parameters for the clients from your central system; these
`parameters should include defaults such as approved directory servers and certificate signers.
`
`The task of supporting user access to certificates will become much easier if your system can support
`more than one method for requesting and receiving a certificate. At a minimum, clients should be able to
`perform these tasks using HTTP, e-mail, and disk files. As we’ve said before, smart cards are also
`becoming an increasingly attractive alternative for distributing and storing digital certificates.
`
`Users should be informed of the need to properly store and protect their certificates. The previous sidebar
`on protecting clients against theft includes some suggestions for protecting their certificates.
`
`Lastly, expect the client software to provide automatic checking of a certificate’s validity using CRL
`
`228
`
`Petitioner Apple Inc. - Exhibit 1024, p.228
`
`

`
`downloads (in the background, for offline use). When OCSP becomes available, look for software that
`supports it so that certificates can be immediately verified online.
`
`Controlling Access Rights
`
`Even though a VPN is architected to provide communications between hosts and security gateways, it‘s
`likely that you’ll still want to maintain some control over the access that each VPN user has to network
`resources. For instance, if sales department personnel are not allowed access to R and D resources when
`they’re on a hard-wired LAN, they should still be restricted from that access if they dial into the VPN
`while they're on the road. This means that you’ll have to merge the control of the new access routes
`provided by your VPN with the access controls currently programmed into your routers and firewalls.
`
`VPN traffic can be handled in two different ways by a firewall, either as unfiltered packets or as filtered
`packets (see Figure l3.6). In the unfiltered approach, the VPN traffic is handled the same way it is in a
`router; that is, the protected data is transferred directly to the internal network without any filtering or
`controls on its contents. In the filtered approach, the firewall’s filter and proxy controls are applied to the
`VPN traffic before it is allowed into the internal network. Filtering VPN traffic can be particularly useful
`if your security policy is to pass only certain types of traffic between VPN sites, say e-mail and FTP.
`Filtering also can be useful for controlling the traffic exchanged with business partners if you expand
`your VPN to an extranet.
`
`FTCUWRE 13.6 Firewalls filtering VPN.
`
`If you place the gateway between the Internet and the router, then the router (and subsequent firewalls)
`can be used to filter both VPN and non-VPN traffic with the same rules; the gateway will provide
`transparent encryption and decryption services to the entire site. Also, the router doesn’t need to be
`reconfigured to pass special tunnel traffic, which is the case when a gateway is installed behind the
`router. One caution: If the gateway is on the public, or untrusted, side of the network, you need to ensure
`that management of the gateway cannot be compromised from someone on the untrusted net. If this link
`is handling both VPN and non-VPN traffic, then the VPN gateway needs to be configured to pass
`non-VPN traffic.
`
`When you locate the gateway behind a router or firewall, the control device would have to be configured
`to pass VPN traffic without filtering. Although this increases the security of the gateway (it’s less
`susceptible to compromising the management port, for instance), it also means that you have less control
`over the traffic entering the LAN after decryption by the gateway. If you want to filter VPN traffic by
`destination, time-of-day, or applica