Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)
RFC 4763

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: The IESG <iesg@ietf.org>, <iana@iana.org>, ietf-announce@ietf.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.