[Double fax headers on all pages except last; omitted hereafter.]
03/03/97 MON 10:51 FAX 202 456 9340 INTEL PROGRAMS >>>EDFORS [PAGE #] SENT BY:Xerox Telecopier 7021 : 2-28-97 : 12:58 : -> 202 456 9340: # [PAGE]
STEPTOE & JOHNSON LLP |
||
| PHOENIX, ARIZONA FACSIMILE: (602) 257-5299 VERIFICATION: (602) 257-5287
MOSCOW, RUSSIA |
1300 CONNECTICUT AVENUE, N.W. |
XEROX 7032 (202) 429-3902 |
(202) 429-3000 |
||
|
IMPORTANT: This facsimile is intended only for the use of the individual or entity to which it is addressed. It may contain information that is privileged, confidential, or otherwise protected from disclosure under applicable law. If the reader of this transmission is not the intended recipient or the employee or agent responsible for delivering the transmission to the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this transmission or its contents is strictly prohibited. If you received this transmission in error, please notify us by telephoning and return the original transmission to us at the above address.
|
||
FROM Name: PETER LICHTENBAUM
Name: ED APPEL and BRUCE MCCONNELL Organization or Firm: NATIONAL SECURITY COUNCIL Telecopy Phone Number: 456-9340 Verification Number :
Special Instructions Total Pages & Cover Sheet: 16 Date Transmitted: S&J Operator's name: CJACKSON Telephone Number: 202-429-8052 Client/Case Number: 112190001
|
||
STEPTOE & JOHNSON LLP |
||
PHOENIX, ARIZONA
TELEPHONE: (602) 257-5200
PETER LICHTENBAUM |
1300 CONNECTICUT AVENUE, N.W.
(202) 429-3000 |
STEPTOE & JOHNSON INTERNATIONAL
TELEPHONE: 011-7-501-258-5850 |
MEMORANDUM
February 28, 1997
BY FACSIMILE
TO: Ed Appel
National Security Council
Bruce McConnell
Office of Management and Budget
FROM: Peter Lichtenbaum
RE: Netscape -- Taher Elgamal Presentation
_________________________________________________________________
In connection with Taher Elgamal's presentation to the
Inter-agency Working Group (IWG) on Monday afternoon, attached is
a copy of a paper that provides the basis for his presentation.
Please give me a call if you have any questions.
Best regards,
Enclosure
[Note: paragraph numbering is irregular in original; figures rough due to multiple faxes]
[nscp-1]
"Key Recovery and Export Licensing Proposal"
Taher Elgamal
Amended Version 0.9 - February 19, 1997
DRAFT - Netscape Confidential
[By hand:] (Netscape counsel agreed with release.)
Introduction
This is a proposal from Netscape Communications Corporation regarding key recovery features in its client and server products. A business timeline is included.
Executive Summary
The key recovery proposal consists of two separate parts. The first part addresses the secure mail (S/MIME) keys (and keys for other local applications) and the second part addresses the SSL keys and related issues. Where possible, Netscape plans to offer voluntary recovery features for some encryption private keys. Corporate customers can define their own key recovery policies. They may decide to require key recovery for email applications as well as any other application that stores encrypted files on local or network disks.
Support for escrow of encryption private keys may be achieved as follows: Netscape client and server products offer Certificate Authorities the capability to only issue a certificate after the private key has been escrowed with an entity chosen by the Intranet administrator for security policy. The certificate will indicate that the corresponding private key has been escrowed.
The proposed plan for SSL does not use explicit escrow for SSL keys at the client or the server sides. Rather, since SSL only encrypts data between the client and the server such that the decrypted data is available on the server (and clients in some cases), other entities can obtain the data from the server directly in the case access to the plain text data is needed.
[Footer at 14 nscp-pages; hereafter omitted:]
Contains Netscape Proprietary Information - Not Subject to Release
Under FOIA
[nscp-2]
2. Executive Summary (Cont'd)
The main point stressed here is that key recovery is useful for applications that enable storage of encrypted data and should be offered (as an optional feature) in a product line, but may not actually provide the desired result in some other applications. A plan that attempts to escrow all keys under all scenarios is perhaps too general and will face issues with scalability, distribution and legal issues with the escrowed private keys.
Recovery of Encrypted Secure Email Messages and Encrypted Data Files
This section outlines the steps involved in providing key or data recovery services for Secure Email and other applications that store encrypted data, for use by companies and other Intranet situations.
Figure 1 depicts the basic steps for issuing digital certificates while saving the encryption private keys. The escrow entity is not necessarily the same entity as the Certificate Authority since the two functions carry different scopes of responsibility. However, a company can decide to make them the same. An Intranet is defined here to be any group of end users that would like to connect certain servers, such as inside an enterprise or online banking servers.
The same options can be offered to end users that do not necessarily belong to an Intranet through optional services from ISPs and others. This can be sold as a method for the end user to retrieve their private keys in case of loss of a password or a similar event.
It is important to point out that the discussion here is specific to private keys that are used for encryption or key exchange only. These keys are used for the sole purpose of providing confidentiality features, rather than for authentication or integrity purposes. In no system will escrow or recovery services be offered for signature private keys.
[nscp-3]
3. Recovery of Encrypted Secure Email Messages and Encrypted Data Files (Cont'd)
The products will offer users the capability to distribute the private keys
among several people or entities in case recovery is needed. Utilization
of this feature will be a policy option for the administrator of the Intranet.
Such a policy may require the collaboration of any M out of N
people to collaborate in order to use the private key for recovery of stored
encrypted data.
Figure 1
Enforcing the use of escrow
It will be possible for an enterprise to enforce a key recovery policy through policy modules that force the client to use a certain level of encryption only when all the recipients of the message have keys escrowed at a particular location (or locations). This is achieved using a trust policy module that offers the following options:
-
Program the clients (and servers) in an Intranet to only trust certain CAs for issuing certificates and certain locations for providing key escrow functions. these features can be restricted by a company, country or any other useful domain.
-
Program the clients (and servers) to only submit certificate requests to certain locations. This gives Intranets control over the ownership of the clients' private keys.
[nscp-4]
3.1 Enforcing the use of escrow (Cont'd)
User profiles are exchanged between correspondents as signed messages so
that each user can determine the capabilities and policies of the other
recipients. The combination of the certificate and user profiles determine
the bit length used to encrypt the message. For example, Figure 2 provides
an illustration of a secure email exchange where the recipient's encryption
private key is escrowed. The sender checks the local policy and starts the
process as illustrated.
Figure 2
Accessing Encrypted Email and files
The encrypted files and stored (or intercepted) email messages can be retrieved using the following procedure. After receiving a required form of proof of the right to get the data, the escrow facility uses its private key to internally retrieve the appropriate keys and uses those to retrieve the file or email message encryption keys used to encrypt the data. The private keys should never be exposed even to administrators, rather the system should automatically produce the message encryption keys. Either party can then decrypt the encrypted data to obtain the original plain text data.
[nscp-5]
3.2 Accessing Encrypted Email and files (Cont'd)
For example, Figure 3 depicts a process by which such access may take place.
The specific processes will be determined by the local policies, economics
and business models of the different parties.
Figure 3
Subsequent to the recovery request being processed, whether or not it is
accepted, both sides must keep records of all such activities for liability
and accounting purposes.
[nscp-6]
Certificate formats
The certificates used in the email system or for local stored files operations include the following special fields to reflect the fact that the corresponding private key has been escrowed.
-
Escrow Flag indicating that the key is a key exchange or encryption key and is escrowed using the X.509 extension mechanism.
-
URL for the entity that performed the escrow can be the same as the CA or different, the URL may represent multiple parties that have to cooperate to produce the keys if an M out of N scheme for storing the private keys.
-
Some indication of the Intranet affiliation. This field may be used by some countries to verify the location of the escrow.
Secure Socket Layer (SSL) Recovery Tasks
The other major use of encryption in Netscape's products is the use of the SSL protocol to connect clients to a variety of servers such as the web (Enterprise) server, the Collabra (News) server or the mail (Messaging) server. SSL is basically used for securing the connection between the client and the server and not for any encryption on the server (or the client) itself. Some servers support SSL currently while others will include the SSL support in the future.
There is no explicit support for escrowing SSL keys in this proposal for the reasons outlined below. However, SSL session data can still be acquired with the appropriate authorization. The mechanism for acquiring SSL session data is describe first, with the remainder of the section devoted to the issues involved if we were to explicitly escrow SSL session keys for either the client or the servers. There are also general issues involved in the use of escrow in protocols that use encrypted communications, but those details are outside the scope of this document.
[nscp-7]
Proposal for accessing data communicated using the SSL protocol
The main point stressed in this section is that SSL does not encrypt the data on any machine, and therefore will not prevent any law enforcement agency or other entity that needs access to the data from obtaining that access through the server. The key points are summarized below:
-
In the majority of the cases, an SSL session allows clients access to data on a server. SSL session keys are not necessary to access encrypted data.
-
Controlling sales of SSL-enabled servers to countries and companies that are established as "good citizens" will restrict clients' access to servers with strong cryptographic support.
-
Some restrictions on the Certification Authorities allowed to be trusted by the client may be necessary to enforce this policy.
-
In this model, the availability of the data on the server obviates the need for inline decryption during transmission, if recovery of the data is needed.
Issues with escrowing keys in the SSL protocol
There are many technical reasons that prevent a practical system for escrowing SSL keys while maintaining the integrity and the performance of the system.
Sessions Keys in SSL:
The SSL session keys are generated using some known numbers to the client and the server in lock step. The SSL protocol does not actually send the session keys at all. This is both for performance and security reasons.
If the SSL protocol were to be modified to allow for sending encrypted versions of the session keys, the performance impact on the clients and servers would be so high that most customers will try to find alternative solutions. This due to the known fact that public-private key operations consume most of the time during the establishment of a secure session. To achieve the escrow functionality, the client and server software will have to, during each session or group of sessions, perform additional public and/or private key operation[s] to encrypt message keys using keys of escrow entities. There is also additional overhead in verifying the validity of the escrow entity of both the client and the server which requires yet more public-private key operations as well as making policy decisions on how many bits of encryption keys to use.
[nscp-8]
4.2.1 Sessions Keys in SSL (Cont'd)
There is also a security problem involved with sending a lot of keys encrypted under a single public key for the escrow entity. The private key of the escrow entity will become a target for all "hackers" and code breakers who will have a lot of plain text - cipher text pairs to work from.
Master Secrets in SSL:
The Master Secrets in SSL are used by the clients and servers to generate both the session keys (used for encryption) and the Message Authentication Code (MAC) secrets used to produce the MAC to ensure integrity of the SSL records. Note: If the Master Secret[s] were to be escrowed, the holder of the escrow keys would be able to make a modification of the original session that would look authentic. That activity makes the session basically invalid since it is easily repudiated by the owner of the key claiming that the escrow entity performed the modification to the session.
Server Private Keys in SSL:
The SSL server private key is used by the client to perform the exchange of the Master Secret. This may appear to be a key exchange function. However, the result of a correct reception of the Master Secret by the server automatically authenticates the server to the client. Thus, the SSL server private key also serves as an authentication key which makes the escrow function invalid because the authentication key is easily repudiated by the owner of the key claiming that the escrow entity performed the signature.
Note that escrowing a signature or an authentication private key should not be considered by any system. That activity makes a signature basically invalid since it is easily repudiated by the owner of the key claiming that the escrow entity performed the signature.
Client Private Keys in SSL:
The SSL client private keys are only used for signatures and thus not suitable for escrow. Besides, knowing these keys does not provide any capability to obtain the plain text data.
Unauthenticated Clients in SSL:
This is perhaps the SSL feature that makes escrow of any keys that control the SSL traffic unusable. Today, the vast majority of the SSL sessions do not use client authentication. That implies that even with the acquisition of all the data during a particular SSL session, there really is no deterministic way of linking a session to any particular client or person. Unlike phone tapping, there is nothing in the SSL to track down that would let anyone recognize the client (person). Depending on IP addresses, DNS names or any other Internet-based quantity is never guaranteed to provide enough data to find a link to a particular person.
[nscp-9]
4.2.5 Unauthenticated clients in SSL (Cont'd)
The only practical way, it seems, is to get to the server and check whether the session is linked to some user name - password recognized by the server for some authentication of the client. Since getting to the server is the only real practical way to get enough information about the client, then an appropriate policy is a mechanism to obtain copies of the entire sessions with particular clients, if the server is informed by the law enforcement agency or other interested entity about the activities of a particular individual or group.
Time Line and Business Issues (Milestones for 1998/1999)
The current (and future) product offerings from Netscape fall under the appropriate class of products that provide data recovery for SSL sessions according to the definitions in the previous sections. The SSL offerings in the various Netscape servers will continue to grow, but will always support the same paradigm of the availability of the data on the server.
As far as the S/MIME key recovery mechanism discussed earlier, the implementation plan goes as follows:
Q1 98 - Planned first introduction of a Certificate Server with recovery capabilities.
Q2 98 - Planned introduction of S/MIME clients with basic recovery features; may not have all options for programming and configuring the email client for all possible policies.
Q1 99 - Planned implementation of more robust recovery features; also support for local file encryption applications.
Netscape will assign appropriate engineering, marketing, test and documentation resources to the above goals. Implemented data recovery features will be marketed to the customer base as well as new customers. Implementation of encryption private key escrow in the certificate server product will be according to the description in this document. Other servers and the client products will utilize the recovery features as they fit.
[nscp-10]
Other Export Related Matters
The following two sections outline the proposed architecture for the coming and following generations of Netscape products. We would like to obtain export licenses for these items for the upcoming releases of the client (Netscape Communicator) and server products.
These items are not directly tied into key recovery, but are included here for the purpose of obtaining the approvals to get export licenses on next generation products in a structured way. This architecture also provides us with a single product build that will simplify and streamline the product building process.
The Cryptography Configuration Module (CCM)
The CCM is a file signed by Netscape that provides the product installation with enough information about the allowed key lengths for the various applications requiring cryptography.
The overall format is a text file, which is digitally signed and packaged in a signed archive (JAR) file. The file consists of a sequence of lines of text. Each line contains a name/value part in the format NAME=VALUE. For each possible application/algorithm combination there will be a NAME/VALUE pair, where NAME describes the application/algorithm combination, and VALUE is a Boolean. A value of true indicates that the algorithm is allowed, and value of false indicates that it is not supported. In addition to Boolean values for crypt algorithms, other Boolean and string values are supported.
The format of the CCM is outlined below:
| Application #1 (e.g. SSL) | |||
| Version | |||
| Algorithm suite #1 | Number of key bits (arbitrary for SSL) | ||
| Algorithm suite #2 | Number of key bits (arbitrary for SSL) | ||
[Omit duplicate of preceding page; apparently generated by restart of fax transmission as indicated by 16 minute time gap and restart of fax page numbering.]
[nscp-11]
6.1 Cryptography Configuration Module (CCM - (Cont'd)
| Application #2 (e.g. S/MIME) | |||
| Version | |||
| Algorithm #1 | Number of key bits (56 bits for symmetric) | ||
| Algorithm #1 with recovery | Number of key bits (arbitrary with recovery) | ||
| Algorithm #2 | Number of key bits (512/1024 for public key) | ||
| Algorithm #2 with recovery | Number of key bits (arbitrary with recovery) | ||
| Application #3 (e.g. Crypto APIs) | |||
| Version | |||
| Algorithm #1 | Number of key bits (56 bits for symmetric) | ||
| Algorithm #1 with recovery | Number of key bits (arbitrary with recovery) | ||
| Algorithm #2 | Number of key bits (512/1024 for public key) | ||
| Algorithm #2 with recovery | Number of key bits (arbitrary with recovery) | ||
| Countries of use
Enforcement flags Signature of Netscape |
|||
[nscp-12]
6.1 Cryptography Configuration Module (CCM - (Cont'd)
The following table gives a specific example of an SSL section in a domestic CCM:
SSL2-RC4-128-WITH-MD5=true
SSL2-RC4-128EXPORT40-WITH-MD5=true
SSL2-RC2-128-CBC-WITH-MD5=true
SSL2-RC2-128-CBC-EXPORT40-WITH-MD5=true
SSL2-DES-64-CBC-WITH-MD5=true
SSL2-DES-192-EDE3-CBC-WITH-MD5=true
SSL3-RSA-WITH-NULL-MD5=true
SSL3-RSA-WITH-RC4-128-MD5=true
SSL3-RSA-WITH-3DES-EDE-CBC-SHA=true
SSL3-RSA-WITH-DES-CBC-SHA=true
SSL3-RSA-WITH-RC4-40-MD5=true
SSL3-RSA-WITH-RC2-CBC-40-MD5=true
SSL3-FORTEZZA-DMA-WITH-FORTEZZA-CBC-SHA=true
SSL3-FORTEZZA-DMS-WITH-RC4-128-SHA=true
SSL3-FORTEZZA-DMS-WITH-NULL-SHA=true
The countries of use field is used as an extra check for improper exportation or importation of a CCM in a wrong country. This field can be checked against the country fields in certificates or escrow entity fields in certificates.
The enforcement flags can be used in certain countries according to local policies.
[nscp-13]
Cryptographic Service Provider (CSP) Interface
Netscape products will use a PKCS #11 interface for CSP's to attach to clients or servers to provide cryptographic functions. Refer to PKCS #11 specifications for more details. For export purposes the following measures are taken to address proper operation under the export laws.
-
The manufacturer of the CSP signs the code implementing the CSP or the driver to the CSP hardware. This is done to ensure integrity of the CSP. There is no guarantee here for the CSP vendor obtaining export license. Rather, the Netscape product itself will monitor the combination of the CSP with Netscape products as described above so that the CSP provides the cryptographic support allowed by the export laws of the various countries.
-
Each application in the Netscape product determines the key length allowed from the configuration file under that application after verifying the Netscape signature on the CCM.
-
The application code filters the requests from the application to the CSP to provide the appropriate key length, even if the CSP supports higher grade encryption.
-
When the CSP first attaches to the Netscape software, a check is made on the encryption routines supported by comparing the output of encrypting a test vector with the correct output for that algorithm. This mechanism is so the CSP does not advertise the "DES" capability, for example with a rogue implementation that attempts to avoid export laws.
[nscp-14]
6.2 Cryptographic Service Provider (CSP) Interface (Cont'd)
The following diagram, Figure 4, outlines the proposed architecture of the
exportable versions of Netscape next generation products. This architecture
uses a combination of key recovery, the Cryptographic Configuration Module
and the filtering software so that only approved products work with the Netscape
product offerings under the various export (and import in some cases) laws.
Figure 4 The Architecture of Exportable Netscape Products
[End Netscape presentation]
[Partly legible fax header; x=illegible]
xxxxxx Xerox Telecopier 7021 xxxxxxx12:08 2024299304 33 x 4024 xxxxx
[By hand:] P126B
Distribution Arrangements Covering Strong Encryption/Remarks #1 Ref. 913-96 Strong Encryption for Corporate Networks:
92 Fortune 500 Companies
-Filed 08 Aug96; with Joyce/NSA 19 Aug96
-New list of S/W and new algorithms Faxed to Joyce
-NSA Meeting @ NSCP 23 SEP96
-NSA Meeting @ NSCP 15 OCT96
-After discussion, we made amendments listing new S/W Quantities/Values,
waiver of DSP-5 & DSP-83; this was Faxed to Joyce 03 DEC96
-NSA Meeting @ NSCP 17 DEC96
-Revision with Joyce 20 DEC96As of 20 DEC, Joyce said her superior had talked to Deputy Director William Crowell and NSA wanted NSCP to consider selling /exporting products without triple-DES. Then, JAN97, Ref. 913-96 was returned without action. #2 Ref. 914-96 Strong Encryption for Corporate Networks: Netscape and its Subsidiaries
-Filed 08 Aug96; with Joyce/NSA 19 Aug96
-New list of S/W and new algorithms Faxed to Joyce
-NSA Meeting @ NSCP 23 SEP96
-NSA Meeting @ NSCP 15 OCT96
-After discussion, NSA indicated this would be combined with Ref. 913-96 and we planned to Fax all approved amendments from 913-96 to comply & pertain to Ref. 914-96.As of 20 DEC, Joyce said her superior had talked to Deputy Director William Crowell and NSA wanted NSCP to consider selling /exporting products without triple-DES. Then, JAN97, Ref. 914-96 was returned without action. #3 Ref. 925-96 Strong Encryption for Financial Institutions: Banks and their Customers
-Filed 09 Aug96; with Joyce/NSA 19 Aug96
-New list of S/W Faxed to Joyce
-NSA Meeting @ NSCP 23 SEP96
-NSA asked us to provide explanation of how we would determine a bank was a responsible institution. We resolved what criteria would be.
-NSA Meeting @ NSCP 15 OCT96
-After discussion, NSA indicated they would first approve 913-96 and we planned to Fax all approved amendments from 913-96 to comply & pertain to Ref. 925-96.As of 20 DEC, Joyce said her superior had talked to Deputy Director William Crowell and NSA wanted NSCP to consider selling /exporting products without triple-DES. Then, JAN97, Ref. 925-96 was returned without action. [Stamp] DEPARTMENT OF STATE IS/FPO/CDR [Initials] Date: 12/17/97 _______________________________________________________________________ (X) RELEASE ( ) DECLASSIFY | MR cases Only: ( ) EXCISE ( ) DECLASSIFY | EO Citations _______________________ ( ) DENY IN PART | ( ) DELETE Non-Responsive Info | _____________________TS authority to FOIA Exemptions________________ | ( ) CLASSIFY as ( ) S or ( ) C PA Exemptions________________ | ( ) Downgrade TS to ( ) S or ( ) C ________________________________________ FEB 07-1997 19:43 2024293904 xxx P.03