5 Internet-Draft Rhodes University
6 Expires: November 28, 2003 R. Naffah
11 Secure Remote Password Authentication Mechanism
12 draft-burdis-cat-srp-sasl-08
16 This document is an Internet-Draft and is in full conformance with
17 all provisions of Section 10 of RFC2026.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that other
21 groups may also distribute working documents as Internet-Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at http://
29 www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on November 28, 2003.
38 Copyright (C) The Internet Society (2003). All Rights Reserved.
42 This document describes an authentication mechanism based on the
43 Secure Remote Password protocol (SRP-6) and how to use it with the
44 authentication frameworks Secure Authentication and Security Layer
45 (SASL), Generic Security Services Application Programming Interface
46 (GSS-API) and Extensible Authentication Protocol (EAP). This
47 mechanism performs mutual authentication and can provide a security
48 layer with replay detection, integrity protection and/or
49 confidentiality protection.
56 Burdis & Naffah Expires November 28, 2003 [Page 1]
58 Internet-Draft SRP Authentication Mechanism May 2003
63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
64 2. Conventions Used in this Document . . . . . . . . . . . . . 5
65 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 6
66 3.1 Scalar Numbers . . . . . . . . . . . . . . . . . . . . . . . 6
67 3.2 Multi-Precision Integers . . . . . . . . . . . . . . . . . . 6
68 3.3 Octet Sequences . . . . . . . . . . . . . . . . . . . . . . 7
69 3.4 Extended Octet Sequences . . . . . . . . . . . . . . . . . . 7
70 3.5 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
71 3.6 Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . 8
72 3.7 Data Element Size Limits . . . . . . . . . . . . . . . . . . 8
73 3.8 Unsigned Integers . . . . . . . . . . . . . . . . . . . . . 8
74 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 9
75 4.1 Client Sends its Identity . . . . . . . . . . . . . . . . . 11
76 4.2 Server Agrees to Re-use Parameters of a Previous Session . . 11
77 4.3 Server Sends Protocol Elements . . . . . . . . . . . . . . . 12
78 4.4 Client Sends its Ephemeral Public Key and Evidence . . . . . 15
79 4.5 Server Verifies Client's Evidence and Sends its Evidence . . 17
80 5. Security Layer . . . . . . . . . . . . . . . . . . . . . . . 19
81 5.1 Cryptographic Primitives . . . . . . . . . . . . . . . . . . 20
82 5.1.1 Pseudo Random Number Generator . . . . . . . . . . . . . . . 20
83 5.1.2 Key Derivation Function . . . . . . . . . . . . . . . . . . 22
84 5.2 Confidentiality Protection . . . . . . . . . . . . . . . . . 23
85 5.3 Replay Detection . . . . . . . . . . . . . . . . . . . . . . 24
86 5.4 Integrity Protection . . . . . . . . . . . . . . . . . . . . 25
87 5.5 Summary of Security Layer Output . . . . . . . . . . . . . . 25
88 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 27
89 6.1 Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . 27
90 6.2 Modulus and Generator Values . . . . . . . . . . . . . . . . 27
91 6.3 Replay Detection Sequence Number Counters . . . . . . . . . 27
92 6.4 Re-using the Parameters of a Previous Session . . . . . . . 28
93 7. SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
94 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 30
95 7.2 Mechanism Name . . . . . . . . . . . . . . . . . . . . . . . 30
96 7.3 Security Layer . . . . . . . . . . . . . . . . . . . . . . . 30
97 7.4 Profile Considerations . . . . . . . . . . . . . . . . . . . 30
98 7.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 31
99 8. GSS-API . . . . . . . . . . . . . . . . . . . . . . . . . . 34
100 8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 34
101 8.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 34
102 8.3 Initial Token . . . . . . . . . . . . . . . . . . . . . . . 34
103 8.4 Security Layer . . . . . . . . . . . . . . . . . . . . . . . 35
104 9. EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
105 9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 36
106 9.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 36
107 9.3 Method Details . . . . . . . . . . . . . . . . . . . . . . . 36
108 9.4 Security Claims . . . . . . . . . . . . . . . . . . . . . . 37
112 Burdis & Naffah Expires November 28, 2003 [Page 2]
114 Internet-Draft SRP Authentication Mechanism May 2003
117 10. Security Considerations . . . . . . . . . . . . . . . . . . 40
118 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
119 Normative References . . . . . . . . . . . . . . . . . . . . 42
120 Informative References . . . . . . . . . . . . . . . . . . . 44
121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46
122 A. Modulus and Generator Values . . . . . . . . . . . . . . . . 47
123 B. Changes since the previous draft . . . . . . . . . . . . . . 49
124 Intellectual Property and Copyright Statements . . . . . . . 50
168 Burdis & Naffah Expires November 28, 2003 [Page 3]
170 Internet-Draft SRP Authentication Mechanism May 2003
175 The Secure Remote Password (SRP) is a password-based, zero-knowledge,
176 authentication and key-exchange protocol developed by Thomas Wu. It
177 has good performance, is not plaintext-equivalent and maintains
178 perfect forward secrecy. It provides authentication (optionally
179 mutual authentication) and the negotiation of a shared context key
182 The mechanism described herein is based on the SRP-6 protocol,
183 described in [SRP-6] and [SRP-6i]. SRP-6 is an improved version of
184 the original SRP protocol (also called SRP-3) described in
185 [RFC-2945]. Due to the design of the mechanism, mutual
186 authentication is MANDATORY.
224 Burdis & Naffah Expires November 28, 2003 [Page 4]
226 Internet-Draft SRP Authentication Mechanism May 2003
229 2. Conventions Used in this Document
231 o A hex digit is an element of the set:
233 {0, 1, 2, 3, 4, 5, 6, 7, 8 , 9, A, B, C, D, E, F}
235 A hex digit is the representation of a 4-bit string. Examples:
241 o An octet is an 8-bit string. In this document an octet may be
242 written as a pair of hex digits. Examples:
248 o All data is encoded and sent in network byte order (big-endian).
250 o The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
251 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
252 in this document are to be interpreted as described in [RFC-2119].
280 Burdis & Naffah Expires November 28, 2003 [Page 5]
282 Internet-Draft SRP Authentication Mechanism May 2003
285 3. Data Element Formats
287 This section describes the encoding of the data elements used by the
288 mechanism described in this document.
292 Scalar numbers are unsigned quantities. Using b[k] to refer to the
293 k-th octet being processed, the value of a two-octet scalar is:
295 ((b[0] << 8) + b[1]),
297 where << is the bit left-shift operator. The value of a four-octet
300 ((b[0] << 24) + (b[1] << 16) + (b[2] << 8) + b[3]).
303 3.2 Multi-Precision Integers
305 Multi-Precision Integers, or MPIs, are positive integers used to hold
306 large integers used in cryptographic computations.
308 MPIs are encoded using a scheme inspired by that used by OpenPGP -
309 [RFC-2440] (section 3.2) - for encoding such entities:
311 The encoded form of an MPI SHALL consist of two pieces: a
312 two-octet scalar that represents the length of the entity, in
313 octets, followed by a sequence of octets that contain the actual
316 These octets form a big-endian number; A big-endian number can be
317 encoded by prefixing it with the appropriate length.
319 Examples: (all numbers are in hexadecimal)
321 The sequence of octets [00 01 01] encodes an MPI with the value
322 1, while the sequence [00 02 01 FF] encodes an MPI with the
327 * The length field of an encoded MPI describes the octet count
328 starting from the MPI's first non-zero octet, containing the
329 most significant non-zero bit. Thus, the encoding [00 02 01]
330 is not formed correctly; It should be [00 01 01].
332 We shall use the syntax mpi(A) to denote the encoded form of the
336 Burdis & Naffah Expires November 28, 2003 [Page 6]
338 Internet-Draft SRP Authentication Mechanism May 2003
341 multi-precision integer A. Furthermore, we shall use the syntax
342 bytes(A) to denote the big-endian sequence of octets forming the
343 multi-precision integer with the most significant octet being the
344 first non-zero octet containing the most significant bit of A.
348 This mechanism generates, uses and exchanges sequences of octets;
349 e.g. output values of message digest algorithm functions. When such
350 entities travel on the wire, they shall be preceded by a one-octet
351 scalar quantity representing the count of following octets.
353 Note that a zero-length octet sequence is encoded as a single 00
356 We shall use the syntax os(s) to denote the encoded form of the octet
357 sequence. Furthermore, we shall use the syntax bytes(s) to denote
358 the sequence of octets s, in big-endian order.
360 3.4 Extended Octet Sequences
362 Extended sequences of octets are exchanged when using the security
363 layer. When these sequences travel on the wire, they shall be
364 preceded by a four-octet scalar quantity representing the count of
367 We shall use the syntax eos(s) to denote the encoded form of the
368 extended octet sequence. Furthermore, we shall use the syntax
369 bytes(s) to denote the sequence of octets s, in big-endian order.
373 The only character set for text is the UTF-8 encoding [RFC-2279] of
374 Unicode characters [ISO-10646]. All text MUST be in Unicode
375 Normalization Form KC [UNICODE-KC] without NUL characters.
377 In addition, to avoid non-interoperability due to incompatible
378 normalisation techniques, the client MUST prepare strings using the
379 [SASLprep] profile of [RFC-3454]
381 We shall use the syntax utf8(L) to denote the string L in UTF-8
382 encoding, preceded by a two-octet scalar quantity representing the
383 count of following octets. Furthermore, we shall use the syntax
384 bytes(L) to denote the sequence of octets representing the UTF-8
385 encoding of L, in big-endian order.
387 Not that the empty string is encoded as the two octet sequence 00 00.
392 Burdis & Naffah Expires November 28, 2003 [Page 7]
394 Internet-Draft SRP Authentication Mechanism May 2003
399 In this mechanism data is exchanged between the client and server
400 using buffers. A buffer acts as an envelope for the sequence of data
401 elements sent by one end-point of the exchange, and expected by the
404 A buffer MAY NOT contain other buffers. It may only contain zero,
405 one or more data elements.
407 A buffer shall be encoded as two fields: a four-octet scalar quantity
408 representing the count of following octets, and the concatenation of
409 the octets of the data element(s) contained in the buffer.
411 We shall use the syntax {A|B|C} to denote a buffer containing A, B
412 and C in that order. For example:
414 { mpi(N) | mpi(g) | utf8(L) }
416 is a buffer containing, in the designated order, the encoded forms of
417 an MPI N, an MPI g and a Text L.
419 3.7 Data Element Size Limits
421 The following table details the size limit, in number of octets, for
422 each of the data element encodings described earlier.
424 Data element type Header Size limit in octets
425 (octets) (excluding header)
426 ------------------------------------------------------------
430 Extended Octet Sequence 4 2,147,483,383
431 Buffer 4 2,147,483,643
433 An implementation MUST signal an exception if any size constraint is
436 3.8 Unsigned Integers
438 This mechanism uses unsigned integer values ranging from zero to
441 When such entities travel on the wire, they shall be encoded as
442 4-octet Scalar Numbers. We shall use the syntax uint(n) to denote
443 the encoding of an Unsigned Integer n.
448 Burdis & Naffah Expires November 28, 2003 [Page 8]
450 Internet-Draft SRP Authentication Mechanism May 2003
453 4. Protocol Description
455 The following sections describe the sequence of data transmitted
456 between the client and server for SRP authentication, as well as the
457 extra control information exchanged to enable a client to request
458 whether or not replay detection, integrity protection and/or
459 confidentiality protection should be provided by a security layer.
460 There are two possible mechanism data exchanges during the
461 authentication phase:
463 The following exchange occurs when a new session is negotiated
464 between the client and the server. It will also occur when the
465 client requests re-use of the parameters of a previous session and
466 either the server does not support such re-use or no longer considers
467 the previous session to be valid:
471 --- { utf8(U) | utf8(I) | utf8(sid) | os(cn) } ------------->
473 <------ { 00 | mpi(N) | mpi(g) | os(s) | mpi(B) | utf8(L) } ---
475 --- { mpi(A) | os(M1) | utf8(o) | os(cIV) } ---------------->
477 <------ { os(M2) | os(sIV) | utf8(sid) | uint(ttl) } ---------
481 U is the authentication identity (username),
483 I is the authorisation identity (userid),
485 sid is the identifier of a previous session whose parameters the
486 client wishes to re-use,
488 cn is the client's nonce used in deriving a new shared context
489 key from the shared context key of the previous session,
491 00 is an octet indicating that the previous session parameters
494 N is the safe prime modulus,
498 s is the user's password salt,
500 B is the server's ephemeral public key,
504 Burdis & Naffah Expires November 28, 2003 [Page 9]
506 Internet-Draft SRP Authentication Mechanism May 2003
509 L is the options list indicating available security services,
511 A is the client's ephemeral public key,
513 M1 is the client's evidence that the shared key K is known,
515 o is the options list indicating chosen security services,
517 cIV is the client's initial vector for the chosen encryption
520 M2 is the server's evidence that the shared key K is known.
522 sIV is the server's initial vector for the chosen encryption
525 sid is the identifier the server gives to this session for
526 possible later re-use of the negotiated parameters,
528 ttl is the time period for which this session's parameters may be
531 The following exchange occurs when the client requests that the
532 parameters negotiated in a previous session be re-used in this
533 session, but with a newly derived shared context key, and the server
538 --- { utf8(U) | utf8(I) | utf8(sid) | os(cn) } -------------->
540 <---------------------------------- { FF | os(sn) } ----------
544 U is the authentication identity (username),
546 I is the authorisation identity (userid),
548 sid is the identifier of a previous session whose parameters the
549 client wishes to re-use,
551 cn is the client's nonce used in deriving a new shared context
552 key from the shared context key of the previous session,
554 FF is an octet indicating that the previous session parameters
560 Burdis & Naffah Expires November 28, 2003 [Page 10]
562 Internet-Draft SRP Authentication Mechanism May 2003
565 sn is the server's nonce used in deriving a new shared context
566 key from the shared context key of the previous session,
569 4.1 Client Sends its Identity
571 The client determines its authentication identity U and authorisation
572 identity I, encodes them and sends them to the server.
574 The semantics of both U and I are intended to be the same as
575 described in [SASL]. Specifically, the authentication identity U is
576 derived from the client's authentication credentials, and the
577 authorisation identity I is used by the server as the primary
578 identity for making access policy decisions.
580 As a client might not have the same information as the server,
581 clients SHOULD NOT themselves try to derive authorisation identities
582 from authentication identities. When an authorisation identity is
583 not specified by the user the client SHOULD send an empty string
586 If the client does not wish to re-use parameters negotiated in a
587 previous session then it sets sid to the empty string and cn to a
588 zero-length octet sequence.
590 However, if the client does wish to attempt to re-use the parameters
591 negotiated in a previous session then it sets sid to the session
592 identifier for that session, and sets cn as follows:
598 prng() is a random number generation function that outputs at
599 least 16 octets of data.
601 See Section 6.4 for more information on re-using negotiated
602 parameters of a previous session.
606 { utf8(U) | utf8(I) | utf8(sid) | os(cn) }
609 4.2 Server Agrees to Re-use Parameters of a Previous Session
611 If the server supports re-using the parameters negotiated in a
612 previous session and it considers the previous session, identified by
616 Burdis & Naffah Expires November 28, 2003 [Page 11]
618 Internet-Draft SRP Authentication Mechanism May 2003
621 the session identifier (sid) received from the client, to be valid,
622 it responds as follows:
624 The server sends the octet FF as the first element of the message to
625 indicate to the client that parameters of the previous session are
626 being re-used. It also generates a nonce (sn), which is later used
627 in deriving a new shared context key for this session:
633 prng() is a random number generation function that outputs at
634 least 16 octets of data.
636 Note that the server nonce (sn) MUST NOT be the same as the client
643 See Section 6.4 for more information on re-using negotiated
644 parameters of a previous session and deriving the new shared context
647 4.3 Server Sends Protocol Elements
649 Otherwise, the server receives U and looks up the safe prime modulus
650 N, the generator g, the salt s, and the verifier v, to be used for
651 that identity. It uses the this information to generate its
652 ephemeral public key B as follows:
656 B = ((3 * v) + (g ** b)) % N;
660 prng() is a random number generation function,
662 b is the MPI that will act as the server's private key,
664 v is the stored password verifier value,
668 N is the safe prime modulus,
672 Burdis & Naffah Expires November 28, 2003 [Page 12]
674 Internet-Draft SRP Authentication Mechanism May 2003
677 * is the multiplication operator,
679 + is the addition operator,
681 ** is the exponentiation operator,
683 % is the modulus operator,
685 The server also creates an options list L, which consists of a
686 comma-separated list of option strings that specify the options the
687 server supports. This options list MUST NOT contain any whitespace
688 characters and all alphabetic characters MUST be in lowercase. When
689 used in digest calculations by the client the options list MUST be
692 The following option strings are defined:
694 o "mda=<MDA-name>" indicates that the server supports the designated
695 hash function as the underlying Message Digest Algorithm for the
696 designated user to be used for all SRP calculations - to compute
697 both client-side and server-side digests. The specified algorithm
698 MUST meet the requirements specified in section 3.2 of [RFC-2945]:
700 "Any hash function used with SRP should produce an output of at
701 least 16 bytes and have the property that small changes in the
702 input cause significant nonlinear changes in the output."
704 Note that in the interests of interoperability between client and
705 server implementations and with other SRP-based tools, both the
706 client and the server MUST support SHA-160 as an underlying
707 Message Digest Algorithm. While the server is not required to
708 list SHA-160 as an available underlying Message Digest Algorithm,
709 it must be able to do so.
711 o "integrity=hmac-<MDA-name>" indicates that the server supports
712 integrity protection using the HMAC algorithm [RFC-2104] with
713 <MDA-name> as the underlying Message Digest Algorithm. Acceptable
714 MDA names are chosen from [SCAN] under the MessageDigest section.
715 A server SHOULD send such an option string for each HMAC algorithm
716 it supports. The server MUST advertise at least one integrity
717 protection algorithm and in the interest of interoperability the
718 server SHOULD advertise support for the HMAC-SHA-160 algorithm.
720 o "replay_detection" indicates that the server supports replay
721 detection using sequence numbers. Replay detection SHALL NOT be
722 activated without also activating integrity protection. If the
723 replay detection option is offered (by the server) and/or chosen
724 (by the client) without explicitly specifying an integrity
728 Burdis & Naffah Expires November 28, 2003 [Page 13]
730 Internet-Draft SRP Authentication Mechanism May 2003
733 protection option, then the default integrity protection option
734 "integrity=hmac-sha-160" is implied and SHALL be activated.
736 o "confidentiality=<cipher-name>" indicates that the server supports
737 confidentiality protection using the symmetric key block cipher
738 algorithm <cipher-name>. The server SHOULD send such an option
739 string for each confidentiality protection algorithm it supports.
740 Note that in the interest of interoperability, if the server
741 offers confidentiality protection, it MUST send the option string
742 "confidentiality=aes" since it is then MANDATORY for it to provide
743 support for the [AES] algorithm.
745 o "mandatory=[integrity|replay_detection|confidentiality]" is an
746 option only available to the server that indicates that the
747 specified security layer option is MANDATORY and MUST be chosen by
748 the client for use in the resulting security layer. If a server
749 specifies an option as mandatory in this way, it MUST abort the
750 connection if the specified option is not chosen by the client.
751 It doesn't make sense for the client to send this option since it
752 is only able to choose options that the server advertises. The
753 client SHOULD abort the connection if the server does not offer an
754 option that it requires. If this option is not specified then
755 this implies that no options are mandatory. The server SHOULD
756 always send the "mandatory=integrity" option indicating that
757 integrity protection is required.
759 o "maxbuffersize=<number-of-bytes>" indicates to the peer the
760 maximum number of raw bytes (excluding the buffer header) to be
761 processed by the security layer at a time, if one is negotiated.
762 The value of <number-of-bytes> MUST NOT exceed the Buffer size
763 limit defined in section 3.7. If this option is not detected by a
764 client or server mechanism, then it shall operate its security
765 layer on the assumption that the maximum number of bytes that may
766 be sent, to the peer server or client mechanism respectively, is
767 the Buffer data size limit indicated in section 3.7. On the other
768 hand, if a recipient detects this option, it shall break any
769 octet-sequence longer than the designated limit into two or more
770 fragments, before sending them separately, in sequence, to the
773 For example, if the server supports integrity protection using the
774 HMAC-SHA-160 and HMAC-MD5 algorithms, replay detection and no
775 confidentiality protection, the options list would be:
777 mda=sha-1,integrity=hmac-sha-160,integrity=hmac-md5,replay_detection
779 The server sends the octet 00 as the first element of the message to
780 indicate to the client that parameters from a previous session are
784 Burdis & Naffah Expires November 28, 2003 [Page 14]
786 Internet-Draft SRP Authentication Mechanism May 2003
793 { 00 | mpi(N) | mpi(g) | os(s) | mpi(B) | utf8(L) }
796 4.4 Client Sends its Ephemeral Public Key and Evidence
798 The client receives the options list L from the server that specifies
799 the Message Digest Algorithm(s) available to be used for all SRP
800 calculations, the security service options the server supports,
801 including the maximum buffer size the server can handle, and the
802 server's ephemeral public key B. The client selects options from
803 this list and creates a new options list o that specifies the
804 selected Message Digest Algorithm to be used for SRP calculations and
805 the security services that will be used in the security layer. At
806 most one available Message Digest Algorithm name, one available
807 integrity protection algorithm and one available confidentiality
808 protection algorithm may be selected. In addition the client may
809 specify the maximum buffer size it can handle. The client MUST
810 include any option specified by the mandatory option.
812 The client SHOULD always select an integrity protection algorithm
813 even if the server does not make it mandatory to do so. If the
814 client selects a confidentiality protection algorithm it SHOULD then
815 also select an integrity protection algorithm.
817 The options list o MUST NOT contain any whitespace characters and all
818 alphabetic characters MUST be in lowercase. When used in digest
819 calculations by the server the options list MUST be used as received.
821 The client generates its ephemeral public key A as follows:
829 a is the MPI that will act as the client's private key,
831 The client also calculates the shared context key K, and calculates
832 the evidence M1 that proves to the server that it knows the shared
833 context key K, as well as the server's ephemeral public key B, the
834 user's authorisation identity I and the server's options list L.
836 K, on the client's side is computed as follows:
840 Burdis & Naffah Expires November 28, 2003 [Page 15]
842 Internet-Draft SRP Authentication Mechanism May 2003
845 x = H(s | H(U | ":" | p));
849 S = ((B - (3 * (g ** x))) ** (a + (u * x))) % N;
855 s is the user's password salt,
857 U is the authentication identity (username),
859 p is the password value.
861 A is the client's ephemeral public key,
863 B is the server's ephemeral public key,
867 N is the safe prime modulus,
869 H() is the result of digesting the designated input/data with the
870 chosen underlying Message Digest Algorithm function.
872 - is the subtraction operator,
874 * is the multiplication operator,
876 + is the addition operator,
878 ** is the exponentiation operator,
880 % is the modulus operator,
884 H( bytes(H( bytes(N) )) ^ bytes( H( bytes(g) ))
885 | bytes(H( bytes(U) ))
890 | bytes(H( bytes(I) ))
891 | bytes(H( bytes(L) ))
896 Burdis & Naffah Expires November 28, 2003 [Page 16]
898 Internet-Draft SRP Authentication Mechanism May 2003
903 ^ is the bitwise XOR operator.
905 All parameters received from the server that are used as input to a
906 digest operation MUST be used as received.
908 If the client chooses to activate the Confidentiality Protection
909 service in the Security Layer, it MUST send the Initial Vector cIV
910 that the server will use to set up its encryption context. (See
911 Section 5.2 for details on the Confidentiality Protection service and
912 how cIV is generated.) However, this element MAY be a zero-length
913 octet stream if the server does not advertise the Confidentiality
914 Protection service or the client decides not to activate it.
918 { mpi(A) | os(M1) | utf8(o) | os(cIV) }
921 4.5 Server Verifies Client's Evidence and Sends its Evidence
923 The server calculates the shared context key K, and verifies the
924 client's evidence M1.
926 K, on the server's side is computed as follows:
930 S = ((A * (v ** u)) ** b) % N;
936 A is the client's ephemeral public key,
938 B is the server's ephemeral public key,
940 v is the stored password verifier value,
942 b is the server's ephemeral private key,
944 N is the safe prime modulus,
946 H() is the result of digesting the designated input/data with the
947 chosen underlying Message Digest Algorithm function.
952 Burdis & Naffah Expires November 28, 2003 [Page 17]
954 Internet-Draft SRP Authentication Mechanism May 2003
957 * is the multiplication operator,
959 ** is the exponentiation operator,
961 % is the modulus operator,
963 If the client chose to activate the Confidentiality Protection
964 service in the Security Layer then the server MUST send the Initial
965 Vector sIV that the client will use to set up its encryption context.
966 (See Section 5.2 for details on the Confidentiality Protection
967 service and how sIV is generated.) However, this element MAY be a
968 zero-length octet sequence if the client did not choose to activate
969 the Confidentiality Protection service.
971 If the server's policy allows re-using the parameters of this session
972 then it sets sid to a unique identifier for this session and sets ttl
973 to the number of seconds for which the session MAY be valid. If the
974 server does not support re-using the parameters of this session then
975 it sets sid to the empty string and ttl to any value. See Section
976 6.4 for more information on re-using negotiated parameters of a
979 The server computes its evidence M2, which proves to the client that
980 it knows the shared context key K, as well as U, I and o, as follows:
985 | bytes(H( bytes(I) ))
986 | bytes(H( bytes(o) ))
991 All parameters received from the client that are used as input to a
992 digest operation MUST be used as received.
996 { os(M2) | os(sIV) | sid | ttl }
1008 Burdis & Naffah Expires November 28, 2003 [Page 18]
1010 Internet-Draft SRP Authentication Mechanism May 2003
1015 Depending on the options offered by the server and chosen by the
1016 client, the security layer may provide integrity protection, replay
1017 detection, and/or confidentiality protection.
1019 The security layer can be thought of as a three-stage filter through
1020 which the data flows from the output of one stage to the input of the
1021 following one. The first input is the original data, while the last
1022 output is the data after being subject to the transformations of this
1025 The data always passes through this three-stage filter, though any of
1026 the stages may be inactive. Only when a stage is active would the
1027 output be different from the input. In other words, if a stage is
1028 inactive, the octet sequence at the output side is an exact duplicate
1029 of the same sequence at the input side.
1031 Schematically, the three-stage filter security layer appears as
1034 +----------------------------+
1036 p1 --->| Confidentiality protection |---+
1038 +----------------------------+ |
1040 +------------------------------------+
1042 | +----------------------------+
1044 p2 +-->| Replay detection |---+
1046 +----------------------------+ |
1048 +------------------------------------+
1050 | +----------------------------+
1052 p3 +-->| Integrity protection |--->
1054 +----------------------------+
1058 p1, p2 and p3 are the input octet sequences at each stage,
1060 I/ denotes the output at the end of one stage if/when the stage is
1064 Burdis & Naffah Expires November 28, 2003 [Page 19]
1066 Internet-Draft SRP Authentication Mechanism May 2003
1069 inactive or disabled,
1071 A/ denotes the output at the end of one stage if/when the stage is
1074 c is the encrypted (sender-side) or decrypted (receiver-side)
1075 octet sequence. c1 shall denote the value computed by the sender,
1076 while c2 shall denote the value computed by the receiver.
1078 q is a four-octet scalar quantity representing a sequence number,
1080 C is the Message Authentication Code. C1 shall denote the value
1081 of the MAC as computed by the sender, while C2 shall denote the
1082 value computed by the receiver.
1084 It is worth noting here that both client and server have their own
1085 distinct security contexts, including distinct encryption and
1086 decryption sub-contexts. In principal, nothing in this specification
1087 should prevent an implementation from supporting asynchronous
1090 5.1 Cryptographic Primitives
1092 5.1.1 Pseudo Random Number Generator
1094 This mechanism requires random data to be generated for use in:
1096 1. The CALG key material for both the client and server when the
1097 Confidentiality Protection service is enabled.
1099 2. The IALG key material for both the client and server when the
1100 Integrity Protection service is enabled.
1102 The PRNG used in this specification is based on the pseudo-random
1103 function described in section 5 of [UMAC]. It uses the [AES]
1104 algorithm, in its 128-bit key size variant, as the underlying
1105 symmetric key block cipher for its operations.
1107 A formal description of this PRNG follows:
1111 * SK: a 16-octet sequence (seeding key to AES)
1115 * n: a positive integer
1120 Burdis & Naffah Expires November 28, 2003 [Page 20]
1122 Internet-Draft SRP Authentication Mechanism May 2003
1127 * Y: an n-octet sequence
1133 1. Initialise an AES instance for encryption with the first 16
1134 octets of SK as its user-supplied key material. Let "aes"
1135 be that instance; i.e. aes = AES(SK, ENCRYPTION);
1137 2. Initialise T to be an all-zero 16-octet long sequence;
1141 1. Initialise "remaining" to n;
1143 2. Initialise Y to be a 0-length octet sequence;
1145 3. while (remaining > 0) do
1149 2. Append m octets from T to Y, where m is the minimum of
1152 3. Subtract 16 from remaining;
1156 In this document, "PRNG(key,n)" will refer to this algorithm, with
1157 the initialisation parameter SK set to be the octets of the specified
1158 key, returning n bits of pseudo-random data. For example,
1159 "PRNG(K,n)" will refer to this algorithm, with the initialisation
1160 parameters SK set to the shared context key K computed by the SRP
1161 calculations (see Section 4.4 and Section 4.5), returning n bits of
1164 This algorithm MAY also be used as part of the SRP calculations to
1165 generate the required "a" and "b" parameters used in creating the
1166 client and server ephemeral private keys ("A" and "B"), or to
1167 generate the cn and sn parameters used in session re-use, or to
1168 generate the initial vectors sIV and cIV used to set up the
1169 encryption contexts. In this case the initialisation parameter SK can
1170 be any 16-octet sequence (e.g. multiple representations of the
1176 Burdis & Naffah Expires November 28, 2003 [Page 21]
1178 Internet-Draft SRP Authentication Mechanism May 2003
1181 If the same PRNG instance is used for both these calculations and the
1182 calculations in this specification, it MUST be re-initialised with
1183 the shared context key K before any of the latter calculations are
1186 5.1.2 Key Derivation Function
1188 During the authentication phase, both parties compute the shared
1189 context key K (see Section 4.4 for the client, and Section 4.5 for
1190 the server sides respectively). The length of K is s bits, where "s"
1191 is the output length of the chosen underlying Message Digest
1192 Algorithm used in the SRP calculations (see "mda" option in Section
1195 When Confidentiality Protection is required, and the length of K is
1196 not equal to the length of the user-supplied key material needed to
1197 initialise the chosen Confidentiality Algorithm (CALG), the peers
1198 MUST apply the Key Derivation Function (KDF) in order to obtain
1199 enough data for this purpose.
1201 Similarly, when Integrity Protection is required, and the length of K
1202 is not equal to the required length of the key material needed to
1203 initialise the chosen Integrity Algorithm (IALG), the peers MUST
1204 apply the Key Derivation Function (KDF) in order to obtain enough
1205 data for this purpose too.
1207 If the KDF is required for both the key used with the CALG and the
1208 key used with the IALG then it is first applied for the CALG key and
1209 thereafter for the IALG key.
1211 We define this KDF as:
1217 Km is the required key material,
1219 K is the shared context key, and
1221 n is the required length of Km.
1223 The following steps describe the KDF algorithm:
1225 If length of K is greater than or equal to n, then
1227 Let Km be the first n bytes of K;
1232 Burdis & Naffah Expires November 28, 2003 [Page 22]
1234 Internet-Draft SRP Authentication Mechanism May 2003
1239 Let Km = PRNG(K, n);
1244 5.2 Confidentiality Protection
1246 The plaintext data octet sequence p1 is encrypted using the chosen
1247 confidentiality algorithm (CALG) with key size m, initialised for
1248 encryption with the key material Kc obtained as follows:
1252 c1 = CALG(Kc, ENCRYPTION)( bytes(p1) )
1254 On the receiving side, the ciphertext data octet sequence p1 is
1255 decrypted using the chosen confidentiality algorithm (CALG)
1256 initialised for decryption, with the key Kc obtained by a similar
1261 c2 = CALG(Kc, DECRYPTION)( bytes(p1) )
1263 The designated CALG symmetric-key block cipher MUST be used in OFB
1264 (Output Feedback Block) mode in the ISO variant, as described in
1265 [HAC], algorithm 7.20.
1267 Let k be the block size of the chosen symmetric key block cipher
1268 algorithm; e.g. for AES this is 128 bits or 16 octets. The OFB mode
1269 used shall have a block size of k.
1271 It is recommended that block ciphers operating in OFB mode be used
1272 with an Initial Vector (the mode's IV). In such a mode of operation
1273 - OFB with key re-use - the IV need not be secret. For the mechanism
1274 described in this document, the server MUST use cIV received from the
1275 client as the Initial Vector when initialising its encryption
1276 context, and the client MUST use sIV received from the server as the
1277 Initial Vector when initialising its encryption context. These
1278 Initial Vectors are generated as:
1288 Burdis & Naffah Expires November 28, 2003 [Page 23]
1290 Internet-Draft SRP Authentication Mechanism May 2003
1293 prng() is a random number generation function that outputs k
1296 k is the block size of the chosen symmetric key block cipher
1299 The input data to the confidentiality protection algorithm shall be a
1300 multiple of the symmetric key block cipher block size k. When the
1301 input length is not a multiple of k octets, the data shall be padded
1302 according to the following scheme (described in [PKCS7] which itself
1303 is based on [RFC-1423]):
1305 Assuming the length of the input is l octets, (k - (l mod k))
1306 octets, all having the value (k - (l mod k)), shall be appended to
1307 the original data. In other words, the input is padded at the
1308 trailing end with one of the following sequences:
1312 01 -- if l mod k = k-1
1313 02 02 -- if l mod k = k-2
1317 k k ... k k -- if l mod k = 0
1319 The padding can be removed unambiguously since all input is padded
1320 and no padding sequence is a suffix of another. This padding
1321 method is well-defined if and only if k < 256 octets, which is the
1322 case with symmetric block ciphers today, and in the forseeable
1325 The output of this stage, when it is active, is:
1327 at the sending side: CALG(Kc, ENCRYPT)( bytes(p1) )
1329 at the receiving side: CALG(Kc, DECRYPT)( bytes(p1) )
1332 5.3 Replay Detection
1334 A sequence number q is incremented every time a message is sent to
1337 The output of this stage, when it is active, is:
1344 Burdis & Naffah Expires November 28, 2003 [Page 24]
1346 Internet-Draft SRP Authentication Mechanism May 2003
1349 At the other end, the receiver increments its instance of the
1350 sequence number. This new value of the sequence number is then used
1351 in the integrity protection transformation, which must also be active
1352 as described in Section 4.3. See Section 6.3 for more details.
1354 5.4 Integrity Protection
1356 When the Integrity Protection stage is active, a message
1357 authentication code C is computed using the chosen integrity
1358 protection algorithm (IALG) as follows:
1360 o the IALG is initialised (once) with the key material Ki of size n
1361 (the required key size of the chosen IALG); i.e. Ki = KDF(n),
1363 o the IALG is updated with every exchange of the sequence p3,
1364 yielding the value C and a new IALG context for use in the
1367 At the other end, the receiver computes its version of C, using the
1368 same transformation, and checks that its value is equal to that
1369 received. If the two values do not agree, the receiver MUST signal an
1370 exception and abort.
1372 The output of this stage, when it is active, is then:
1374 IALG(Ki)( bytes(p3) )
1377 5.5 Summary of Security Layer Output
1379 The following table shows the data exchanged by the security layer
1380 peers, depending on the possible legal combinations of the three
1381 security services in operation:
1383 CP IP RD Peer sends/receives
1386 I A I { eos(p) | os( IALG(Ki)( bytes(p) ) ) }
1387 I A A { eos(p) | os( IALG(Ki)( bytes(p) | bytes(q)) ) }
1389 A A I { eos(c) | os( IALG(Ki)( bytes(c) ) ) }
1390 A A A { eos(c) | os( IALG(Ki)((bytes(c) | bytes(q)) )}
1394 CP Confidentiality protection,
1396 IP Integrity protection,
1400 Burdis & Naffah Expires November 28, 2003 [Page 25]
1402 Internet-Draft SRP Authentication Mechanism May 2003
1405 RD Replay detection,
1407 I Security service is Inactive/disabled,
1409 A Security service is Active/enabled,
1411 p The original plaintext,
1413 q The sequence number.
1415 c The enciphered input obtained by either:
1417 CALG(Kc, ENCRYPT)( bytes(p) ) at the sender's side, or
1419 CALG(Kc, DECRYPT)( bytes(p) ) at the receiver's side
1456 Burdis & Naffah Expires November 28, 2003 [Page 26]
1458 Internet-Draft SRP Authentication Mechanism May 2003
1463 6.1 Mandatory Algorithms
1465 The algorithms specified as mandatory were chosen for utility and
1466 availablity. We felt that a mandatory confidentiality and integrity
1467 protection algorithm for the security layer and a mandatory Message
1468 Digest Algorithm for SRP calculations should be specified to ensure
1469 interoperability between implementations of this mechanism:
1471 o The SHA-160 Message Digest Algorithm was chosen as an underlying
1472 algorithm for SRP calculations because this allows for easy
1473 interoperability with other SRP-based tools that use the SRP-SHA1
1474 protocol described in section 3 of [RFC-2945] and create their
1475 password files using this algorithm.
1477 o The HMAC algorithm was chosen as an integrity algorithm because it
1478 is faster than MAC algorithms based on secret key encryption
1479 algorithms [RFC-2847].
1481 o AES was chosen as a symmetric-key block cipher because it has
1482 undergone thorough scrutiny by the best cryptographers in the
1485 Since confidentiality protection is optional, this mechanism should
1486 be usable in countries that have strict controls on the use of
1489 6.2 Modulus and Generator Values
1491 It is RECOMMENDED that the server use values for the modulus N and
1492 generator g chosen from those listed in Appendix A so that the client
1493 can avoid expensive constraint checks, since these predefined values
1494 already meet the constraints described in [RFC-2945]:
1496 "For maximum security, N should be a safe prime (i.e. a number of
1497 the form N = 2q + 1, where q is also prime). Also, g should be a
1498 generator modulo N (see [SRP] for details), which means that for
1499 any X where 0 < X < N, there exists a value x for which g**x == X
1502 If other values are used for N and g then these values SHOULD undergo
1503 the specified constraint checks.
1505 6.3 Replay Detection Sequence Number Counters
1507 The mechanism described in this document allows the use of a Replay
1508 Detection security service that works by including sequence number
1512 Burdis & Naffah Expires November 28, 2003 [Page 27]
1514 Internet-Draft SRP Authentication Mechanism May 2003
1517 counters in the message authentication code (MAC) created by the
1518 Integrity Protection service. As noted in Section 4.3 integrity
1519 protection is always activated when the Replay Detection service is
1522 Both the client and the server keep two sequence number counters.
1523 Each of these counters is a 32-bit unsigned integer initialised with
1524 a Starting Value and incremented by an Increment Value with every
1525 successful transmission of a data buffer through the security layer.
1526 The Sent counter is incremented for each buffer sent through the
1527 security layer. The Received counter is incremented for each buffer
1528 received through the security layer. If the value of a sequence
1529 number counter exceeds 2**32-1 it wraps around and starts from zero
1532 When a sender sends a buffer it includes the value of its Sent
1533 counter in the computation of the MAC accompanying each integrity
1534 protected message. When a recipient receives a buffer it uses the
1535 value of it's Received counter in its computation of the integrity
1536 protection MAC for the received message. The recipient's Received
1537 counter must be the same as the sender's Sent counter in order for
1538 the received and computed MACs to match.
1540 This specification assumes that for each sequence number counter the
1541 Starting Value is ZERO, and that the Increment Value is ONE. These
1542 values do not affect the security or the intended objective of the
1543 replay detection service, since they never travel on the wire.
1545 6.4 Re-using the Parameters of a Previous Session
1547 Re-using the parameters of a previous session enables the client and
1548 server to avoid the overhead of the full authentication exchange
1549 where the client and server communicate more than once during a
1550 server-specified time period.
1552 Servers are not required to support re-using the parameters of the
1553 current session in future sessions. If they do not wish to support
1554 this then they send an empty string for the session identifier (sid).
1555 However, if the server's policy allows for the parameters of the
1556 current session to be re-used later, it generates a session
1557 identifier (sid) that will uniquely identify the session within the
1558 specified time period (ttl). The time period (ttl) is specified in
1559 seconds and only gives an indication to the client how long the
1560 session may be valid. The server is not required to ensure that the
1561 session is valid for this time period. Note that a ttl of 0 indicates
1562 an indeterminate time period.
1564 To avoid session hijacking, servers SHOULD NOT indicate that a
1568 Burdis & Naffah Expires November 28, 2003 [Page 28]
1570 Internet-Draft SRP Authentication Mechanism May 2003
1573 session may be re-used unless a security layer with integrity
1574 protection and/or confidentiality protection has been negotiated.
1576 Clients are not required to support re-using the parameters of
1577 previous sessions. If they do not wish to support it or they do not
1578 wish to re-use the parameters of a previous session then they send
1579 the empty string as the value for the session identifier (sid) and
1580 send a zero-length octet sequence for the nonce (cn). If they do
1581 support it and wish to use the parameters of a previous session then
1582 they send the session identifier for this session that they
1583 previously received from the server and calculate cn as described in
1586 If a client specifies a session id (sid) for a session that the
1587 server still considers valid then the server sends the octet FF, to
1588 indicate to the client that parameters of a previous session are
1589 being re-used, and the nonce (sn) calculated as described in Section
1590 4.2. The client and server then calculate the new shared context key
1591 Kn for this session as follows:
1597 K is the shared context key for the previous session identified
1600 H() is the result of digesting the designated input/data with the
1601 Message Digest Algorithm function negotiated in the previous
1602 session identified by sid.
1604 Then, if the confidentiality and/or integrity protection services
1605 were negotiated for the previous session, new keys for these services
1606 are derived using the KDF for use in this session. (See Section
1609 If the server does not support re-using parameters of previous
1610 sessions or no longer considers the specified previous session to be
1611 valid, it ignores the session id specified by the client and
1612 continues the full authentication exchange. However, the first
1613 element of the next buffer it sends is the octet 00, which indicates
1614 to the client that no parameters of a previous session will be
1624 Burdis & Naffah Expires November 28, 2003 [Page 29]
1626 Internet-Draft SRP Authentication Mechanism May 2003
1633 SASL is described as follows [RFC-2222]:
1635 The Simple Authentication and Security Layer (SASL) is a method
1636 for adding authentication support to connection-based protocols.
1638 This document describes a mechanism that can be used within the SASL
1639 authentication framework.
1643 The SASL mechanism name associated with this protocol is "SRP".
1647 Section 3 of [RFC-2222] describes the operation of the security layer
1650 "The security layer takes effect immediately following the last
1651 response of the authentication exchange for data sent by the
1652 client and the completion indication for data sent by the server.
1653 Once the security layer is in effect, the protocol stream is
1654 processed by the security layer into buffers of cipher-text. Each
1655 buffer is transferred over the connection as a stream of octets
1656 prepended with a four octet field in network byte order that
1657 represents the length of the following buffer. The length of the
1658 cipher-text buffer must be no larger than the maximum size that
1659 was defined or negotiated by the other side."
1662 7.4 Profile Considerations
1664 As mentioned briefly in [RFC-2222], and detailed in [SASL] a SASL
1665 specification has three layers: (a) a protocol definition using SASL
1666 known as the "Profile", (b) a SASL mechanism definition, and (c) the
1669 Point (3) in section 5 of [SASL] ("Protocol profile requirements")
1670 clearly states that it is the responsibility of the Profile to define
1671 "...how the challenges and responses are encoded, how the server
1672 indicates completion or failure of the exchange, how the client
1673 aborts an exchange, and how the exchange method interacts with any
1674 line length limits in the protocol."
1676 The username entity, referenced as U throughout this document, and
1680 Burdis & Naffah Expires November 28, 2003 [Page 30]
1682 Internet-Draft SRP Authentication Mechanism May 2003
1685 used by the server to locate the password data, is assumed to travel
1686 "in the clear," meaning that no transformation is applied to its
1687 contents. This assumption was made to allow the same SRP password
1688 files to be used in this mechanism, as those used with other SRP
1689 applications and tools.
1691 A Profile may decide, for privacy or other reason, to disallow such
1692 information to travel in the clear, and instead use a hashed version
1693 of U, or more generally a transformation function applied to U; i.e.
1694 f(U). Such a Profile would require additional tools to add the
1695 required entries to the SRP password files for the new value(s) of
1696 f(U). It is worth noting too that if this is the case, and the same
1697 user shall access the server through this mechanism as well as
1698 through other SRP tools, then at least two entries, one with U and
1699 the other with f(U) need to be present in the SRP password files if
1700 those same files are to be used for both types of access.
1704 The example below uses SMTP authentication [RFC-2554]. The base64
1705 encoding of challenges and responses, as well as the reply codes
1706 preceding the responses are part of the SMTP authentication
1707 specification, not part of this SASL mechanism itself.
1709 "C:" and "S:" indicate lines sent by the client and server
1712 S: 220 smtp.example.com ESMTP server ready
1714 C: EHLO zaau.example.com
1716 S: 250-smtp.example.com
1717 S: 250 AUTH SRP CRAM-MD5 DIGEST-MD5
1719 C: AUTH SRP AAAADAAEdGVzdAAEdGVzdA==
1727 S: 334 AAABygEArGvbQTJKmpvxZt5eE4lYL69ytmUZh+4H/DGSlD21YFCjcynLtKCZ
1728 7YGT4HV3Z6E91SMSq0sDMQ3Nf0ip2gT9UOgIOWntt2ewz2CVF5oWOrNmGgX71fqq6Ck
1729 YqZYvC5O4Vfl5k+yXXuqoDXQK2/T/dHNZ0EHVwz6nHSgeRGsUdzvKl7Q6I/uAFna9IH
1730 pDbGSB8dK5B4cXRhpbnTLmiPh3SFRFI7UksNV9Xqd6J3XS7PoDLPvb9S+zeGFgJ5AE5
1731 Xrmr4dOcwPOUymczAQce8MI2CpWmPOo0MOCca41+Onb+7aUtcgD2J965DXeI21SX1R1
1732 m2XjcvzWjvIPpxEfnkr/cwABAgqsi3AvmIqdEbREALhtZGE9U0hBLTEsbWFuZGF0b3J
1736 Burdis & Naffah Expires November 28, 2003 [Page 31]
1738 Internet-Draft SRP Authentication Mechanism May 2003
1741 5PXJlcGxheSBkZXRlY3Rpb24scmVwbGF5IGRldGVjdGlvbixpbnRlZ3JpdHk9aG1hYy
1742 1zaGExLGludGVncml0eT1obWFjLW1kNSxjb25maWRlbnRpYWxpdHk9YWVzLGNvbmZpZ
1743 GVudGlhbGl0eT1jYXN0NSxjb25maWRlbnRpYWxpdHk9Ymxvd2Zpc2gsbWF4YnVmZmVy
1744 c2l6ZT0yMTQ3NDgzNjQz
1748 N = "21766174458617435773191008891802753781907668374255538511144
1749 6432246898862353838409572109090130860564015713997172358072665816
1750 4960647214841029141336415219736447718088739565548373811507267740
1751 2235101762521901569820740293149529620419333266262073471054548368
1752 7360395197024862265062488610602569718029849535611214426801576680
1753 0076142998822245709041387397397017192709399211475176516806361476
1754 1119615476233422096442783117971236371647333871414335895773474667
1755 3089670508070055093204247996784170368679283167612722742303140675
1756 4829113358247958306143957755934710196177140617368437852270348349
1757 5337037655006751328447510550299250924469288819"
1761 s = "814819216327401865851972"
1763 L = "mda=sha-1,mandatory=replay_detection,replay_detection,integ
1764 rity=hmac-sha1,integrity=hmac-md5,confidentiality=aes,confidenti
1765 ality=cast5,confidentiality=blowfish,maxbuffersize=2147483643"
1767 C: AAABYwEAAp5q/4zhXoTUzXBscozN97SWgfDcAImIk3lNHNvd0b+Dr7jEm6upXblZ
1768 T5sL9mPgFsejlIh+B/eCu/HvzWCrXj6ylPZv8dy3LCH3LIORqQ45S7Lsbmrrg/dukDh
1769 4tZCJMLD4r3evzaY8KVhtJeLMVbeXuh4JljKP42Ll59Lzwf8jfPh4+4Lae1rpWUCL9D
1770 ueKcY+nN+xNHTit/ynLATxwL93P6+GoGY4TkUbUBfjiI1+rAMvyMDMw5XozGy07FOEc
1771 ++U0iPeXCQP4MT5FipOUoz8CYX7J1LbaXp2WJuFHlkyVXF7oCoyHbhld/5CfR3o6q/B
1772 /x9+yZRqaHH+JfllOgBfbWRhPVNIQS0xLHJlcGxheSBkZXRlY3Rpb24saW50ZWdyaXR
1773 5PWhtYWMtbWQ1LGNvbmZpZGVudGlhbGl0eT1ibG93ZmlzaCxtYXhidWZmZXJzaXplPT
1778 A = "33059541846712102497463123211304342021934496372587869281515
1779 9695658237779884462777478850394977744553746930451895815615888405
1780 0562780707370878253753979367019077142882237029766166623275718227
1781 6555389834190840322081091599089081947324537907613924707058150037
1782 7802790776231793962143786411792516760030102436603621046541729396
1783 6890613394379900527412007068242559299422872893332111365840536495
1784 1858834742328835373387573188369956379881606380890675411966073665
1785 1106922002294035533470301541999274557200666703389531481794516625
1786 4757418442215980634933876533189969562613241499465295849832999091
1787 40398081321840949606581251320320995783959866"
1792 Burdis & Naffah Expires November 28, 2003 [Page 32]
1794 Internet-Draft SRP Authentication Mechanism May 2003
1797 o = mda=sha-1,replay_detection,integrity=hmac-md5,confidentialit
1798 y=blowfish,maxbuffersize=2147483643"
1800 S: 334 AAABAgEAOUKbXpnzMhziivGgMwm+FS8sKGSvjh5M3D+80RF/5z9rm0oPoi4+
1801 pF83fueWn4Hz9M+muF/22PHHZkHtlutDrtapj4OtirdxC21fS9bMtEh3F0whTX+3mPv
1802 thw5sk11turandHiLvcUZOgcrAGIoDKcBPoGyBud+8bMgpkf/uGfyBM2nEX/hV+oGgg
1803 X+LiHjmkxAJ3kewfQPH0eV9ffEuuyu8BUcBXkJsS6l7eWkuERSCttVOi/jS031c+CD/
1804 nuecUXYiF8IYzW03rbcwYhZzifmTi3VK9C8zG2K1WmGU+cDKlZMkyCPMmtCsxlbgE8z
1805 SHCuCiOgQ35XhcA0Qa0C3Q==
1809 B: "722842847565031844205403087285424428589273458129750231766015
1810 4465607827529853239240118185263492617243523916106658696965596526
1811 8585300845435562962039149169549800169184521786717633959469278439
1812 8771344445002432579509292115598435685062882631760796416554562980
1813 8475896198325835507901319556929511421472132184990365213059654962
1814 7218189966140113906545856088040473723048909402258929560823932725
1815 2022154114087913895411927676707073040281136096806681758265221209
1816 8822374723416364340410020172215773934302794679034424699999611678
1817 9730443114919539575466941344964841591072763617954717789621871251
1818 71089179399349194452686682517183909017223901"
1820 C: AAAAFRTkoju6xGP+zH89iaDWIFjfIKt5Kg==
1822 S: 235 Authentication successful.
1848 Burdis & Naffah Expires November 28, 2003 [Page 33]
1850 Internet-Draft SRP Authentication Mechanism May 2003
1857 The GSS-API is described as follows:
1859 The Generic Security Service Application Program Interface
1860 (GSS-API), Version 2, as defined in [RFC-2078], provides security
1861 services to callers in a generic fashion, supportable with a range
1862 of underlying mechanisms and technologies and hence allowing
1863 source-level portability of applications to different
1866 According to [RFC-2078] there are certain specifications related to
1867 the GSS-API that are:
1869 "documents defining token formats, protocols, and procedures to be
1870 implemented in order to realize GSS-API services atop particular
1871 security mechanisms"
1873 This specification is such a document - it defines a security
1874 mechanism that can be used with the GSS-API authentication framework.
1878 The tokens referred to in the GSS-API specification [RFC-2078] are
1879 the same as the buffers referred to in this document.
1883 [RFC-2078] states that:
1885 The first context-level token obtained from GSS_Init_sec_context()
1886 is required to indicate at its very beginning a
1887 globally-interpretable mechanism identifier, i.e., an Object
1888 Identifier (OID) of the security mechanism. The remaining part of
1889 this token as well as the whole content of all other tokens are
1890 specific to the particular underlying mechanism used to support
1893 To satisfy this requirement and make use of the mechanism described
1894 in this document as a GSS-API mechanism, the following octets must be
1895 prefixed to the first buffer sent as part of the protocol described
1898 [ 60 08 06 06 2B 06 01 05 05 08 ]
1900 Each octet is written as a pair of hex digits - see Section 2.
1904 Burdis & Naffah Expires November 28, 2003 [Page 34]
1906 Internet-Draft SRP Authentication Mechanism May 2003
1909 These octets represent the encoding of the GSS-API mechanism
1910 identifier as per section 3.1 of [RFC-2078]. The OID for this
1911 mechanism is iso.org.dod.internet.security.mechanisms.srp
1914 Note that it is not possible to make this requirement part of the
1915 security protocol itself, because other authentication frameworks
1916 have different requirements for the initial octets in a mechanism
1921 This mechanism does not provide distinct replay detection and
1922 sequencing services as part of the security layer. Both of these
1923 services are provided through the use of sequence numbers in
1924 integrity protected messages. If a GSS-API caller sets either the
1925 replay_det_req_flag or the sequence_req_flag (section 1.2.3 of
1926 [RFC-2078]) then this selects the "replay_detection" security
1929 This mechanism does not make use of any channel binding data (section
1930 1.1.6 of [RFC-2078]).
1960 Burdis & Naffah Expires November 28, 2003 [Page 35]
1962 Internet-Draft SRP Authentication Mechanism May 2003
1969 The Extensible Authentication Protocol (EAP) [RFC-2284] is an
1970 authentication framework that supports multiple authentication
1971 mechanisms. It is used with link layer protocols such as PPP and the
1972 IEEE-802 wired and wireless protocols.
1976 EAP uses the following terms to describe the entities involved in the
1977 authentication exchange [rfc2284bis]:
1979 Authenticator: The entity that initiates EAP authentication in order
1980 to authenticate a Peer.
1982 Peer: The entity that responds to requests from the Authenticator.
1984 In this document, the Server corresponds to the Authenticator and the
1985 Client corresponds to the Peer.
1989 The EAP authentication method described in this document has the
1990 following properties:
1996 As described in section 2 of [rfc2284bis] the EAP authentication
1997 exchange is initiated by the Authenticator sending a Request packet
1998 to the peer with a Type field indicating the type of request. The
1999 Peer responds with a corresponding Reply packet, and the
2000 Authenticator and Peer exchange additional corresponding Request and
2001 Reply packets until the Authenticator deems that the authentication
2002 exchange is successful and complete, whereafter the Authenticator
2003 sends a Success packet. However, if at any time the Authenticator
2004 deems the authentication exchange to be unsuccessful it sends a
2005 Failure packet to indicate this.
2007 When using this authentication method, the Type field in all Request
2008 and Reply packets is set to 7 and the Type Data is as described in
2009 Section 4 and the rest of this document. The diagrams below
2010 illustrate the EAP packet exchanges for this authentication method.
2012 The following exchange occurs when a new session is negotiated
2016 Burdis & Naffah Expires November 28, 2003 [Page 36]
2018 Internet-Draft SRP Authentication Mechanism May 2003
2021 between the client and the server. It will also occur when the
2022 client requests re-use of the parameters of a previous session and
2023 either the server does not support such re-use or no longer considers
2024 the previous session to be valid:
2026 Peer (client) Authenticator (server)
2028 <------------ Request [ 7, { } ] ----------------------------
2030 ---- Reply [ 7, { U, I, sid, cn } ] ------------------------->
2032 <------------ Request [ 7, { 00, N, g, s, B, L } ] ----------
2034 ---- Reply [ 7, { A, M1, o, cIV } ] ------------------------>
2036 <------------ Request [ 7, { M2, sIV, sid, ttl } ] ----------
2038 ---- Reply [ 7, { } ] -------------------------------------->
2040 The following exchange occurs when the client requests that the
2041 parameters negotiated in a previous session be re-used in this
2042 session, but with a newly derived shared context key, and the server
2045 Peer (client) Authenticator (server)
2047 <----------------------------- Request [ 7, { } ] -----------
2049 --------- Reply [ 7, { U, I, sid, cn } ] ------------------->
2051 <----------------------------- Request [ 7, { FF, sn } ] ----
2053 --------- Reply [ 7, { } ] --------------------------------->
2055 If a security layer is negotiated then the payloads of all subsequent
2056 lower layer packets sent over the link are protected using the
2057 negotiated security services.
2061 As required by section 7.2 of [rfc2284bis], these are the security
2062 claims made by this authentication method indicating the level of
2065 Intended Use: Wired networks, including PPP, PPPOE, and IEEE-802
2066 wired media. Use over the Internet or with wireless media only
2067 when the recommended security layer has been negotiated.
2072 Burdis & Naffah Expires November 28, 2003 [Page 37]
2074 Internet-Draft SRP Authentication Mechanism May 2003
2077 Mechanism: Passphrase
2079 Mutual authentication: Yes. This mechanism requires mutual
2082 Integrity protection: Yes. The calculations of evidence that the
2083 shared context key is known - M1 sent by the client and M2 sent by
2084 the server - include the protocol elements received from the
2085 other party, so any modification by a third party will be
2086 detected. SRP itself is resistent to known active and passive
2087 attacks - see [SRP].
2089 Replay protection: Yes. Both the client and the server randomly
2090 generate ephemeral private keys (a and b) that are used in the SRP
2091 calculations, but are not publicly revealed. New ephemeral
2092 private keys are generated for each session making replay attacks
2095 Confidentiality: No.
2099 Dictionary attack protection: Yes. From [SRP]: "An attacker with
2100 neither the user's password nor the host's password file cannot
2101 mount a dictionary attack on the password".
2103 Fast reconnect: Yes. An optional, optimised alternate authentication
2104 exchange is available where the parameters of a previously
2105 negotiated session are re-used, but with a newly derived shared
2106 context key - see Section 6.4.
2108 Man-in-the-Middle resistance: Yes. The calculations of evidence - M1
2109 sent by the client and M2 sent by the server - include the
2110 protocol elements received from the other party, so any
2111 modification by a third party will be detected. SRP itself is
2112 resistent to known active attacks, including man-in-the-middle
2113 attacks - see [SRP].
2115 Acknowledged result indications: Yes. When the client receives M2
2116 from the server it knows that the server has verified that the
2117 evidence (M1) it presented to prove its knowledge of the shared
2118 context key is correct, so it knows that it is authenticated to
2119 the server. When the server receives the empty response from the
2120 client at the end of the authentication exchange, it knows that
2121 the client has verified that the evidence (M2) it presented to
2122 prove its knowledge of the shared context key is correct, so it
2123 knows that it is authenticated to the client. Similarly for
2124 session re-use where the client receives the server nonce (sn)
2128 Burdis & Naffah Expires November 28, 2003 [Page 38]
2130 Internet-Draft SRP Authentication Mechanism May 2003
2133 from the server, and the server receives the final empty response
2138 Key strength: The shared context key (K) negotiated between the
2139 client and server has a length of s, where "s" is the output
2140 length of the chosen underlying Message Digest Algorithm used in
2141 the SRP calculations (see "mda" option in Section 4.3). For
2142 example, the recommended Message Digest Algorithm SHA-160 has an
2143 output length of 160 bits, so in this case the length of K would
2144 be 160 bits. Keys for the confidentiality and integrity
2145 protection services are derived from K - see Section 5.1.2 - and
2146 have sizes appropriate for the algorithms being used. Note that
2147 all Message Digest Algorithms used with this mechanism MUST have
2148 an output of at least 16 bytes (see "mda" option in Section 4.3),
2149 which means that the shared context key will always have a length
2150 of at least 128 bits.
2184 Burdis & Naffah Expires November 28, 2003 [Page 39]
2186 Internet-Draft SRP Authentication Mechanism May 2003
2189 10. Security Considerations
2191 This mechanism relies on the security of SRP, which bases its
2192 security on the difficulty of solving the Diffie-Hellman problem in
2193 the multiplicative field modulo a large safe prime. See section 4
2194 "Security Considerations" of [RFC-2945], section 4 "Security
2195 analysis" of [SRP], and [SRP-6i].
2197 This mechanism also relies on the security of the HMAC algorithm and
2198 the underlying hash function when integrity protection is used.
2199 Section 6 "Security" of [RFC-2104] discusses these security issues in
2200 detail. Weaknesses found in MD5 do not impact HMAC-MD5 [DOBBERTIN].
2202 U, I, A and o, sent from the client to the server, and N, g, s, B and
2203 L, sent from the server to the client, could be modified by an
2204 attacker before reaching the other party. For this reason, these
2205 values are included in the respective calculations of evidence (M1
2206 and M2) to prove that each party knows the shared context key K.
2207 This allows each party to verify that these values were received
2210 The use of integrity protection is RECOMMENDED to detect message
2211 tampering and to avoid session hijacking after authentication has
2214 Replay attacks may be avoided through the use of sequence numbers,
2215 because sequence numbers make each integrity protected message
2216 exchanged during a session different, and each session uses a
2219 Research [KRAWCZYK] shows that the order and way of combining message
2220 encryption (Confidentiality Protection) and message authentication
2221 (Integrity Protection) are important. This mechanism follows the EtA
2222 (encrypt-then-authenticate) method and is "generically secure".
2224 This mechanism uses a Pseudo-Random Number Generator (PRNG) for
2225 generating some of its parameters. Section 5.1.1 describes a
2226 securely seeded, cryptographically strong PRNG implementation for
2240 Burdis & Naffah Expires November 28, 2003 [Page 40]
2242 Internet-Draft SRP Authentication Mechanism May 2003
2245 11. Acknowledgements
2247 The following people provided valuable feedback in the preparation of
2250 Stephen Farrell <stephen.farrell@baltimore.ie>
2252 Sam Hartman <hartmans@mit.edu>
2254 Timothy Martin <tmartin@andrew.cmu.edu>
2256 Alexey Melnikov <mel@messagingdirect.com>
2258 Ken Murchison <ken@oceana.com>
2260 Magnus Nystrom <magnus@rsasecurity.com>
2262 David Taylor <DavidTaylor@forge.com.au>
2264 Thomas Wu <tom@arcot.com>
2296 Burdis & Naffah Expires November 28, 2003 [Page 41]
2298 Internet-Draft SRP Authentication Mechanism May 2003
2301 Normative References
2304 Linn, J., "Generic Security Service Application Program
2305 Interface, Version 2", RFC 2078, January 1997, <http://
2306 www.ietf.org/rfc/rfc2078.txt>.
2309 Krawczyk, H., "HMAC: Keyed-Hashing for Message
2310 Authentication", RFC 2104, February 1997, <http://
2311 www.ietf.org/rfc/rfc2104.txt>.
2314 Bradner, S., "Key words for use in RFCs to Indicate
2315 Requirement Levels", BCP 0014, RFC 2119, March 1997,
2316 <http://www.ietf.org/rfc/rfc2119.txt>.
2319 Myers, J., "Simple Authentication and Security Layer
2320 (SASL)", RFC 2222, October 1997, <http://www.ietf.org/rfc/
2324 Blunk, L. and J. Vollbrecht, "PPP Extensible
2325 Authentication Protocol (EAP)", RFC 2284, March 1998,
2326 <http://www.ietf.org/rfc/rfc2284.txt>.
2329 Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H.
2330 Levkowetz, "Extensible Authentication Protocol (EAP), work
2331 in progress", May 2003, <http://www.ietf.org/
2332 internet-drafts/draft-ietf-eap-rfc2284bis-03.txt>.
2335 Wu, T., "The SRP Authentication and Key Exchange System",
2336 RFC 2945, September 2000, <http://www.ietf.org/rfc/
2340 Hoffman, P. and M. Blanchet, "Preparation of
2341 Internationalized Strings ("stringprep")", RFC 3454,
2342 December 2002, <http://www.ietf.org/rfc/rfc3454.txt>.
2344 [SASL] Myers, J., "Simple Authentication and Security Layer
2345 (SASL)", April 2002, <http://www.ietf.org/internet-drafts/
2346 draft-myers-saslrev-02.txt>.
2352 Burdis & Naffah Expires November 28, 2003 [Page 42]
2354 Internet-Draft SRP Authentication Mechanism May 2003
2357 Zeilenga, K., "SASLprep: Stringprep profile for user names
2358 and passwords, work in progress", May 2003, <http://
2359 www.ietf.org/internet-drafts/
2360 draft-ietf-sasl-saslprep-01.txt>.
2362 [SRP] Wu, T., "The Secure Remote Password Protocol, Proceedings
2363 of the 1998 Internet Society Network and Distributed
2364 System Security Symposium, San Diego, CA, Mar 1998, pp.
2365 97-111", March 1998, <http://srp.stanford.edu/ndss.html>.
2367 [SRP-6i] Wu, T., "SRP-6: Improvements and Refinements to the Secure
2368 Remote Password Protocol", October 2002, <http://
2369 srp.stanford.edu/srp6.ps>.
2408 Burdis & Naffah Expires November 28, 2003 [Page 43]
2410 Internet-Draft SRP Authentication Mechanism May 2003
2413 Informative References
2415 [AES] National Institute of Standards and Technology, "Rijndael:
2416 NIST's Selection for the AES", December 2000, <http://
2417 csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf>.
2420 Dobbertin, H., "The Status of MD5 After a Recent Attack",
2421 December 1996, <ftp://ftp.rsasecurity.com/pub/cryptobytes/
2424 [HAC] Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook
2425 of Applied Cryptography", CRC Press, Inc., ISBN
2426 0-8493-8523-7, 1997, <http://www.cacr.math.uwaterloo.ca/
2427 hac/about/chap7.ps>.
2430 International Standards Organization, "International
2431 Standard --Information technology-- Universal
2432 Multiple-Octet Coded Character Set (UCS) -- Part 1
2433 Architecture and Basic Multilingual Plane. UTF-8 is
2434 described in Annex R, adopted but not yet published.
2435 UTF-16 is described in Annex Q, adopted but not yet
2436 published.", ISO/IEC 10646-1, 1993.
2439 Krawczyk, H., "The order of encryption and authentication
2440 for protecting communications (Or: how secure is SSL?)",
2441 June 2001, <http://eprint.iacr.org/2001/045/>.
2443 [PKCS7] RSA Data Security, Inc., "PKCS #7: Cryptographic Message
2444 Syntax Standard", Version 1.5, November 1993, <ftp://
2445 ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-7.asc>.
2448 Balenson, D., "Privacy Enhancement for Internet Electronic
2449 Mail: Part III: Algorithms, Modes, and Identifiers", RFC
2450 1423, February 1993, <http://www.ietf.org/rfc/
2454 Yergeau, F., "UTF-8, a transformation format of Unicode
2455 and ISO 10646", RFC 2279, January 1998, <http://
2456 www.ietf.org/rfc/rfc2279.txt>.
2459 Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
2460 "OpenPGP Message Format", RFC 2440, November 1998, <http:/
2464 Burdis & Naffah Expires November 28, 2003 [Page 44]
2466 Internet-Draft SRP Authentication Mechanism May 2003
2469 /www.ietf.org/rfc/rfc2440.txt>.
2472 Myers, J., "SMTP Service Extension for Authentication",
2473 RFC 2554, March 1999.
2476 Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
2477 June 1999, <http://www.ietf.org/rfc/rfc2629.txt>.
2480 Eisler, M., "LIPKEY - A Low Infrastructure Public Key
2481 Mechanism Using SPKM", RFC 2847, June 2000, <http://
2482 www.ietf.org/rfc/rfc2847.txt>.
2484 [SCAN] Hopwood, D., "Standard Cryptographic Algorithm Naming",
2485 June 2000, <http://www.eskimo.com/~weidai/scan-mirror/>.
2487 [SRP-6] Wu, T., "SRP Protocol Design", October 2002, <http://
2488 srp.stanford.edu/design.html>.
2490 [SRPimpl] Wu, T., "SRP: The Open Source Password Authentication
2491 Standard", March 1998, <http://srp.stanford.edu/srp/>.
2493 [UMAC] Black, J., Halevi, S., Krawczyk, H., Krovetz, T. and P.
2494 Rogaway, "UMAC: Fast and Secure Message Authentication,
2495 Advances in Cryptology - CRYPTO '99. Lecture Notes in
2496 Computer Science, vol. 1666, Springer-Verlag, 1999, pp.
2497 216-233", October 2000, <http://www.cs.ucdavis.edu/
2498 ~rogaway/umac/umac_proc.pdf>.
2500 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
2501 3.2.0, is defined by The Unicode Standard, Version 3.0, as
2502 amended by the Unicode Standard Annex #27: Unicode 3.1 and
2503 by the Unicode Standard Annex #28: Unicode 3.2.", March
2504 2002, <http://www.unicode.org/reports/tr28/tr28-3.html>.
2507 Durst, D., "Unicode Standard Annex #15: Unicode
2508 Normalization Forms.", March 2001, <http://
2509 www.unicode.org/unicode/reports/tr15>.
2520 Burdis & Naffah Expires November 28, 2003 [Page 45]
2522 Internet-Draft SRP Authentication Mechanism May 2003
2529 Computer Science Department
2533 EMail: keith@rucus.ru.ac.za
2537 Forge Research Pty. Limited
2539 Locomotive Workshop,
2540 Australian Technology Park
2545 EMail: raif@forge.com.au
2576 Burdis & Naffah Expires November 28, 2003 [Page 46]
2578 Internet-Draft SRP Authentication Mechanism May 2003
2581 Appendix A. Modulus and Generator Values
2583 Modulus N and generator g values for various modulus lengths are
2584 given below. In each case the modulus is a large safe prime and the
2585 generator is a primitve root of GF(n) [RFC-2945]. These values are
2586 taken from software developed by Tom Wu and Eugene Jhong for the
2587 Stanford SRP distribution [SRPimpl].
2591 115B8B692E0E045692CF280B436735C77A5A9E8A9E7ED56C965F87DB5B2A2
2597 8025363296FB943FCE54BE717E0E2958A02A9672EF561953B2BAA3BAACC3E
2598 D5754EB764C7AB7184578C57D5949CCB41B
2603 D4C7F8A2B32C11B8FBA9581EC4BA4F1B04215642EF7355E37C0FC0443EF75
2604 6EA2C6B8EEB755A1C723027663CAA265EF785B8FF6A9B35227A52D86633DB
2610 C94D67EB5B1A2346E8AB422FC6A0EDAEDA8C7F894C9EEEC42F9ED250FD7F0
2611 046E5AF2CF73D6B2FA26BB08033DA4DE322E144E7A8E9B12A0E4637F6371F
2612 34A2071C4B3836CBEEAB15034460FAA7ADF483
2617 B344C7C4F8C495031BB4E04FF8F84EE95008163940B9558276744D91F7CC9
2618 F402653BE7147F00F576B93754BCDDF71B636F2099E6FFF90E79575F3D0DE
2619 694AFF737D9BE9713CEF8D837ADA6380B1093E94B6A529A8C6C2BE33E0867
2625 EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256
2626 576D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D60
2627 89DAD15DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F56
2628 6660E57EC68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC6
2632 Burdis & Naffah Expires November 28, 2003 [Page 47]
2634 Internet-Draft SRP Authentication Mechanism May 2003
2642 D77946826E811914B39401D56A0A7843A8E7575D738C672A090AB1187D690
2643 DC43872FC06A7B6A43F3B95BEAEC7DF04B9D242EBDC481111283216CE816E
2644 004B786C5FCE856780D41837D95AD787A50BBE90BD3A9C98AC0F5FC0DE744
2645 B1CDE1891690894BC1F65E00DE15B4B2AA6D87100C9ECC2527E45EB849DEB
2646 14BB2049B163EA04187FD27C1BD9C7958CD40CE7067A9C024F9B7C5A0B4F5
2652 9DEF3CAFB939277AB1F12A8617A47BBBDBA51DF499AC4C80BEEEA9614B19C
2653 C4D5F4F5F556E27CBDE51C6A94BE4607A291558903BA0D0F84380B655BB9A
2654 22E8DCDF028A7CEC67F0D08134B1C8B97989149B609E0BE3BAB63D4754838
2655 1DBC5B1FC764E3F4B53DD9DA1158BFD3E2B9C8CF56EDF019539349627DB2F
2656 D53D24B7C48665772E437D6C7F8CE442734AF7CCB7AE837C264AE3A9BEB87
2657 F8A2FE9B8B5292E5A021FFF5E91479E8CE7A28C2442C6F315180F93499A23
2663 AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56
2664 050A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA
2665 04FD50E8083969EDB767B0CF6095179A163AB3661A05FBD5FAAAE82918A99
2666 62F0B93B855F97993EC975EEAA80D740ADBF4FF747359D041D5C33EA71D28
2667 1E446B14773BCA97B43A23FB801676BD207A436C6481F1D2B9078717461A5
2668 B9D32E688F87748544523B524B0D57D5EA77A2775D2ECFA032CFBDBF52FB3
2669 786160279004E57AE6AF874E7303CE53299CCC041C7BC308D82A5698F3A8D
2670 0C38271AE35F8E9DBFBB694B5C803D89F7AE435DE236D525F54759B65E372
2671 FCD68EF20FA7111F9E4AFF73
2688 Burdis & Naffah Expires November 28, 2003 [Page 48]
2690 Internet-Draft SRP Authentication Mechanism May 2003
2693 Appendix B. Changes since the previous draft
2695 Removed specific references to SASL in the main document, instead
2696 isolating them to their own section.
2698 Added sections describing how the mechanism can be used with the
2699 GSS-API and EAP authentication frameworks.
2701 Adopted SRP-6 exchange for the base protocol.
2703 Mandated the use of SASLprep profile for text based information.
2705 Added an optional, optimised alternate authentication exchange where
2706 the parameters of a previously negotiated session are re-used, but
2707 with a newly derived shared context key.
2709 TODO: Regenerate SASL example.
2744 Burdis & Naffah Expires November 28, 2003 [Page 49]
2746 Internet-Draft SRP Authentication Mechanism May 2003
2749 Intellectual Property Statement
2751 The IETF takes no position regarding the validity or scope of any
2752 intellectual property or other rights that might be claimed to
2753 pertain to the implementation or use of the technology described in
2754 this document or the extent to which any license under such rights
2755 might or might not be available; neither does it represent that it
2756 has made any effort to identify any such rights. Information on the
2757 IETF's procedures with respect to rights in standards-track and
2758 standards-related documentation can be found in BCP-11. Copies of
2759 claims of rights made available for publication and any assurances of
2760 licenses to be made available, or the result of an attempt made to
2761 obtain a general license or permission for the use of such
2762 proprietary rights by implementors or users of this specification can
2763 be obtained from the IETF Secretariat.
2765 The IETF invites any interested party to bring to its attention any
2766 copyrights, patents or patent applications, or other proprietary
2767 rights which may cover technology that may be required to practice
2768 this standard. Please address the information to the IETF Executive
2772 Full Copyright Statement
2774 Copyright (C) The Internet Society (2003). All Rights Reserved.
2776 This document and translations of it may be copied and furnished to
2777 others, and derivative works that comment on or otherwise explain it
2778 or assist in its implementation may be prepared, copied, published
2779 and distributed, in whole or in part, without restriction of any
2780 kind, provided that the above copyright notice and this paragraph are
2781 included on all such copies and derivative works. However, this
2782 document itself may not be modified in any way, such as by removing
2783 the copyright notice or references to the Internet Society or other
2784 Internet organizations, except as needed for the purpose of
2785 developing Internet standards in which case the procedures for
2786 copyrights defined in the Internet Standards process must be
2787 followed, or as required to translate it into languages other than
2790 The limited permissions granted above are perpetual and will not be
2791 revoked by the Internet Society or its successors or assignees.
2793 This document and the information contained herein is provided on an
2794 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2795 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2796 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2800 Burdis & Naffah Expires November 28, 2003 [Page 50]
2802 Internet-Draft SRP Authentication Mechanism May 2003
2805 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2806 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2811 Funding for the RFC Editor function is currently provided by the
2856 Burdis & Naffah Expires November 28, 2003 [Page 51]
projects / cyrus-sasl.git / blob