Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: RFC Editor <email@example.com> Cc: The IESG <firstname.lastname@example.org>, <email@example.com>, firstname.lastname@example.org Subject: Re: Informational RFC to be: draft-vanderveen-eap-sake-03.txt The IESG has no problem with the publication of 'Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)' <draft-vanderveen-eap-sake-03.txt> as an Informational RFC. The IESG would also like the IRSG or RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14154&rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vanderveen-eap-sake-03.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary
Technical Summary This document specifies an EAP method developed and implemented by Flarion. The method is based on the use of a shared secret. Working Group Summary This specification is an individual submission via the RFC Editor. Protocol Quality Jari Arkko has reviewed this specification for conformance with the RFC 3748 requirements for allocation of EAP Type codes, and for RFC 3932 requirements for conflict with IETF work. The IESG notes that response (2) from RFC 3932 applies: The IESG thinks that this work is related to IETF work done in WGs EMU and EAP, but this does not prevent publishing. Rationale: EMU WG is working on (among other things) a standardized shared-secret based method. A number of proprietary or undocumented EAP methods already exist, however, including methods based on shared secrets. Unfortunately, most of current EAP usage happens through such methods, for only a handful of methods matching current requirements in, e.g., wireless have been published as RFCs, and none of those have been published on the standards track. This situation is problematic from the point of view of interoperability, equal access to specifications, and quality of the methods. The IESG believes that the community is in this case best served by openly documenting existing practice, and by simultaneously progressing EMU work so that high-quality standards track solutions can be made available. IESG Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. IANA Note This document has been reviewed by Designated Expert in accordance with RFC 3748 rules for EAP Type code allocations. After modifications suggested in the review were adopted, the review result was positive: http://www.drizzle.com/~aboba/EAP/ (search for "SAKE") As a result, an EAP Type code can be allocated for this specification.