Using the Secure Remote Password (SRP) Protocol for TLS Authentication
RFC 5054
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2008-01-31 |
14 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2008-01-31 |
14 | Amy Vezza | [Note]: 'RFC 5054' added by Amy Vezza |
2007-11-20 |
14 | (System) | RFC published |
2007-09-05 |
14 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2007-09-05 |
14 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2007-09-05 |
14 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2007-09-01 |
14 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2007-08-31 |
14 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2007-08-31 |
14 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2007-08-30 |
14 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2007-08-30 |
14 | Amy Vezza | IESG state changed to Approved-announcement sent |
2007-08-30 |
14 | Amy Vezza | IESG has approved the document |
2007-08-30 |
14 | Amy Vezza | Closed "Approve" ballot |
2007-08-30 |
14 | (System) | IANA Action state changed to In Progress |
2007-08-24 |
14 | (System) | Removed from agenda for telechat - 2007-08-23 |
2007-08-23 |
14 | Amy Vezza | State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza |
2007-08-23 |
14 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2007-08-22 |
14 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2007-08-22 |
14 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2007-08-22 |
14 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2007-08-20 |
14 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2007-08-20 |
14 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2007-08-18 |
14 | Russ Housley | [Ballot comment] The discussion that followed the Gen-ART Review by Brian Carpenter indicates that the reader would be served by a minor change. All ... [Ballot comment] The discussion that followed the Gen-ART Review by Brian Carpenter indicates that the reader would be served by a minor change. All of the details from [SRP-6] that are needed to implement are included in draft-ietf-tls-srp-14. For this reason [SRP-6] is an informational reference. This fact should be stated in the document at the first place that a reference is made to [SRP-6]. |
2007-08-18 |
14 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2007-08-17 |
14 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2007-08-16 |
14 | Cullen Jennings | Placed on agenda for telechat - 2007-08-23 by Cullen Jennings |
2007-08-16 |
14 | Ron Bonica | Removed from agenda for telechat - 2007-08-23 by Ron Bonica |
2007-08-14 |
14 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2007-07-24 |
14 | Chris Newman | [Ballot comment] This is a weak abstain (I'm not asking other area directors to join my position). If the target were standards track, this would ... [Ballot comment] This is a weak abstain (I'm not asking other area directors to join my position). If the target were standards track, this would be a strong abstain. This a matter of application software architecture that applies to any user-based authentication mechanism embedded in TLS that involves or may involve unspecified server storage of per-user credential information. TLS stacks and the APIs to TLS stacks have started to ossify into operating systems, mobile devices and shipping application software. Such stacks are absolutely critical to application security, and are already so complex that they are the cause of a significant number of software defects and security updates. I am very concerned about adding unnecessary complexity to such a critical software component. There is already a great deal of flux upgrading the cipher suites, cipher modes and hash functions in these stacks. Meanwhile, all the software infrastructure in applications surrounding user identity, server credential repositories for users, and identity federation is highly complex and in a great deal of flux. If one looks at the amount of complexity in the GSSAPI or deployed general purpose SASL APIs and imagines the complexity of a software stack including all those APIs blended with a TLS API, I find the prospect daunting. Indeed the complexity is sufficiently great that I consider it bad architecture. Meanwhile, there's a viable alternative. If TLS and an authentication framework such as GSSAPI, EAP or SASL are loosely bound using a mechanism such as TLS channel bindings (TLS negotiates the security layer which is subsequently bound to a completely separate user authentication), then there is a very simple and clean boundary between the two software stacks, leading to a much more pragmatic real-world architecture. |
2007-07-24 |
14 | Chris Newman | [Ballot Position Update] New position, Abstain, has been recorded by Chris Newman |
2007-07-22 |
14 | Tim Polk | [Ballot Position Update] New position, Yes, has been recorded for Tim Polk |
2007-07-22 |
14 | Tim Polk | Ballot has been issued by Tim Polk |
2007-07-22 |
14 | Tim Polk | Created "Approve" ballot |
2007-07-22 |
14 | Tim Polk | Placed on agenda for telechat - 2007-08-09 by Tim Polk |
2007-07-22 |
14 | Tim Polk | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Tim Polk |
2007-07-13 |
14 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2007-07-12 |
14 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Paul Hoffman. |
2007-07-04 |
14 | Yoshiko Fong | IANA Last Call Comments: Action 1: Upon approval of this document, the IANA will make the following assignments in the "Transport Layer Security (TLS) Extensions" ... IANA Last Call Comments: Action 1: Upon approval of this document, the IANA will make the following assignments in the "Transport Layer Security (TLS) Extensions" registry located at http://www.iana.org/assignments/tls-extensiontype-values sub-registry "ExtensionType Values" Value Extension name Reference ----- --------------------------- --------- [TBD1] srp [RFC-tls-srp-14] Action 2: Upon approval of this document, the IANA will make the following assignments in the "Transport Layer Security (TLS) Parameters" registry located at http://www.iana.org/assignments/tls-parameters sub-registry "TLS Cipher Suite Registry" Value Description Reference ----------- -------------------------------------- --------- 0xC0,[TBD2] TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA [RFC-tls-srp-14] 0xC0,[TBD3] TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA [RFC-tls-srp-14] 0xC0,[TBD4] TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA [RFC-tls-srp-14] 0xC0,[TBD5] TLS_SRP_SHA_WITH_AES_128_CBC_SHA [RFC-tls-srp-14] 0xC0,[TBD6] TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA [RFC-tls-srp-14] 0xC0,[TBD7] TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA [RFC-tls-srp-14] 0xC0,[TBD8] TLS_SRP_SHA_WITH_AES_256_CBC_SHA [RFC-tls-srp-14] 0xC0,[TBD9] TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA [RFC-tls-srp-14] 0xC0,[TBD10] TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA [RFC-tls-srp-14] We understand the above to be the only IANA Actions for this document. |
2007-06-29 |
14 | Amy Vezza | Last call sent |
2007-06-29 |
14 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2007-06-29 |
14 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Paul Hoffman |
2007-06-29 |
14 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Paul Hoffman |
2007-06-28 |
14 | Tim Polk | Last Call was requested by Tim Polk |
2007-06-28 |
14 | (System) | Ballot writeup text was added |
2007-06-28 |
14 | (System) | Last call text was added |
2007-06-28 |
14 | (System) | Ballot approval text was added |
2007-06-28 |
14 | Tim Polk | State Changes to Last Call Requested from Publication Requested by Tim Polk |
2007-06-18 |
14 | Dinara Suleymanova | PROTO Write-Up: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, ... PROTO Write-Up: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Pasi Eronen. Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document went through WG last call, and although the number people who commented the technical details was rather small, I don't have concerns about the depth or breadth. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. This document took quite long to get finished: the -00 version was posted more than 6 (six) years ago... There are three IPR disclosures that may be relevant: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=25 https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=31 https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=63 Basically the only contentious issue was whether this should be on Standards Track or not. A straw poll was held to gauge consensus; there was no consensus for Standards Track, and thus this document is now progressing with intended status of Informational. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Given the amount of comments about technical details, I'd say the interest is rather limited. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Nobody has threatened an appeal or otherwise indicated extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split into normative and informative; all normative references look acceptable. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Everything looks OK here. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The only (semi-)formal language used is the TLS presentation language defined in RFC 4346 (the base TLS spec), for which no automated tools are available. I have checked them manually. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document adds Secure Remote Password (SRP) based authentication to TLS. Working Group Summary This document is a product of the Transport Layer Security (TLS) Working Group. Document Quality There are at least four implementations of earlier versions of this document. (end) |
2007-06-18 |
14 | Dinara Suleymanova | State Changes to Publication Requested from AD is watching::AD Followup by Dinara Suleymanova |
2007-06-14 |
14 | (System) | New version available: draft-ietf-tls-srp-14.txt |
2007-04-13 |
14 | Tim Polk | Responsible AD has been changed to Tim Polk from Russ Housley |
2006-12-18 |
14 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-12-18 |
13 | (System) | New version available: draft-ietf-tls-srp-13.txt |
2006-07-12 |
14 | Russ Housley | State Changes to AD is watching::Revised ID Needed from AD is watching::AD Followup by Russ Housley |
2006-06-27 |
14 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-06-27 |
12 | (System) | New version available: draft-ietf-tls-srp-12.txt |
2006-06-13 |
14 | Russ Housley | State Changes to AD is watching::Revised ID Needed from AD is watching by Russ Housley |
2006-06-13 |
14 | Russ Housley | State Change Notice email list have been change to ekr@networkresonance.com, Pasi.Eronen@nokia.com from <ekr@networkresonance.com> |
2006-05-19 |
14 | (System) | State Changes to AD is watching from Dead by system |
2006-05-18 |
11 | (System) | New version available: draft-ietf-tls-srp-11.txt |
2006-05-05 |
14 | (System) | State Changes to Dead from AD is watching by system |
2006-05-05 |
14 | (System) | Document has expired |
2005-10-11 |
10 | (System) | New version available: draft-ietf-tls-srp-10.txt |
2005-10-06 |
14 | Russ Housley | State Change Notice email list have been change to <ekr@networkresonance.com> from <treese@acm.org> |
2005-10-06 |
14 | Russ Housley | State Changes to AD is watching from Dead by Russ Housley |
2005-10-03 |
14 | (System) | State Changes to Dead from AD is watching by system |
2005-10-03 |
14 | (System) | Document has expired |
2005-03-18 |
09 | (System) | New version available: draft-ietf-tls-srp-09.txt |
2004-11-12 |
14 | Russ Housley | Shepherding AD has been changed to Russ Housley from Steve Bellovin |
2004-08-25 |
08 | (System) | New version available: draft-ietf-tls-srp-08.txt |
2004-06-08 |
07 | (System) | New version available: draft-ietf-tls-srp-07.txt |
2004-02-02 |
06 | (System) | New version available: draft-ietf-tls-srp-06.txt |
2003-06-17 |
05 | (System) | New version available: draft-ietf-tls-srp-05.txt |
2002-12-02 |
04 | (System) | New version available: draft-ietf-tls-srp-04.txt |
2002-11-04 |
14 | Steven Bellovin | Draft Added by Bellovin, Steve |
2002-09-04 |
03 | (System) | New version available: draft-ietf-tls-srp-03.txt |
2002-08-27 |
02 | (System) | New version available: draft-ietf-tls-srp-02.txt |
2001-06-29 |
01 | (System) | New version available: draft-ietf-tls-srp-01.txt |
2001-03-08 |
00 | (System) | New version available: draft-ietf-tls-srp-00.txt |