Skip to main content

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