eap Mailing List: RE: Re: EAP Issue #221

[Joseph Salowey (jsalowey]

Part of the point of specifying a standard key derivation is to eliminate
the impact of one application on another.  I don't think that IETF consensus
should be required.  I do think that a specification is highly desirable.  

Joe

eap-admin [at] frascone.com wrote:
> Jari Arkko wrote:
> 
> "But in any case, even that might lead to problems.
> There might be a number of proprietary ways to key
> a standard application FOO.
> 
> I think Specification Required would be appropriate.
> Maybe even something stronger."
> 
> How about IETF consensus?  Here is the proposed text of the
> IANA section: 6.  IANA Considerations
> 
>    This section provides guidance to the Internet Assigned Numbers
>    Authority (IANA) regarding registration of values related
> to EAP key
>    management, in accordance with BCP 26, [RFC2434].
> 
>    The following terms are used here with the meanings defined in BCP
>    26: "name space", "assigned value", "registration".
> 
>    The following policies are used here with the meanings
> defined in BCP
>    26: "Private Use", "First Come First Served", "Expert Review",
>    "Specification Required", "IETF Consensus", "Standards Action".
> 
>    For registration requests where a Designated Expert should be
>    consulted, the responsible IESG area director should appoint the
>    Designated Expert.  The intention is that any allocation will be
>    accompanied by a published RFC.  But in order to allow for the
>    allocation of values prior to the RFC being approved for
>    publication, the Designated Expert can approve allocations once it
>    seems clear that an RFC will be published.  The Designated expert
>    will post a request to the EAP WG mailing list (or a successor
> designated by the
>    Area Director) for comment and review, including an Internet-Draft.
>    Before a period of 30 days has passed, the Designated Expert will
>    either approve or deny the registration request and
> publish a notice
>    of the decision to the EAP WG mailing list or its
> successor, as well
>    as informing IANA.  A denial notice must be justified by an
>    explanation and, in the cases where it is possible, concrete
>    suggestions on how the request can be modified so as to become   
> acceptable. 
> 
>    This document introduces a new name space for "key labels".  Key
>    labels are ASCII strings and are assigned via IETF
> Consensus.  It is
>    expected that key label specifications will include the following 
> information: 
> 
>         o A description of the application
>         o The key label to be used
>         o How TSKs will be derived from the AMSK and how they
> will be used
>         o If application specific data is used, what it is
> and how it is
>            maintained
>         o Where the AMSKs or TSKs will be used and how they are
>           communicated if necessary.
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap