Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE)
draft-harkins-ipsecme-spsk-auth-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-04-12
|
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-04-12
|
08 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2012-04-12
|
08 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2012-04-11
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-04-02
|
08 | (System) | IANA Action state changed to In Progress |
2012-03-27
|
08 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-03-26
|
08 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-03-26
|
08 | Amy Vezza | IESG has approved the document |
2012-03-26
|
08 | Amy Vezza | Closed "Approve" ballot |
2012-03-26
|
08 | Amy Vezza | Ballot approval text was generated |
2012-03-26
|
08 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-03-26
|
08 | Amy Vezza | Ballot writeup was changed |
2012-03-26
|
08 | Stephen Farrell | [Ballot comment] Thanks for addressing my comments (and ignoring the dumb one:-) |
2012-03-26
|
08 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2012-03-26
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-03-26
|
08 | Dan Harkins | New version available: draft-harkins-ipsecme-spsk-auth-08.txt |
2012-03-19
|
07 | Stephen Farrell | [Ballot discuss] #1 OH CRAP, bad arithmetic:-) Sorry - I screwed up there, relevant power of 2 is 256 not 8. Embarrassed apologies. That was … [Ballot discuss] #1 OH CRAP, bad arithmetic:-) Sorry - I screwed up there, relevant power of 2 is 256 not 8. Embarrassed apologies. That was pretty dumb;-) #2 hunting and pecking: is this a potential timing attack vector for passphrases? If the answer is known then adding that to the security considerations seems warranted. If not, then just saying that that's for further study would be ok, but I think at least that is needed. |
2012-03-19
|
07 | Stephen Farrell | [Ballot comment] - s1, saying 5996 is "insecure" is maybe overstated, I'd suggest "insecure with weak pre-shared keys, such as human-memorable passwords" - maybe say … [Ballot comment] - s1, saying 5996 is "insecure" is maybe overstated, I'd suggest "insecure with weak pre-shared keys, such as human-memorable passwords" - maybe say "MUST use the same group" in section 4 rather than "uses the same group" just to call that out. - s4, you don't define "scalar" - I guess you mean an integer but better to say. - p5, typo: s/consists points/consists of points" - The scalar-op description is confusing, or wrong (would s/multiplication/addition/ be right? I forget too much math;-) Wouldn't it be better to just say that 2*X = X + X after the element-op has been defined? - 4.1, last para: better to name the IANA registry there maybe - 4.2, s/modulus a prime/modulo a prime/ - section 6 could badly do with some examples if that's possible. I'd expect interop problems in any case, but more without that. Those might be shared with the other scheme drafts. - Is the last paragraph of section 6 really achieveable? A common pattern here is that one side needs the cleartext password, e.g. if using an existing DB that's also used for some other protocol. Might be bad practice, but would a SHOULD store the pre-processed value be more likely to get implemented? - section 7, point 3 - is this really correct? If the PSK is based on a passphrase then the pre-processed values will not really be uniformly distributed amongst all 256 bit strings. The set of pre-processed strings might be indistinguishable from any subset of the set of 256 bit strings but that's not quite the same. - Its probably wrong to say that Dragonfly is "patent-free and royalty-free." We can't know the former and the latter seems to require that some IPR exists. - 8.2.1 - "hunting and pecking continues" means increment the counter and get a new ske-value right? Be better to say that. - 8.2.1 - be good to explain how y=sqrt(...) produces FAIL since that's not very obvious |
2012-03-19
|
07 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2012-03-15
|
07 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2012-03-15
|
07 | Stephen Farrell | [Ballot discuss] #1 8.1 - why an 8-bit counter? that's usually wrong unless there's a reason to want it so short. In this case if … [Ballot discuss] #1 8.1 - why an 8-bit counter? that's usually wrong unless there's a reason to want it so short. In this case if len(r)~=len(p) then 3 in every 1000 IKE exchanges might not work with this scheme. While that might be ok for an experimental RFC, having to change it if this became a standard would be bad. I'd suggest a 16 bit counter or else providing a way to iterate until you do find a good ske-value. (If I'm right about the probability there.) The pseudo-code in 8.2.1 & 8.2.2 also need something to terminate their loops, e.g. "while (found == 0 && counter < limit )" #2 hunting and pecking: is this a potential timing attack vector for passphrases? If the answer is known then adding that to the security considerations seems warranted. If not, then just saying that that's for further study would be ok, but I think at least that is needed. |
2012-03-15
|
07 | Stephen Farrell | [Ballot comment] - s1, saying 5996 is "insecure" is maybe overstated, I'd suggest "insecure with weak pre-shared keys, such as human-memorable passwords" - maybe say … [Ballot comment] - s1, saying 5996 is "insecure" is maybe overstated, I'd suggest "insecure with weak pre-shared keys, such as human-memorable passwords" - maybe say "MUST use the same group" in section 4 rather than "uses the same group" just to call that out. - s4, you don't define "scalar" - I guess you mean an integer but better to say. - p5, typo: s/consists points/consists of points" - The scalar-op description is confusing, or wrong (would s/multiplication/addition/ be right? I forget too much math;-) Wouldn't it be better to just say that 2*X = X + X after the element-op has been defined? - 4.1, last para: better to name the IANA registry there maybe - 4.2, s/modulus a prime/modulo a prime/ - section 6 could badly do with some examples if that's possible. I'd expect interop problems in any case, but more without that. Those might be shared with the other scheme drafts. - Is the last paragraph of section 6 really achieveable? A common pattern here is that one side needs the cleartext password, e.g. if using an existing DB that's also used for some other protocol. Might be bad practice, but would a SHOULD store the pre-processed value be more likely to get implemented? - section 7, point 3 - is this really correct? If the PSK is based on a passphrase then the pre-processed values will not really be uniformly distributed amongst all 256 bit strings. The set of pre-processed strings might be indistinguishable from any subset of the set of 256 bit strings but that's not quite the same. - Its probably wrong to say that Dragonfly is "patent-free and royalty-free." We can't know the former and the latter seems to require that some IPR exists. - 8.2.1 - "hunting and pecking continues" means increment the counter and get a new ske-value right? Be better to say that. - 8.2.1 - be good to explain how y=sqrt(...) produces FAIL since that's not very obvious |
2012-03-15
|
07 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2012-03-15
|
07 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-03-14
|
07 | Adrian Farrel | [Ballot comment] I have no objection to the publiction of this document. I love the concept of "distilling entropy". This is, I think, really just … [Ballot comment] I have no objection to the publiction of this document. I love the concept of "distilling entropy". This is, I think, really just hiding the absence of entropy, but I have no objection to the term being used in this document. |
2012-03-14
|
07 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-03-14
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-03-13
|
07 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-03-13
|
07 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-03-13
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-03-09
|
07 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-03-09
|
07 | Dan Harkins | New version available: draft-harkins-ipsecme-spsk-auth-07.txt |
2012-03-08
|
06 | Peter Saint-Andre | [Ballot comment] Section 6 states: The first step of pre-processing is to remove ambiguities that may arise due to internationalization. Each character-based password … [Ballot comment] Section 6 states: The first step of pre-processing is to remove ambiguities that may arise due to internationalization. Each character-based password or passphrase MUST be pre-processed to remove that ambiguity by processing the character-based password or passphrase according to the rules of the [RFC4013] profile of [RFC3454]. Please be aware there there is work underway to obsolete RFC 3454 and RFC 4013, primarily because stringprep is limited to Unicode 3.2; see draft-melnikov-precis-saslprepbis. This is just a heads-up, and I'm not necessarily suggesting that you change the text to something like "use RFC 4013 or equivalent". However, when your experiment is done and you put this on the standards track, you'll probably be asked to update the internationalization to use saslprepbis (if the PRECIS WG finishes before your experiment does!). |
2012-03-08
|
06 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded for Peter Saint-Andre |
2012-03-05
|
06 | Sean Turner | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-03-05
|
06 | Sean Turner | Ballot has been issued |
2012-03-05
|
06 | Sean Turner | [Ballot Position Update] New position, Yes, has been recorded for Sean Turner |
2012-03-05
|
06 | Sean Turner | Ballot writeup was changed |
2012-03-05
|
06 | Sean Turner | Created "Approve" ballot |
2012-02-14
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2012-02-02
|
06 | Roni Even | Request for Last Call review by GENART Completed. Reviewer: Roni Even. |
2012-01-23
|
06 | Amanda Baber | We understand that, upon approval of this document, there will be a single action for IANA. In the IKEv2 Secure Password Methods subregistry of the … We understand that, upon approval of this document, there will be a single action for IANA. In the IKEv2 Secure Password Methods subregistry of the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at: http://www.iana.org/assignments/ikev2-parameters IANA will assign a new authentication method as follows: Value Description Reference ----- ------------------------- --------------------- [TBD] Secure PSK Authentication [RFC-to-be] |
2012-01-19
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2012-01-19
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2012-01-19
|
06 | Sean Turner | Placed on agenda for telechat - 2012-03-15 |
2012-01-19
|
06 | Cindy Morgan | PROTO writeup for draft-harkins-ipsecme-spsk-auth-06.txt (1.a) I (Paul Hoffman) am the shepherd, and I have reviewed the -06 version of the draft. I believe that it … PROTO writeup for draft-harkins-ipsecme-spsk-auth-06.txt (1.a) I (Paul Hoffman) am the shepherd, and I have reviewed the -06 version of the draft. I believe that it is ready for forwarding to the IESG. Note that this is an individual submission, not the product of the IPsecME WG. (1.b) The document was reviewed in the IPsecME WG, although it is not a WG draft. There were multiple requests for reviews, and there were a fair number of comments on various versions of the draft (1.c) I do not believe that more reviews will necessarily help the draft. (1.d) I do not have any special concerns about this draft. There are no IPR statements for this draft. (1.e) There was informal consensus in the IPsecME WG that multiple proposals for a PAKE, including this one, should be standardized. (1.f) I do not believe anyone has threatened an appeal. There are some individuals who expressed extreme discontent with the idea that there would be more than one PAKE published, but the WG could not agree on just one PAKE. (1.g) There were no nits that would prevent the document from being published as an RFC. (1.h) The document's split between normative and informative references is appropriate, and there are no normative downward references. (1.i) The IANA considerations is appropriate. (1.j) There is no formal languages used in the document. Technical Summary This document describes a password-based key exchange for IKEv2 that can be used in the framework described in RFC 6467. The document describes its exchange as "a secure pre-shared key authentication method for IKE. It is resistant to dictionary attack and retains security even when used with weak pre-shared keys". Working Group Summary This document is an individual submission. Document Quality The document has been well-reviewed, with significant changes made since the initial submission. It includes references to academic papers that cover the algorithm described in the document. |
2012-01-17
|
06 | Cindy Morgan | Last call sent |
2012-01-17
|
06 | Cindy Morgan | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (Secure PSK Authentication for IKE) to Experimental RFC The IESG has received a request from an individual submitter to consider the following document: - 'Secure PSK Authentication for IKE' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes a secure pre-shared key authentication method for IKE. It is resistant to dictionary attack and retains security even when used with weak pre-shared keys. The file can be obtained via http://datatracker.ietf.org/doc/draft-harkins-ipsecme-spsk-auth/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-harkins-ipsecme-spsk-auth/ No IPR declarations have been submitted directly on this I-D. |
2012-01-17
|
06 | Cindy Morgan | [Note]: changed to 'Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd.' |
2012-01-17
|
06 | Cindy Morgan | State Change Notice email list has been changed to dharkins@arubanetworks.com, draft-harkins-ipsecme-spsk-auth@tools.ietf.org, paul.hoffman@vpnc.org from dharkins@arubanetworks.com, draft-harkins-ipsecme-spsk-auth@tools.ietf.org |
2012-01-17
|
06 | Sean Turner | Last Call was requested |
2012-01-17
|
06 | Sean Turner | State changed to Last Call Requested from Waiting for AD Go-Ahead. |
2012-01-17
|
06 | Sean Turner | Last Call text changed |
2012-01-13
|
06 | (System) | New version available: draft-harkins-ipsecme-spsk-auth-06.txt |
2011-07-28
|
05 | (System) | New version available: draft-harkins-ipsecme-spsk-auth-05.txt |
2011-05-06
|
06 | Sean Turner | [Note]: 'Dan Harkins (dharkins@arubanetworks.com) is the document shepherd.' added |
2011-05-06
|
06 | Sean Turner | Status Date has been changed to 2011-05-06 from 2011-03-26 |
2011-04-26
|
04 | (System) | New version available: draft-harkins-ipsecme-spsk-auth-04.txt |
2011-04-23
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-04-21
|
06 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Richard Barnes. |
2011-04-12
|
06 | Amanda Baber | IANA understands that, upon approval of this document, there are five IANA Actions which need to be completed. First, a new subregistry of the Internet … IANA understands that, upon approval of this document, there are five IANA Actions which need to be completed. First, a new subregistry of the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at: http://www.iana.org/assignments/ikev2-parameters will be created. This new registry - "IKEv2 Password Preprocessing" - will consist of values from 0x00 to 0xFF inclusive. New values and changes to the registry will require "Specification Required" as per RFC5226. The fields in the registry will be the Password Preprocessing value, a description and a reference. The reference for this subregistry will be [RFC-to-be]. The initial values for the registry will be: Value Description Reference ----- -------------------- ----------- 0x00 None [RFC-to-be] 0x01 RFC2759 [RFC-to-be] 0x02 SASLprep [RFC-to-be] Second, in the IKEv2 Notify Message Types - Error Codes subregistry of the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at: http://www.iana.org/assignments/ikev2-parameters IANA will register a single new value as follows: Value: TBD NOTIFY MESSAGES - ERROR TYPES" UNSUPPORTED_PREP Reference: [RFC-to-be] Third, in the IKEv2 Payload Types subregistry of the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at: http://www.iana.org/assignments/ikev2-parameters IANA will register a single new value as follows: Value Next Payload Type Notation Reference ------- ------------------------------- --------- ---------- TBD Commit COM [RFC-to-be] Fourth, in the IPSEC Authentication Method subregistry of the Internet Key Exchange (IKE) Attributes registry located at: http://www.iana.org/assignments/ipsec-registry IANA will assign a new authentication method as follows: Value Method Reference ----- ------------------------- --------------------- TBD Secure PSK Authentication [RFC-to-be] Fifth, in the IKEv2 Authentication Method registry in the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at: http://www.iana.org/assignments/ikev2-parameters IANA will register a single new value as follows: Value Authentication Method Reference -------- ------------------------------------------ --------- TBD Secure PSK Authentication [RFC-to-be] IANA understands that these are the only actions that need to be completed upon approval of this document. |
2011-04-11
|
06 | Sean Turner | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document … (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? The Document Shepherd is Dan Harkins. I've reviewed the document and I believe it is ready to be forwarded to the IESG for publication. (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document was reviewed by members of the IPsec(me) community and review was requested on the CFRG mailing list. I don't have any reservations about the amount of review this document has received. (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, I don't think so. It's a new authentication method for IKE and has been reviewed by individuals with extensive experience and expertise in IKE. It's been reviewed by security experts with a more mathematical focus on the security of the underlying key exchange. (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 interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I'm not sold on the need for negotiation (or, really, specification) of an encoding of the password. Since there really isn't a "user" per-se (the use case involving users is handled by the EAP extensions already made to IKEv2) there just needs to be a way to agree. As soon as LC was announced I received a comment on how this was done in the draft. I will discuss the issue with the commenter and come to a decision. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? This draft is an individual submission. That said.... This draft, and the idea behind it, was presented when the IPsecme WG was considering expanding its charter. Password authentication was added to the charter because of my advocation for it and my presentation of this draft as a way to solve it. There was, at one time, consensus to proceed with this draft. I think there is interest in the community for this type of a solution-- IKE, both v1 and v2 are broken when used with a PSK and the RFCs mention this-- but there is probably some confusion due to the conflicting drafts attempting to propose a solution. (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.) Not to my knowledge. Discontent with this draft has been of the "mine's better" variety. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist 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, I'm unaware of any issues. (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]. The References section has sub-sections for normative references and informative references. The state of all normative references are clear. (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 suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. 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? There is an IANA Considerations section and it is consistent with the document. There is one outstanding comment received (same one from 1.d, above) that deals with how the initial registry is layed out. That comment will be resolved. (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? There is no formal language used that would require validation. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This draft specifies the addition of a new authentication method to IKE that uses a zero-knowledge proof for authentication using only a password. It is resistant to dictionary attack and retains security even when used with "weak" pre-shared keys. Working Group Summary This document is an individual submission. It was used to advocate for expansion of the IPsecme WG's charter, which was expanded to include this topic. There was discussion of this draft on the mailing list and controversy on it seemed to be on unfounded IPR issues. At one point in time this draft had very rough consensus (enough to expand the charter to tackle the problem of password authentication) but that consensus has since been diluted. Document Quality This document has been reviewed by members of the IPsecme WG and by people on the CFRG mailing list. Primarily this review has been on technical, not editorial, content. |
2011-04-06
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Richard Barnes |
2011-04-06
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Richard Barnes |
2011-03-26
|
06 | Sean Turner | Intended Status has been changed to Experimental from Informational |
2011-03-26
|
06 | Cindy Morgan | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (Secure PSK Authentication for IKE) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Secure PSK Authentication for IKE' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-harkins-ipsecme-spsk-auth/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-harkins-ipsecme-spsk-auth/ |
2011-03-26
|
06 | Sean Turner | Last Call was requested |
2011-03-26
|
06 | (System) | Ballot writeup text was added |
2011-03-26
|
06 | (System) | Last call text was added |
2011-03-26
|
06 | (System) | Ballot approval text was added |
2011-03-26
|
06 | Sean Turner | State changed to Last Call Requested from Publication Requested. |
2011-03-26
|
06 | Sean Turner | Last Call text changed |
2011-03-26
|
06 | Sean Turner | Draft added in state Publication Requested |
2010-12-22
|
03 | (System) | New version available: draft-harkins-ipsecme-spsk-auth-03.txt |
2010-07-01
|
02 | (System) | New version available: draft-harkins-ipsecme-spsk-auth-02.txt |
2010-03-07
|
01 | (System) | New version available: draft-harkins-ipsecme-spsk-auth-01.txt |
2009-11-11
|
00 | (System) | New version available: draft-harkins-ipsecme-spsk-auth-00.txt |