Network Working Group K.R. Burdis Internet-Draft Rhodes University Expires: March 13, 2001 September 12, 2000 Secure Remote Password SASL Mechanism draft-burdis-cat-srp-sasl-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 March 13, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes an SASL mechanism based on the Secure Remote Password protocol. The mechanism includes mutual authentication and can provide a security layer with replay detection, integrity protection and/or confidentiality protection. Burdis Expires March 13, 2001 [Page 1] Internet-Draft Secure Remote Password SASL Mechanism September 2000 Table of Contents 1. Conventions Used in this Document . . . . . . . . . . . . . 3 2. Netstrings . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 3.1 Server sends N, g and L . . . . . . . . . . . . . . . . . . 6 3.2 Client sends request . . . . . . . . . . . . . . . . . . . . 9 3.3 Server sends response . . . . . . . . . . . . . . . . . . . 10 3.4 Client sends evidence . . . . . . . . . . . . . . . . . . . 10 3.5 Server sends evidence . . . . . . . . . . . . . . . . . . . 10 4. Security Layer . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 Integrity Protection . . . . . . . . . . . . . . . . . . . . 11 4.1.1 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.2 Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . 17 A. Modulus and Generator values . . . . . . . . . . . . . . . . 19 Full Copyright Statement . . . . . . . . . . . . . . . . . . 21 Burdis Expires March 13, 2001 [Page 2] Internet-Draft Secure Remote Password SASL Mechanism September 2000 1. Conventions Used in this Document In this document, a string of 8-bit bytes may be written in two different forms: as a series of hexadecimal numbers between angle brackets, or as a sequence of ASCII characters between double quotes. For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a string of length 12; it is the same as the string "hello world!" [1]. All data is encoded and sent in network byte order (big-endian). 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 RFC 2119[2]. Burdis Expires March 13, 2001 [Page 3] Internet-Draft Secure Remote Password SASL Mechanism September 2000 2. Netstrings This mechanism makes extensive use of netstrings, which are described in more detail in [1]: A netstring is a self-delimiting encoding of a string. Netstrings are very easy to generate and to parse. Any string may be encoded as a netstring; there are no restrictions on length or on allowed bytes. Another virtue of a netstring is that it declares the string size up front. Thus an application can check in advance whether it has enough space to store the entire string. Any string of 8-bit bytes may be encoded as {len}":"{string}",". Here {string} is the string and {len} is a nonempty sequence of ASCII digits giving the length of {string} in decimal. The ASCII digits are <30> for 0, <31> for 1, and so on up through <39> for 9. Extra zeros at the front of {len} are prohibited: {len} begins with <30> exactly when {string} is empty. For example, the string "hello world!" is encoded as <31 32 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". The empty string is encoded as "0:,". {len}":"{string}"," is called a netstring. {string} is called the interpretation of the netstring. Note that {string} may itself be a netstring. Burdis Expires March 13, 2001 [Page 4] Internet-Draft Secure Remote Password SASL Mechanism September 2000 3. Protocol Description The SASL mechanism name associated with this protocol is "SRP". SRP is a password-based zero-knowledge authentication and key-exchange protocol developed by Thomas Wu. It has good performance, is not plaintext-equivalent and maintains perfect forward secrecy. It provides authentication (optionally mutual authentication) and the negotiation of a session key [11]. This mechanism is based on the optimised SRP-SHA1 protocol described at the end of section 3 in [10], since this reduces the total number of messages exchanged by grouping together pieces of information that do not depend on earlier messages. Due to the design of the mechanism, mutual authentication is MANDATORY. This document describes how the SRP-SHA1 data is encoded for transmission between the client and server, and it adds extra control information to enable the client to request whether or not replay detection, integrity protection and/or confidentiality protection should be provided by a security layer. Mechanism data exchanges are shown below: Client Server <-- N,g,L -- -- U,I,A,o --> <-- s,B -- -- M1 --> M1 = H(H(N) XOR H(g) | H(U) | s | H(L) | A | B | K) <-- M2 -- M2 = H(A | H(U) | H(I) | H(o) | M1 | K) where: | is the concatenation operator H is the SHA-1 one-way function N is the prime modulus Burdis Expires March 13, 2001 [Page 5] Internet-Draft Secure Remote Password SASL Mechanism September 2000 g is the generator L is the options list indicating available security services U is the client's username (authentication identity) I is the client's authorisation identity A is the client's ephemeral public key o is the options list indicating requested security services s is the client's password salt B is the server's ephemeral public key M1 is the client's evidence that the shared key is known M2 is the server's evidence that the shared key is known 3.1 Server sends N, g and L The prime modulus (N) is encoded as a netstring (ns1). The generator (g) is encoded as a netstring (ns2). The server creates an options list (L), which consists of a comma-separated list of option strings that specify the security service options the server supports. The following option strings are defined: o "integrity=HMAC-MD5" indicates that the server supports integrity protection using the HMAC-MD5 algorithm [5]. This option string MUST always be sent, since support for this algorithm is MANDATORY. o "replay detection" indicates that the server supports replay detection using sequence numbers. o "confidentiality=BLOWFISH-CBC" indicates that the server supports confidentiality protection using the Blowfish cipher in CBC mode [9]. If the server supports confidentiality protection, it MUST send this option string, since it is then MANDATORY for it to provide support for this algorithm. Other option strings MAY be sent. The options list SHOULD NOT be interpreted in a case-sensitive manner. For example, if the server supports integrity protection, replay detection and no confidentiality protection, the options list would Burdis Expires March 13, 2001 [Page 6] Internet-Draft Secure Remote Password SASL Mechanism September 2000 be: integrity=HMAC-MD5,replay detection This options list (L) is encoded as a netstring (ns3). These three netstrings (ns1, ns2 and ns3) are concatenated and this string is encoded as a netstring (ns4). The resulting string (ns4) is sent to the client. For example if: N = and: g = <02> and: L = "integrity=hmac-md5,replay detection, confidentiality=blowfish-cbc" or L = <69 6E 74 65 67 72 69 74 79 3D 68 6D 61 63 2D 6D 64 35 2C 72 65 70 6C 61 79 20 64 65 74 65 63 74 69 6F 6E 2C 63 6F 6E 66 69 64 65 6E 74 69 61 6C 69 74 79 3D 62 6C 6F 77 66 69 73 68 2D 63 62 63> Burdis Expires March 13, 2001 [Page 7] Internet-Draft Secure Remote Password SASL Mechanism September 2000 N encoded as a netstring is: <31 32 38 3A EE AF 0A B9 AD B3 8D D6 9C 33 F8 0A FA 8F C5 E8 60 72 61 87 75 FF 3C 0B 9E A2 31 4C 9C 25 65 76 D6 74 DF 74 96 EA 81 D3 38 3B 48 13 D6 92 C6 E0 E0 D5 D8 E2 50 B9 8B E4 8E 49 5C 1D 60 89 DA D1 5D C7 D7 B4 61 54 D6 B6 CE 8E F4 AD 69 B1 5D 49 82 55 9B 29 7B CF 18 85 C5 29 F5 66 66 0E 57 EC 68 ED BC 3C 05 72 6C C0 2F D4 CB F4 97 6E AA 9A FD 51 38 FE 83 76 43 5B 9F C6 1D 2F C0 EB 06 E3 2C> g encoded as a netstring is: "1:" <02> "," or <31 3A 02 2C> L encoded as a netstring is: "64:integrity=hmac-md5,replay detection, confidentiality=blowfish-cbc," or <36 34 3A 69 6E 74 65 67 72 69 74 79 3D 68 6D 61 63 2D 6D 64 35 2C 72 65 70 6C 61 79 20 64 65 74 65 63 74 69 6F 6E 2C 63 6F 6E 66 69 64 65 6E 74 69 61 6C 69 74 79 3D 62 6C 6F 77 66 69 73 68 2D 63 62 63 2C> Burdis Expires March 13, 2001 [Page 8] Internet-Draft Secure Remote Password SASL Mechanism September 2000 The final string is: "205:128:" ",1:" <2> ",64:" <69 6E 74 65 67 72 69 74 79 3D 68 6D 61 63 2D 6D 64 35 2C 72 65 70 6C 61 79 20 64 65 74 65 63 74 69 6F 6E 2C 63 6F 6E 66 69 64 65 6E 74 69 61 6C 69 74 79 3D 62 6C 6F 77 66 69 73 68 2D 63 62 63> ",," or <32 30 35 3A 31 32 38 3A EE AF 0A B9 AD B3 8D D6 9C 33 F8 0A FA 8F C5 E8 60 72 61 87 75 FF 3C 0B 9E A2 31 4C 9C 25 65 76 D6 74 DF 74 96 EA 81 D3 38 3B 48 13 D6 92 C6 E0 E0 D5 D8 E2 50 B9 8B E4 8E 49 5C 1D 60 89 DA D1 5D C7 D7 B4 61 54 D6 B6 CE 8E F4 AD 69 B1 5D 49 82 55 9B 29 7B CF 18 85 C5 29 F5 66 66 0E 57 EC 68 ED BC 3C 05 72 6C C0 2F D4 CB F4 97 6E AA 9A FD 51 38 FE 83 76 43 5B 9F C6 1D 2F C0 EB 06 E3 2C 31 3A 02 2C 36 34 3A 69 6E 74 65 67 72 69 74 79 3D 68 6D 61 63 2D 6D 64 35 2C 72 65 70 6C 61 79 20 64 65 74 65 63 74 69 6F 6E 2C 63 6F 6E 66 69 64 65 6E 74 69 61 6C 69 74 79 3D 62 6C 6F 77 66 69 73 68 2D 63 62 63 2C 2C> 3.2 Client sends request The client's username (U) is encoded as a netstring (ns1). The client's authorisation identity (I) is encoded as a netstring (ns2). The client generates its ephemeral public key (A) and this is encoded as a netstring (ns3). The client creates a comma-separated options list (o) that specifies the security service options that it requests. (The client can only select security services that the server has indicated it can provide). The defined options are: o "integrity=HMAC-MD5": the client requests integrity protection using the HMAC-MD5 algorithm [5]. o "replay detection": the client requests replay detection using sequence numbers. (Note that an integrity protection algorithm Burdis Expires March 13, 2001 [Page 9] Internet-Draft Secure Remote Password SASL Mechanism September 2000 MUST be specified if this option is chosen). o "confidentiality=BLOWFISH-CBC": the client requests confidentiality protection using the Blowfish cipher in CBC mode [9]. Other options MAY be available. This options list (o) is encoded as a netstring (ns4). These four netstrings (ns1, ns2, ns3 and ns4) are concatenated and this string is encoded as a netstring (ns5). The resulting string (ns5) is sent to the server. 3.3 Server sends response The server calculates the shared context key (K). The client's salt (s) is encoded as a netstring (ns1). The server generates its ephemeral public key (B) and this is encoded as a netstring (ns2). These two netstrings (ns1 and ns2) are concatenated and this string is encoded as a netstring (ns3). The resulting string (ns3) is sent to the server. 3.4 Client sends evidence The client calculates the shared context key (K). The client calculates the evidence (M1) that proves to the server that it knows the shared context key (K), including L as part of the calculation. M1 = H(H(N) XOR H(g) | H(U) | s | H(L) | A | B | K) This evidence (M1) is encoded as a netstring (ns1) and sent to the server. 3.5 Server sends evidence The server calculates the evidence (M2) that proves to the client that it knows the shared context key (K), including U, I, and o as part of the calculation. M2 = H(A | H(U) | H(I) | H(o) | M1 | K) This evidence (M2) is encoded as a netstring (ns1) and sent to the client. Burdis Expires March 13, 2001 [Page 10] Internet-Draft Secure Remote Password SASL Mechanism September 2000 4. Security Layer Depending on the options specified by the initiator, the security layer may provide integrity protection, replay detection, and/or confidentiality protection. Messages are encoded as follows: o If neither integrity nor confidentiality protection is requested then the message is sent unchanged to the other party. o If just confidentiality protection is requested then the message data is encrypted using the chosen confidentiality algorithm (eg. Blowfish). The encrypted message is encoded as a netstring and sent to the other party. o If just integrity protection is requested then the integrity checksum is calculated on the message data as described in Section 4.1. o If both integrity protection and confidentiality protection are requested then the message data is first encrypted using the chosen confidentiality algorithm (eg. Blowfish). Thereafter the integrity checksum is calculated on the encrypted message data as described in Section 4.1. o If replay detection is requested then the sequence number included in the integrity checksum is incremented after each message is sent, starting at zero, otherwise the sequence number is always zero. 4.1 Integrity Protection Integrity protection is provided using the chosen integrity protection algorithm (usually the HMAC-MD5 [5] algorithm), with the shared context key (K) used as the input key. The encoding and decoding of message data is described below. 4.1.1 Encoding The (possibly encrypted) message data is encoded as a netstring (ns1). The (incremented) sequence number is encoded as a netstring (ns2). These two netstrings (ns1 and ns2) are concatenated and encoded as a netstring (ns3). A MAC is computed using the chosen integrity protection algorithm, the shared context key and ns3. The MAC is then encoded as a netstring (ns4). ns3 and ns4 are concatenated and this string is encoded as a netstring (ns5). ns5 is sent to the other party. Burdis Expires March 13, 2001 [Page 11] Internet-Draft Secure Remote Password SASL Mechanism September 2000 4.1.2 Decoding The received data is interpreted as a netstring. This string is the concatenation of two netstrings (ns3 and ns4). ns3 contains the concatenation of the (possibly encrypted) message data netstring (ns1) and the sequence number netstring (ns2). The interpretation of ns4 is the received message authentication code (MAC). The receiver computes a message authentication code using the chosen integrity protection algorithm (eg. HMAC-MD5), the shared context key and ns3. This computed MAC is compared with the received MAC. If the MACs do not match then that indicates that the message has been tampered with and the message SHOULD be rejected. If replay detection was requested then the receiver interprets ns2, checks that the sequence number is what it expects it to be, and rejects the message if it is not. The interpretation of ns3 is the (possibly encrypted) original message. If the message is encrypted it should be decrypted using the chosen confidentiality algorithm (eg. Blowfish) and the session key (K). Burdis Expires March 13, 2001 [Page 12] Internet-Draft Secure Remote Password SASL Mechanism September 2000 5. Example The example below uses SMTP authentication [6]. The base64 encoding of challenges and responses, as well as the reply codes preceding the responses are part of the SMTP authentication[6] specification, not part of this SASL mechanism itself. "C:" and "S:" indicate lines sent by the client and server respectively. S: 220 smtp.example.com ESMTP server ready C: EHLO krb.example.com S: 250-smtp.example.com S: 250 AUTH SRP CRAM-MD5 DIGEST-MD5 C: AUTH SRP S: 334 MjA1OjEyODrurwq5rbON1pwz+Ar6j8XoYHJhh3X/PAueojFMnCVldtZ033S W6oHTODtIE9aSxuDg1djiULmL5I5JXB1gidrRXcfXtGFU1rbOjvStabFdSYJVmyl7z xiFxSn1ZmYOV+xo7bw8BXJswC/Uy/SXbqqa/VE4/oN2Q1ufxh0vwOsG4ywxOgIsNjQ 6aW50ZWdyaXR5PWhtYWMtbWQ1LHJlcGxheSBkZXRlY3Rpb24sY29uZmlkZW50aWFsa XR5PWJsb3dmaXNoLWNiYyws C: MjE3OjU6a2VpdGgsNTprZWl0aCwxMjg6iNsL3XSGLjrCf/ecuOzQP0FyYI0WPJ6 DFwlUKrnnsVTAo0mEWz03KcS4Q78BqTIQGpFny7W0KqP8WRX119ey5mcu4yh7M2qoS E51g/4baqVuCvPtrrodPExHIM1I+nIU/XlFMNjrC3WSuO/2P/jOQrHvflnOqoNltl0 tpTW1F6IsNjQ6aW50ZWdyaXR5PWhtYWMtbWQ1LHJlcGxheSBkZXRlY3Rpb24sY29uZ mlkZW50aWFsaXR5PWJsb3dmaXNoLWNiYyws S: MTQ3OjEwOhUpUDmvEIlfBRAsMTI4OsSBV0SYkU6GiUISs1IIJgMbMJNMnSI+XSC aeoON4fPr1GrhE2k8YBvTx/gfNXg64Up7UwzxzrFO8CiizXc5By1vr0GPgjrlCA5t0 zB9srXSN0rASwfVW4CJ9z3NZgnVEnEkHC31uk/pYMvepMDbHgyVzBVse4MmZEthOEJ An4/vLCw= C: MjA6+ebL5YgK6sztDcP1PZCrnMKIjFgs S: MjA6sE5gGxTxvc+yFPgygRuVvze9m6Ys C: S: 235 Authentication successful. Burdis Expires March 13, 2001 [Page 13] Internet-Draft Secure Remote Password SASL Mechanism September 2000 6. Discussion Although the MD5 and SHA-1 hash functions are used in this mechanism, they could be replaced with any iterative cryptographic hash function [5]. The specified algorithms were chosen for utility and availablity. It was also felt that a mandatory confidentiality and integrity protection algorithm should be specified to ensure interoperability between implementations of this mechanism. The HMAC-MD5 algorithm was chosen as an integrity algorithm because it is faster than both HMAC-SHA1 and MAC algorithms based on secret key encryption algorithms [4]. Blowfish was chosen as a cipher because [9]: o it is free from intellectual property constraints o it is fast o it has withstood cryptanalysis since 1993 o a number of implementations in various programming languages are freely available Other algorithms that are identified as useful may be specified at a later stage. Since confidentiality protection is optional this mechanism should be usable in countries that have strict controls on the use of cryptography. It is RECOMMENDED that the server use values for the modulus (n) and generator (g) chosen from those listed in Appendix A so that the client can avoid expensive constraint checks, since these predefined values already meet the constraints described in [10]: "For maximum security, N should be a safe prime (i.e. a number of the form N = 2q + 1, where q is also prime). Also, g should be a generator modulo N (see [SRP] for details), which means that for any X where 0 < X < N, there exists a value x for which g^x % N == X." Burdis Expires March 13, 2001 [Page 14] Internet-Draft Secure Remote Password SASL Mechanism September 2000 7. Security Considerations This mechanism relies on the security of SRP, which bases its security on the difficulty of solving the Diffie-Hellman problem in the multiplicative field modulo a large safe prime. See section 4 "Security Considerations" of [10] and section 4 "Security analysis" of [11]. This mechanism also relies on the security of the HMAC algorithm and the underlying hash function. Section 6 "Security" of [5] discusses these security issues in detail. Weaknesses found in MD5 do not impact HMAC-MD5 [3]. The Blowfish cipher has undergone cryptanalysis for a long period of time and no weaknesses have been found [9]. U, I, A and o sent from the client to the server, and N, g, L, s and B sent from the server to the client could be modified by an attacker before reaching the other party. For this reason, these values are included in the respective calculations of evidence to prove that each party knows the session key. This allows each party to verify that these values were received unmodified. The use of integrity protection is RECOMMENDED to detect message tampering and to avoid session hijacking after authentication has taken place. Replay attacks may be avoided through the use of sequence numbers, because sequence numbers make each integrity protected message exchanged during a session different, and each session uses a different key. Burdis Expires March 13, 2001 [Page 15] Internet-Draft Secure Remote Password SASL Mechanism September 2000 8. Acknowledgements The following people provided valuable feedback in the preparation of this document: Timothy Martin Raif S. Naffah Burdis Expires March 13, 2001 [Page 16] Internet-Draft Secure Remote Password SASL Mechanism September 2000 References [1] Bernstein, D.J., "Netstrings", February 1997, . [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 0014, RFC 2119, March 1997. [3] Dobbertin, H., "The Status of MD5 After a Recent Attack", December 1996, . [4] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM", RFC 2847, June 2000. [5] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [6] Myers, J.G., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [7] Myers, J.G., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [8] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [9] Schneier, B., "The Blowfish Encryption Algorithm", March 1993, . [10] Wu, T., "Internet Draft: The SRP Authentication and Key Exchange System", July 1999, . [11] Wu, T., "The Secure Remote Password Protocol", March 1998, . [12] Wu, T., "SRP: The Open Source Password Authentication Standard", March 1998, . Burdis Expires March 13, 2001 [Page 17] Internet-Draft Secure Remote Password SASL Mechanism September 2000 Author's Address K.R. Burdis Rhodes University Computer Science Department Grahamstown 6139 ZA EMail: keith@rucus.ru.ac.za URI: http://www.cryptix.org/~keith/ Burdis Expires March 13, 2001 [Page 18] Internet-Draft Secure Remote Password SASL Mechanism September 2000 Appendix A. Modulus and Generator values Modulus (n) and generator (g) values for various modulus lengths are given below. In each case the modulus is a large safe prime and the generator is a primitve root of GF(n) [11]. These values are taken from software developed by Tom Wu and Eugene Jhong for the Stanford SRP distribution [12]. The modulus values are base64 encoded. [264 bits] Modulus = HMujfBWu4LfBFA0j3PpN7UbgUYfv.rMoMNuVRMoekpZ Generator = 2 [384 bits] Modulus = W2KsCfRxb3/ELBvnVWufMA0gbdBlLXbJihgZkgp3xLTKwtPCUhSOHNZ5VLb9pBGR Generator = 2 [512 bits] Modulus = 3Kn/YYiomHkFkfM1x4kayR125MGkzpLUDy3y14FlTMwYnhZkjrMXnoC2TcFAecNl U5kFzgcpKYUbBOPZFRtyf3 Generator = 2 [640 bits] Modulus = CbDP.jR6YD6wAj2ByQWxQxQZ7.9J9xkn2.Uqb3zVm16vQyizprhBw9hi80psatZ8 k54vwZfiIeEHZVsDnyqeWSSIpWso.wh5GD4OFgdhVI3 Generator = 2 [768 bits] Modulus = iqJ7nFZ4bGCRjE1F.FXEwL085Zb0kLM2TdHDaVVCdq0cKxvnH/0FLskJTKlDtt6s Dl89dc//aEULTVFGtcbA/tDzc.bnFE.DWthQOu2n2JwKjgKfgCR2lZFWXdnWmoOh Generator = 2 [1024 bits] Modulus = Ewl2hcjiutMd3Fu2lgFnUXWSc67TVyy2vwYCKoS9MLsrdJVT9RgWTCuEqWJrfB6u E3LsE9GkOlaZabS7M29sj5TnzUqOLJMjiwEzArfiLr9WbMRANlF68N5AVLcPWvNx 6Zjl3m5Scp0BzJBz9TkgfhzKJZ.WtP3Mv/67I/0wmRZ Generator = 2 [1280 bits] Modulus = 3NUKQ2Re4P5BEK0TLg2dX3gETNNNECPoe92h4OVMaDn3Xo/0QdjgG/EvM.hiVV1B dIGklSI14HA38Mpe5k04juR5/EXMU0r1WtsLhNXwKBlf2zEfoOh0zVmDvqInpU69 5f29Iy7sNW3U5RIogcs740oUp2Kdv5wuITwnIx84cnO.e467/IV1lPnvMCr0pd1d Burdis Expires March 13, 2001 [Page 19] Internet-Draft Secure Remote Password SASL Mechanism September 2000 gS0a.RV5eBJr03Q65Xy61R Generator = 2 [1536 bits] Modulus = dUyyhxav9tgnyIg65wHxkzkb7VIPh4o0lkwfOKiPp4rVJrzLRYVBtb76gKlaO7ef 5LYGEw3G.4E0jbMxcYBetDy2YdpiP/3GWJInoBbvYHIRO9uBuxgsFKTKWu7RnR7y Tau/IrFTdQ4LY/q.AvoCzMxV0PKvD9Odso/LFIItn8PbTov3VMn/ZEH2SqhtpBUk WtmcIkEflhX/YY/fkBKfBbe27/zUaKUUZEUYZ2H2nlCL60.JIPeZJSzsu/xHDVcx Generator = 2 [2048 bits] Modulus = 2iQzj1CagQc/5ctbuJYLWlhtAsPHc7xWVyCPAKFRLWKADpASkqe9djWPFWTNTdeJ tL8nAhImCn3Sr/IAdQ1FrGw0WvQUstPx3FO9KNcXOwisOQ1VlL.gheAHYfbYyBax XL.NcJx9TUwgWDT0hRzFzqSrdGGTN3FgSTA1v4QnHtEygNj3eZ.u0MThqWUaDiP8 7nqha7XnT66bkTCkQ8.7T8L4KZjIImrNrUftedTTBi.WCi.zlrBxDuOM0da0JbUk QlXqvp0yvJAPpC11nxmmZOAbQOywZGmu9nhZNuwTlxjfIro0FOdthaDTuZRL9VL7 MRPUDo/DQEyW.d4H.UIlzp Generator = 2 Burdis Expires March 13, 2001 [Page 20] Internet-Draft Secure Remote Password SASL Mechanism September 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Burdis Expires March 13, 2001 [Page 21]