diff options
author | Simon Josefsson <simon@josefsson.org> | 2005-12-17 09:43:39 +0000 |
---|---|---|
committer | Simon Josefsson <simon@josefsson.org> | 2005-12-17 09:43:39 +0000 |
commit | 33e0370a8860636d7f0fd2ababfcda00b36d8a5f (patch) | |
tree | 273bf98a7d9fe348c38a2481ef51e134ede6742c /doc | |
parent | 043f10ebefc7182aff593bc89ae9cd1bb61bd3d0 (diff) | |
download | gnutls-33e0370a8860636d7f0fd2ababfcda00b36d8a5f.tar.gz |
Add.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/protocol/draft-salowey-tls-ticket-06.txt | 784 |
1 files changed, 784 insertions, 0 deletions
diff --git a/doc/protocol/draft-salowey-tls-ticket-06.txt b/doc/protocol/draft-salowey-tls-ticket-06.txt new file mode 100644 index 0000000000..7a142cc559 --- /dev/null +++ b/doc/protocol/draft-salowey-tls-ticket-06.txt @@ -0,0 +1,784 @@ + + + +Network Working Group J. Salowey +Internet-Draft H. Zhou +Expires: June 18, 2006 Cisco Systems + P. Eronen + Nokia + H. Tschofenig + Siemens + December 15, 2005 + + + Transport Layer Security Session Resumption without Server-Side State + draft-salowey-tls-ticket-06.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + 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 inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on June 18, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes a mechanism which enables the Transport Layer + Security (TLS) server to resume sessions and avoid keeping per-client + session state. The TLS server encapsulates the session state into a + ticket and forwards it to the client. The client can subsequently + + + +Salowey, et al. Expires June 18, 2006 [Page 1] + +Internet-Draft Stateless TLS Session Resumption December 2005 + + + resume a session using the obtained ticket. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.2 SessionTicket TLS extension . . . . . . . . . . . . . . . 5 + 3.3 SessionTicket handshake message . . . . . . . . . . . . . 6 + 3.4 Interaction with TLS session ID . . . . . . . . . . . . . 7 + 4. Recommended Ticket Construction . . . . . . . . . . . . . . . 8 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 5.1 Invalidating Sessions . . . . . . . . . . . . . . . . . . 10 + 5.2 Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 10 + 5.3 Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 10 + 5.4 Denial of Service Attacks . . . . . . . . . . . . . . . . 10 + 5.5 Ticket Protection Key Lifetime . . . . . . . . . . . . . . 10 + 5.6 Alternate Ticket Formats and Distribution Schemes . . . . 11 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 + 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 + 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 + Intellectual Property and Copyright Statements . . . . . . . . 14 + + + + + + + + + + + + + + + + + + + + + + + + + +Salowey, et al. Expires June 18, 2006 [Page 2] + +Internet-Draft Stateless TLS Session Resumption December 2005 + + +1. Introduction + + This document defines a way to resume a Transport Layer Security + (TLS) session without requiring session-specific state at the TLS + server. This mechanism may be used with any TLS ciphersuite. This + document applies to both TLS 1.0 defined in [RFC2246] and TLS 1.1 + defined in [I-D.ietf-tls-rfc2246-bis]. The mechanism makes use of + TLS extensions defined in [I-D.ietf-tls-rfc3546bis] and defines a new + TLS message type. + + This mechanism is useful in the following types of situations + (1) servers that handle a large number of transactions from + different users + (2) servers that desire to cache sessions for a long time + (3) ability to load balance requests across servers + (4) embedded servers with little memory + +2. Terminology + + Within this document the term 'ticket' refers to a cryptographically + protected data structure which is created by the server and consumed + by the server to rebuild session specific state. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Protocol + + This specification describes a mechanism to distribute encrypted + session state information in a ticket from a TLS server to a TLS + client and a mechanism for a TLS client to present a ticket to a TLS + server to resume a session. Implementations of this specification + are expected to support both mechanisms. Other specifications can + take advantage of the session tickets, perhaps specifying alternative + means for distribution or selection. For example a separate + specification may describe an alternate way to distribute a ticket + and use the TLS extension in this document to resume the session. + This behavior is beyond the scope of the document and would need to + be described in a separate specification. + +3.1 Overview + + The client indicates that it supports this mechanism by including a + SessionTicket TLS extension in the ClientHello message. The + extension will be empty if the client does not already possess a + ticket for the server. The extension is described in Section 3.2 + + + + +Salowey, et al. Expires June 18, 2006 [Page 3] + +Internet-Draft Stateless TLS Session Resumption December 2005 + + + If the server wants to use this mechanism, it stores its session + state (such as ciphersuite and master secret) to a ticket that is + encrypted and integrity-protected by a key known only to the server. + The ticket is distributed to the client using the SessionTicket TLS + handshake message described in Section 3.3. This message is sent + during the TLS handshake before the ChangeCipherSpec message after + the server has successfully verified the client's Finished message. + + + Client Server + + ClientHello --------> + (empty SessionTicket extension) + ServerHello + (empty SessionTicket extension) + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + SessionTicket + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + The client caches this ticket along with the master secret and other + parameters associated with the current session. When the client + wishes to resume the session, it includes the ticket in the + SessionTicket extension within ClientHello message. The server then + decrypts the received ticket, verifies that the ticket is valid and + has not been tampered with, retrieves the session state from the + contents of the ticket and uses this state to resume the session. + The interaction with the TLS Session ID is described in Section 3.4. + If the server successfully verifies the client's ticket then it may + renew the ticket by including a SessionTicket handshake message after + the ServerHello. + + + + + + + + + + + +Salowey, et al. Expires June 18, 2006 [Page 4] + +Internet-Draft Stateless TLS Session Resumption December 2005 + + + ClientHello + (SessionTicket extension) --------> + ServerHello + (empty SessionTicket extension) + SessionTicket + [ChangeCipherSpec] + <-------- Finished + [ChangeCipherSpec] + Finished --------> + Application Data <-------> Application Data + + A recommended ticket format is given in Section 4. + + If the server cannot or does not want to honor the ticket then it can + initiate a full handshake with the client. + +3.2 SessionTicket TLS extension + + The SessionTicket TLS extension is based on [I-D.ietf-tls- + rfc3546bis]. The format of the ticket is an opaque structure used to + carry session specific state information. This extension may be sent + in the ClientHello and ServerHello. + + If the client possesses a ticket that it wants to use to resume a + session then it includes it in the SessionTicket extension in the + ClientHello. If the client does not have a ticket and it is prepared + to receive one in the SessionTicket handshake message then it MUST + include a zero length ticket in the SessionTicket extension. If the + client is not prepared to receive a ticket in the SessionTicket + handshake message then it MUST NOT include a SessionTicket extension + unless it is sending a non-empty ticket it received through some + other means from the server. + + The server uses an zero length SessionTicket extension to indicate to + the client that it will send a new session ticket using the + SessionTicket handshake message described in Section 3.3. The server + MUST send this extension in the ServerHello if the server wishes to + issue a new ticket to the client using the SessionTicket handshake + message. The server MUST NOT send this extension if the client does + not include a SessionTicket handshake message in the client hello. + + If the server fails to verify the ticket then it falls back to + performing a full handshake. If the ticket is accepted by the server + but the handshake fails the client SHOULD delete the ticket. + + The SessionTicket extension has been assigned the number TBD1. The + format of the SessionTicket extension is given below. + + + + +Salowey, et al. Expires June 18, 2006 [Page 5] + +Internet-Draft Stateless TLS Session Resumption December 2005 + + + struct { + opaque ticket<0..2^16-1>; + } SessionTicket; + + +3.3 SessionTicket handshake message + + This message is sent by the server during the TLS handshake before + the ChangeCipherSpec message. This message MUST be sent if the + server included a SessionTicket extension in the ServerHello. This + message MUST NOT be sent if the server did not include a + SessionTicket extension in the ServerHello. In the case of a full + handshake, the server MUST verify the client's Finished message + before sending the ticket. The client MUST NOT treat the ticket as + valid until it has verified the server's Finished message. If the + server determines that it does not want to include a ticket after it + has included the SessionTicket extension in the ServerHello then it + MAY send a zero length ticket in the SessionTicket handshake message. + + If the server successfully verifies the client's ticket then it MAY + renew the ticket by including a SessionTicket handshake message after + the ServerHello in the abbreviated handshake. The client should + start using the new ticket as soon as possible after it verifies the + Server's finished message for new connections. Note that since the + updated ticket is issued before the handshake completes it is + possible that the client may not put the new ticket into use before + it initiates new connections. The server MUST NOT assume the client + actually received the updated ticket until it successfully verifies + the client's Finished message. + + The SessionTicket handshake message has been assigned the number + TBD2. The definition of the SessionTicket handshake message is given + below. + + + + + + + + + + + + + + + + + + +Salowey, et al. Expires June 18, 2006 [Page 6] + +Internet-Draft Stateless TLS Session Resumption December 2005 + + + struct { + HandshakeType msg_type; + uint24 length; + select (HandshakeType) { + case hello_request: HelloRequest; + case client_hello: ClientHello; + case server_hello: ServerHello; + case certificate: Certificate; + case server_key_exchange: ServerKeyExchange; + case certificate_request: CertificateRequest; + case server_hello_done: ServerHelloDone; + case certificate_verify: CertificateVerify; + case client_key_exchange: ClientKeyExchange; + case finished: Finished; + case session_ticket: SessionTicket; /* NEW */ + } body; + } Handshake; + + + struct { + opaque ticket<0..2^16-1>; + } SessionTicket; + + +3.4 Interaction with TLS session ID + + If a server is planning on issuing a SessionTicket to a client that + does not present one it SHOULD include an empty Session ID in the + ServerHello. If the server includes a non-empty session ID then it + is indicating intent to use stateful session resume. If the client + receives a SessionTicket from the server then it discards any Session + ID that was sent in the ServerHello. + + When presenting a ticket the client MAY generate and include a + Session ID in the TLS ClientHello. If the server accepts the ticket + and the Session ID is not empty then it MUST respond with the same + Session ID present in the ClientHello. This allows the client to + easily differentiate when the server is resuming a session or falling + back to a full handshake. Since the client generates a Session ID + the server MUST NOT rely upon the Session ID having a particular + value when validating the ticket. If a ticket is presented by the + client the server MUST NOT attempt to use the Session ID in the + ClientHello for stateful session resume. Alternatively, the client + MAY include an empty Session ID in the ClientHello. In this case the + client ignores the Session ID sent in the ServerHello and determines + if the server is resuming a session by the subsequent handshake + messages. + + + + +Salowey, et al. Expires June 18, 2006 [Page 7] + +Internet-Draft Stateless TLS Session Resumption December 2005 + + +4. Recommended Ticket Construction + + This section describes a recommended format and protection for the + ticket. Note that the ticket is opaque to the client so the + structure is not subject to interoperability concerns, so + implementations may diverge from this format. If implementations do + diverge from this format they must take security concerns seriously. + Clients MUST NOT examine the ticket under the assumption that it + complies with this document. + + The server uses two different keys, one 128-bit key for AES [AES] in + CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104] + [SHA1]. + + The ticket is structured as follows: + + struct { + uint32 key_version; + opaque iv[16] + opaque encrypted_state<0..2^16-1>; + opaque mac[20]; + } Ticket; + + Here key_version identifies a particular set of keys. One + possibility is to generate new random keys every time the server is + started, and use the timestamp as the key version. The same + mechanisms known from a number of other protocols can be reused for + this purpose. + + The actual state information in encrypted_state is encrypted using + 128-bit AES in CBC mode with the given IV. The MAC is calculated + using HMAC-SHA1 over key_version (4 octets)and IV (16 octets), + followed by the length of the encrypted_state field (2 octets) and + its contents (variable length). + + + + + + + + + + + + + + + + + +Salowey, et al. Expires June 18, 2006 [Page 8] + +Internet-Draft Stateless TLS Session Resumption December 2005 + + + struct { + ProtocolVersion protocol_version; + CipherSuite cipher_suite; + CompressionMethod compression_method; + opaque master_secret[48]; + ExampleClientIdentity client_identity; + uint32 timestamp; + } StatePlaintext; + + enum { + anonymous(0), + certificate_based(1), + psk(2) + } ClientAuthenticationType; + + struct { + ClientAuthenticationType client_authentication_type; + select (ClientAuthenticationType) { + case anonymous: struct {}; + case certificate_based: + ASN.1Cert certificate_list<0..2^24-1>; + case psk: + opaque psk_identity<0..2^16-1>; + + } + } ClientIdentity; + + The structure StatePlaintext stores the TLS session state including + the master_secret. The timestamp within this structure allows the + TLS server to expire tickets. To cover the authentication and key + exchange protocols provided by TLS the ClientIdentity structure + contains the authentication type of the client used in the initial + exchange (see ClientAuthenticationType). To offer the TLS server + with the same capabilities for authentication and authorization a + certificate list is included in case of public key based + authentication. The TLS server is therefore able to inspect a number + of different attributes within these certificates. A specific + implementation might choose to store a subset of this information or + additional information. Other authentication mechanism such as + Kerberos [RFC2712] would require different client identity data. + +5. Security Considerations + + This section addresses security issues related to the usage of a + ticket. Tickets must be sufficiently authenticated and encrypted to + prevent modification or eavesdropping by an attacker. Several + attacks described below will be possible if this is not carefully + done. + + + +Salowey, et al. Expires June 18, 2006 [Page 9] + +Internet-Draft Stateless TLS Session Resumption December 2005 + + + Implementations should take care to ensure that the processing of + tickets does not increase the chance of denial of serve as described + below. + +5.1 Invalidating Sessions + + The TLS specification requires that TLS sessions be invalidated when + errors occur. [CSSC] discusses the security implications of this in + detail. In the analysis in this paper, failure to invalidate + sessions does not pose a security risk. This is because the TLS + handshake uses a non-reversible function to derive keys for a session + so information about one session does not provide an advantage to + attack the master secret or a different session. If a session + invalidation scheme is used the implementation should verify the + integrity of the ticket before using the contents to invalidate a + session to ensure an attacker cannot invalidate a chosen session. + +5.2 Stolen Tickets + + An eavesdropper or man-in-the-middle may obtain the ticket and + attempt to use the ticket to establish a session with the server, + however since the ticket is encrypted and the attacker does not know + the secret key, a stolen ticket does not help an attacker resume a + session. A TLS server MUST use strong encryption and integrity + protection for the ticket to prevent an attacker from using a brute + force mechanism to obtain the tickets contents. + +5.3 Forged Tickets + + A malicious user could forge or alter a ticket in order to resume a + session, to extend its lifetime, to impersonate as another user or + gain additional privileges. This attack is not possible if the + ticket is protected using a strong integrity protection algorithm + such as a keyed HMAC-SHA1. + +5.4 Denial of Service Attacks + + An adversary could store or forge a large number of tickets to send + to the TLS server for verification. To minimize the possibility of a + denial of service, the verification of the ticket should be + lightweight (e.g., using efficient symmetric key cryptographic + algorithms). + +5.5 Ticket Protection Key Lifetime + + The management of the keys used to protect the ticket is beyond the + scope of this document. It is advisable to limit the lifetime of + these keys to ensure they are not overused. + + + +Salowey, et al. Expires June 18, 2006 [Page 10] + +Internet-Draft Stateless TLS Session Resumption December 2005 + + +5.6 Alternate Ticket Formats and Distribution Schemes + + If a different ticket format or distribution scheme than the ones + defined in this document is used then great care must be taken in + analyzing the security of the solution. In particular if a secret is + transferred to the client it MUST be done using secure communication + so as to prevent attackers from obtaining or modifying the key. Also + the ticket MUST have its integrity and privacy protected with strong + cryptographic techniques to prevent a breach in the security of the + system. + +6. Acknowledgments + + The authors would like to thank the following people for their help + with preparing and reviewing this document: Eric Rescorla, Mohamad + Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew, + Rob Dugal and members of the TLS working group. + + [CSSC] describes a solution that is very similar to the one described + in this document and gives a detailed analysis of the security + considerations involved. [RFC2712] describes a mechanism for using + Kerberos ([RFC4120]) in TLS ciphersuites, which helped inspire the + use of tickets to avoid server state. [I-D.cam-winget-eap-fast] + makes use of a similar mechanism to avoid maintaining server state + for the cryptographic tunnel. [SC97] also investigates the concept + of stateless sessions. + +7. IANA considerations + + IANA has assigned a TLS extension number of TBD1 (the value 35 is + suggested) to the SessionTicket TLS extension from the TLS registry + of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis]. + + IANA has assigned a TLS HandshakeType number TBD2 to the + SessionTicket handshake type from the TLS registry of HandshakeType + values defined in [I-D.ietf-tls-rfc2246-bis]. + +8. References + +8.1 Normative References + + [I-D.ietf-tls-rfc2246-bis] + Dierks, T. and E. Rescorla, "The TLS Protocol Version + 1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress), + June 2005. + + [I-D.ietf-tls-rfc3546bis] + Blake-Wilson, S., "Transport Layer Security (TLS) + + + +Salowey, et al. Expires June 18, 2006 [Page 11] + +Internet-Draft Stateless TLS Session Resumption December 2005 + + + Extensions", draft-ietf-tls-rfc3546bis-02 (work in + progress), October 2005. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + +8.2 Informative References + + [AES] National Institute of Standards and Technology, "Advanced + Encryption Standard (AES)", Federal Information + Processing Standards (FIPS) Publication 197, + November 2001. + + [CBC] National Institute of Standards and Technology, + "Recommendation for Block Cipher Modes of Operation - + Methods and Techniques", NIST Special Publication 800-38A, + December 2001. + + [CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side + caching for TLS", Transactions on Information and + System Security (TISSEC) , Volume 7, Issue 4, + November 2004. + + [I-D.cam-winget-eap-fast] + Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "EAP + Flexible Authentication via Secure Tunneling (EAP-FAST)", + draft-cam-winget-eap-fast-02 (work in progress), + April 2005. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher + Suites to Transport Layer Security (TLS)", RFC 2712, + October 1999. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + + [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites + for Transport Layer Security (TLS)", RFC 4279, + December 2005. + + + + +Salowey, et al. Expires June 18, 2006 [Page 12] + +Internet-Draft Stateless TLS Session Resumption December 2005 + + + [SC97] Aura, T. and P. Nikander, "Stateless Connections", + Proceedings of the First International Conference on + Information and Communication Security (ICICS '97) , 1997. + + [SHA1] National Institute of Standards and Technology, "Secure + Hash Standard (SHS)", Federal Information Processing + Standards (FIPS) Publication 180-2, August 2002. + + +Authors' Addresses + + Joseph Salowey + Cisco Systems + 2901 3rd Ave + Seattle, WA 98121 + US + + Email: jsalowey@cisco.com + + + Hao Zhou + Cisco Systems + 4125 Highlander Parkway + Richfield, OH 44286 + US + + Email: hzhou@cisco.com + + + Pasi Eronen + Nokia Research Center + P.O. Box 407 + FIN-00045 Nokia Group + Finland + + Email: pasi.eronen@nokia.com + + + Hannes Tschofenig + Siemens + Otto-Hahn-Ring 6 + Munich, Bayern 81739 + Germany + + Email: Hannes.Tschofenig@siemens.com + + + + + + +Salowey, et al. Expires June 18, 2006 [Page 13] + +Internet-Draft Stateless TLS Session Resumption December 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Salowey, et al. Expires June 18, 2006 [Page 14] + |