Network Working Group William A. Nace(NSA) Internet Draft James E. Zmuda(SPYRUS) expires in six months November 21st, 1997 PPP Certificate Exchange Protocol Status of this Memo This document is a submission to the Point-to-Point Protocol Extensions Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as 'work in progress.' To learn the current status of any Internet-Draft, please check the '1id-abstracts.txt' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication of its peer before allowing Network Layer protocols to transmit over the link. The Certificate exchange protocol is an extension to PPP that is Nace & Zmuda Expires in six months [Page 1] DRAFT PPP Certificate Exchange Protocol November 1997 in the form of an additional phase, called the certificate exchange phase, that would allow for a PPP entity to request certificates from a peer. If configured, this phase would be negotiated during the LCP exchange. This exchange of certificates is aimed at easing configuration issues by providing for the exchange of certificate path information in a standard manner across different strong, or public-key certificate-based, authentication protocols. The certificate exchange protocol accomodates arbitrary sized certificates. 1. Introduction In order to establish communications over a point-to- point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase. After the link has been established, we are suggesting that the PPP provide for an optional Certificate Exchange phase before proceeding to the Authentication phase. By default, this certificate exchange phase will not be mandatory. If the certificate exchange phase is configured into a PPP entity, and negotiation with the peer has concluded that it can be supported by the peer, then the certificate exchange protocol will be performed after the LCP phase and before the Authentication phase. If the certificate exchange protocol is desired, an implementation MUST specify the Certificate-Exchange-Protocol Configuration Option during Link Establishment phase. Of course, if no Authentication Protocol is negotiated during the Link Establishment phase, or one that does not use strong authentica- tion that requires the type of certificate that we have obtained, then the product of the Certificate Exchange protocol will have been wasted. However, this is to be avoided through proper configuration and properly forming certificate exchange requests and responses. This means primarily two things: First, the in the initial certifi- cate exchange request, the requestor shall send the algorithm iden- tifier for the certificate type in which he is interested, as well as his distinguished name. Second, the responder shall include a certi- ficate (if available) in his reply that supports the algorithm iden- tified in the request, and that is within the naming hierarchy indi- cated by the requestor's distinguished name. These procedures will insure that the information retrieved by the certificate exchange protocol is relevant. Nace & Zmuda Expires in six months [Page 2] DRAFT PPP Certificate Exchange Protocol November 1997 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective required, means that the definition is an absolute requirement of the specifi- cation. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective recommended, means that there may exist valid reasons in particular cir- cumstances to ignore this item, but the full implica- tions must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective optional, means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementa- tion which does include the option. 1.2. Terminology This document frequently uses the following terms: certificate A certificate consists of the binding together of one or more public key values and an identity. This bind- ing is effected through a digital signature which is applied to the data containing both the public key and the identity. This signature is applied by a "certif- ication authority" that is recognized as issuing this certificate on behalf of the entity identified in the certificate. In this manner a recipient of this certi- ficate can determine the recognized public key of the particular entity identified in the certificate. This requires the recipient to, either directly or indirectly, trust the authority that has issued this certificate. certificate validation An individual certificate provides the recipient of a certificate the assurance that the subject named in the certificate is the holder of the public key con- tained in the certificate. However, this assurance Nace & Zmuda Expires in six months [Page 3] DRAFT PPP Certificate Exchange Protocol November 1997 requires that the recipient trust the issuer of the certificate. If the recipient doesn't directly trust the certificate issuer, the recipient will attempt to establish that trust by reviewing and validating the certificate of the issuing authority itself. This process continues until the recipient arrives at an issuer whom it does trust. If this process is suc- cessful, the certificate is validated. If this pro- cess is unsuccessful within a certain number of steps the certificate is not validated. This process of validation of a chain of certificates is called certi- ficate validation. certificate pathThe chain of certificates examined during certificate validation. certification authority (CA) An authority trusted by one or more users to create and assign certificates. [2]. distinguished name A unique hierarchical name. Used in the certificate's "subject" field to denote the entity associated with the public key value(s) in the certificate[2]. Also used in the certificate's "issuer" field to denote the entity that issued this certificate. peer The other end of the point-to-point link. Requestor The end of the link initiating the Certificate Exchange. It does this by sending the peer a Certifi- cate Exchange Request packet. 2. PPP Certificate Exchange Protocol The Certificate Exchange Protocol is a general protocol in support of public-key based PPP authentication protocols. The gating issue with respect to the deployment of public-key based authentication protocols is the establishment of infrastructure. Two types of infrastructure are needed. The first is the ability to issue certificates. This relies upon the availability of certificate authorities with the means to adequately verify legitimate users before issuing them certificates. The second type of infrastructure is a method to distribute these certificates to the necessary parties, who are engaged in Nace & Zmuda Expires in six months [Page 4] DRAFT PPP Certificate Exchange Protocol November 1997 certificate-based strong authentication. There are a number of ways that this can be accomplished in practice. The first, and obvious method is to require that all parties who wish to employ certificate/public-key based authentication have a complete database of all the certificates required to authenticate any desired peer. Another alternative would be to utilize one of the many access proto- cols to retrieve a required certificate from a directory service. Another method would be to require security protocols to transfer certificates during the authentication exchange. None of these options is particularly attractive or even applicable for the case of PPP certificate-based authentication protocols. The use of a pre-configured database is a possible but limited approach. The use of a directory service is not feasible due to the point in time at which PPP authentication protocols are run, namely during the authentication phase. At this point in time the connectivity needed to reach a directory service has not yet been achieved. The current approach used within certificate-based authentication in PPP is to saddle the authentication protocol with the task of exchanging the certificates required to authenticate a peer. This is problematic. The reason is that more data than can be conveyed in a single PPP packet may be required to be exchanged, and the PPP proto- cols, running at the level they are and in the simple request response fashion they do, do not immediately lend themselves to con- veying large amounts of data. The authors suggest that a better option is for the PPP authentica- tion protocols to worry about authentication and another protocol to perform the exchanges of certificates required to support certificate validation. The Certificate Exchange protocol is such a protocol. The Certificate Exchange Protocol is a challenge- response protocol. The initiator starts the protocol by sending the peer an initial exchange packet. The peer is to respond to this request with an ini- tial exchange response packet containing his own certificate. The initiator then determines if he has the information required to vali- date this certificate. [See the definition of certificate valida- tion, above.] If the initiator does not possess such information, he issues another certificate exchange request packet. This packet, however is a "DName Specified" request packet. In this packet the initiator puts the Distinguished name of the entity whose certificate he requires to complete the next step in the certificate validation process. The peer is to respond to this request with the certificate Nace & Zmuda Expires in six months [Page 5] DRAFT PPP Certificate Exchange Protocol November 1997 for the entity named in the request. If this certificate itself requires another certificate in order to be validated, the initiator issues yet another Certificate Exchange Request packet with DName of the entity whose certificate is required to validate this certifi- cate. This process continues until the complete certificate path for the peer has been validated. The protocol also has additional request/response types to handle the case of a certificate that is itself too large for one PPP packet. 3. PPP Certificate Exchange Protocol Packet Format The Certificate Exchange protocol is accomplished using two different packet formats: a Request packet format and a Response packet format. Both the Certificate Exchange Request and Response packets have the following common format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Type Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3.0-1 - The Certificate Exchange protocol packet format Code 1 (Request) 2 (Response) Identifier The identifier field is one octet and aids in matching responses with requests. The identifier field MUST be changed on each Request packet containing a different DName value. Length The Length field is two octets and indicates the length of the Certificate Exchange Request and Response packets including the Code, Identifier, Length, Type, and Type Data fields. Octets in the packet outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. Nace & Zmuda Expires in six months [Page 6] DRAFT PPP Certificate Exchange Protocol November 1997 Type 1 (Initial Exchange) 2 (DName Specified Exchange) 3 (Certificate unavailable) 4 (Partial Certificate Request/Response) Type Data Depending upon the setting of the type field, the Request packet will either use this field to carry the algorithm ID and DName from its own certificate (in the case of an Initial Exchange), or will use this field to specify the DName of the certificate being requested (in the case of a "DName Specified" Exchange). The Response packet uses this field to hold the certificate value. The length of this field is inferred from the length field for this packet as a whole. In the event the responder must reply to a request (either Initial, or DName-specified) with a certificate that is too big to fit within the current PPP MTU, the certificate exchange protocol will respond with a "Par- tial Certificate" response type packet. This format allows the responder to return a partial certificate and indicate the amount remaining. Subsequent "Partial Cer- tificate" Requests and Responses will be used to transfer the complete certificate. The following sections define the format of the various request and response packets used in the certificate exchange protocol. The first to be dealt with are the PDUs exchanged during the retrieval of complete certificates. Following this are the PDUs required to support retrieval of certificates too large to fit within the current PPP MTU. 3.1. Certificate Exchange Protocol Request Packet The Certificate Exchange Protocol Request Packet is formatted as fol- lows: Nace & Zmuda Expires in six months [Page 7] DRAFT PPP Certificate Exchange Protocol November 1997 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | AlgIDLen | AlgorithmID... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...AlgorithmID... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |...AlgorithmID | DName... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3.0-2 - Certificate Exchange Protocol Request Packet format Code 1 (Request) Identifier The identifier field is one octet and aids in matching responses with requests. The identifier field MUST be changed on each Request packet containing a different DName value. Length The Length field is two octets and indicates the length of the Certificate Exchange Request packet including the Code, Identifier, Length, and Type, Algorithm ID, and DName fields. Octets in the packet outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. Type 1 (Initial Exchange) 2 (DName Specified Exchange) AlgIDLen Indicates the length of the AlgorithmID field. AlgorithmID If the type field is set to a 1, indicating an "Initial Exchange" then this field will contain the Algorithm Identifier from the Certificate that the requestor will Nace & Zmuda Expires in six months [Page 8] DRAFT PPP Certificate Exchange Protocol November 1997 use during the authentication phase. This field is car- ried in its raw ASN.1 form, right out of the certificate. On the other hand, if the type field is set to a 2, indicting this is a subsequent request, then this field will not be present. This is indicating by a value of 0 in the AlgIDLen field. DName If the type field is set to a 1, indicating an "Initial Exchange" then this field contains the DName from the certificate that the requestor will use during the authentication phase. On the other hand, if the type field is set to a 2, indicting this is a subsequent request, then this field will contain the DName of the entity whose certificate is being requested. 3.2. Certificate Exchange Protocol Response Packet The Certificate Exchange response packet is formatted as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Certificate... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3.0-3 - Certificate Exchange Protocol Response Packet format Code 2 (Response) Identifier The identifier field is one octet and MUST match the Identifier field from the corresponding request. Length The Length field is two octets and indicates the length of the Certificate Exchange Response packet including the Code, Identifier, Length, and Type, and Certificate fields. Octets in the packet outside the range of the Length field should be treated as Data Link Layer padding Nace & Zmuda Expires in six months [Page 9] DRAFT PPP Certificate Exchange Protocol November 1997 and should be ignored on reception. Type The Type field in the Response can carry either the value 1 (signifying an initial certificate exchange request) or the value 2 (signifying a subsequent certificate exchange request), or the value 3 (signifying a retrieval failure). Certificate The Certificate field contains the complete ASN.1 encoded X.509 certificate for the entity named in the Certificate Exchange request that this response corresponds to. In the case there was no entity named in the Certificate Exchange request (e.g. an Initial Certificate Exchange Request) the responder will choose a certificate to use to send to the requestor. The type of certificate returned should correspond to the type of algorithm indi- cated by the Requestor in the Initial Exchange Request. The public key in this certificate should correspond to the private key that will be used in any subsequent EAP authentication operations. A type value of 4 indicates a "Partial Certificate" response. This format is described in section 3.3. 3.3. Certificate Exchange Protocol "Partial Certificate" Response Packet The Certificate Exchange "Partial Certificate" response packet is formatted as follows. Nace & Zmuda Expires in six months [Page 10] DRAFT PPP Certificate Exchange Protocol November 1997 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | CertOffset... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...CertOffset | CertTotLen... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |...CertTotLen | DName Length | DName... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...DName | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Certificate Segment... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3.0-4 - Certificate Exchange Protocol "Partial Certificate" Response Packet format Code 2 (Response) Identifier The identifier field is one octet and MUST match the Identifier field from the corresponding request. Length The Length field is two octets and indicates the length of the Certificate Exchange Response packet including the Code, Identifier, Length, and Type, and CertOffset, Cert- TotLen, DName Length, DName, and Certificate fields. Octets in the packet outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. Type The Type field in the "Partial Certificate" Response will carry a value of 4, or the value 3 (signifying a retrieval failure). CertOffset The CertOffset, or "Certificate Offset" field contains the offset within the entire certificate of the segment Nace & Zmuda Expires in six months [Page 11] DRAFT PPP Certificate Exchange Protocol November 1997 carried within this partial response. CertTotLen The CertTotLen, or "Certificate Total Length" field con- tains the length of the entire certificate, of which only a portion is carried in this partial response. DName Length The Length of the DName field in bytes. DName This field contains the DName field from the Certificate, whose segment is being carried in the Certificate Segment field. This is present to facilitate the Requestors for- mation of the subsequent "Partial Certificate" Requests required to retrieve the complete Certificate. Certificate Segment The Certificate Segment field contains as much of the complete ASN.1 encoded X.509 certificate that can be car- ried within the current PPP MTU-sized packet. 3.4. Certificate Exchange Protocol "Partial Certificate" Request Packet The Certificate Exchange "Partial Certificate" request packet is for- matted as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | CertOffset... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...CertOffset | CertTotLen... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |...CertTotLen | DName Length | DName... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...DName +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3.0-5 - Certificate Exchange Protocol "Partial Certificate" Request Packet format Nace & Zmuda Expires in six months [Page 12] DRAFT PPP Certificate Exchange Protocol November 1997 Code 1 (Request) Identifier The identifier field is one octet and aids in matching responses with requests. The identifier field MUST be changed on each Request packet containing a different DName value. Length The Length field is two octets and indicates the length of the Certificate Exchange Response packet including the Code, Identifier, Length, and Type, and CertOffset, Cert- TotLen, DName Length, and DName fields. Octets in the packet outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. Type The Type field in the "Partial Certificate" Request will carry a value of 4. CertOffset The CertOffset, or "Certificate Offset" field contains the offset within the entire certificate of the certifi- cate segment being requested. CertTotLen The CertTotLen, or "Certificate Total Length" field con- tains the length of the entire certificate. DName Length The Length of the DName field in bytes. DName This field contains the DName field from the Certificate, whose segment is being requested. Nace & Zmuda Expires in six months [Page 13] DRAFT PPP Certificate Exchange Protocol November 1997 4. Certificate Exchange Protocol Processing During the certificate exchange phase, a PPP entity that is config- ured to use the certificate exchange protocol will initiate the Cer- tificate Exchange protocol. The Certificate Exchange protocol is a series of REQUEST/RESPONSE exchanges. The PPP entity configured to perform the Certificate Exchange protocol, or "initiator", will send REQUEST packets requesting the peer send it a certificate. In the initial exchange the initiator will send a initial Certificate Exchange request asking the peer for its current certificate. The Requestor will place its own certificate in this outgoing Initial Exchange Request. The reason for this is so that the Responder will know which, compatible type of certificate of the many it may have available to send back in the Response. Next, the peer will reply with a response packet containing its certificate of the appropriate type, it available. If not, it will return a Response packet with a type field indicating a retrieval failure. The initiator will then determine if this certificate can be validated with the information it currently has. (If it has the complete path to a common trust point that this certificate requires.) If the initiator decides it has sufficient information to validate this certificate, it finishes the certificate exchange protocol phase and continues to the authen- tication phase. If, on the other hand, the initiator does not have enough information to validate this certificate, it sends another Certificate Exchange protocol request packet to the peer requesting the certificate (or the first certificate of a number of certifi- cates) which it is missing in order to complete validation. This process continues until the complete path has been obtained. The Cer- tificate Exchange protocol is unilateral in that the requests are in one direction only. If the peer PPP entity requires certificates to accomplish authentication then that peer should also be configured to perform the certificate exchange protocol. In the event that the type field of a certificate response contains a 4 - indicating that the data field contains a partial response, the requestor will use a partial certificate request type packet to request the next segment in the certificate. The segment requested is indicated in the partial certificate request by indicating the byte offset within the total certificate of the next segment of the certificate. The exchange of these request-response pairs continues until the requestor is satisfied that it has retrieved the entire certificate. Then processing continues, if necessary, to retrieve the complete certificate path as in the normal case, above. Figure 4.0-1 depicts the operation of the Certificate Exchange proto- col. (For the purposes of this example, it is assumed that the cer- tificates fit within a single PPP packet) In this figure depicting protocol exchanges, the curly braces ({, }) denote items in ASN.1 Nace & Zmuda Expires in six months [Page 14] DRAFT PPP Certificate Exchange Protocol November 1997 representation. Side: B A Authenticator Authenticatee CRTXCHG Request (ID1, Initial Exchange, {certB}) => <= CRTXCHG Response(ID1, Initial Exchange, {certA}) CRTXCHG Request (ID2, DName Specified, {DName}) => <= CRTXCHG Response(ID2, DName Specified, {Cert(DName)}) Figure 4.0-1 Certificate Exchange protocol processing Security Considerations This memo defines a method for exchanging certificates to be used to support public-key based authentication protocols, which rely upon the validity of the public key used to verify signatures from the peer. The validity of these public keys is vouched for by having the certificates that bind them to an identity signed for by either a directly or indirectly trusted third party. Obviously, the security of such a system depends upon there being some common trust point between the parties. References: [1] Simpson, W. A., 'The Point to Point Protocol (PPP)', July 1994, RFC 1661. [2] CCITT Recommendation X.509, 'The Directory - Authentication Framework', 1988. Acknowledgements: Thanks to Peter Yee and Russ Housley who provided helpful comments on earlier versions of this Memo. And thanks to Bill Simpson for the standard PPP spec boilerplate from which I have borrowed heavily. Nace & Zmuda Expires in six months [Page 15] DRAFT PPP Certificate Exchange Protocol November 1997 Chair's Address: The working group can be contacted via the current chair: Karl Fox Ascend Communications, Inc. Email: karl@ascend.com Author's Address: Questions about this memo can also be directed to: DIRNSA Attn: X22 (W. Nace) 9800 Savage Road Fort Meade, MD 20755-6000 USA Phone: +1 410 859-4464 Email: WANace@missi.ncsc.mil James E. Zmuda SPYRUS 2460 N. First Street Suite 100 San Jose, CA 95131-1023 USA Phone: +1 408 432-8180 Email: jzmuda@spyrus.com Nace & Zmuda Expires in six months [Page 16]