Subject: [eap] SECMECH list announcement

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 23 Jun 2005 11:08:22 -0700

This is a brief note to announce a the creation of a mailing list for
discussing security mechanisms.  The current scope is security
mechanisms for the GSS-API, EAP and SASL frameworks.  There will most
likely be a BOF on this topic at IETF 63.  Please join the mailing list
if you have interest in this topic.   

General Discussion: [email-masked]
To Subscribe:       https://www1.ietf.org/mailman/listinfo/secmech
Archive:
http://www.ietf.org/mail-archive/web/secmech/index.html

Description
-------------------

There exists a disconnect between the IETF's security frameworks.
Although these frameworks have very similar goals,  the set of
mechanisms available depends upon the choice of framework.  There are a
number of issues that make a compelling case for converging the way we
develop mechanisms for these frameworks.  

- There is a desire to standardized EAP mechanisms and there currently
is no working group with this on its charter. It would be desirable to
work on this in conjunction with other efforts in the security area
including work on GSS-API enhancements in KITTEN working group and SASL
enhancements in the SASL working group.

- The actual mechanisms in each of these frameworks have very similar
goals of authentication and establishing a cryptographic context. In
many cases frameworks are developing new functionality that bring them
closer together.  An example of this is the addition of a PRF API to
access key material from GSS-API. 

- There is pressure to adopt a particular framework because of the set
of mechanisms available not because of the capabilities and upper-layer
interface of the framework.  This recently was an issue with ISMS, but
there has also been a desire to use EAP to authenticate other
applications.  We should be in a situation where the choice on mechanism
was dictated by the deployment requirements and the choice of framework
dictated by protocol design and implementation simplicity.  

- There is a duplication of effort in the development of security
mechanism that support similar credential types and infrastructures.
This is problematic because the development of security mechanisms is
both difficult and time consuming.  It would be good to leverage the
work and expertise required for developing a mechanism across all the
frameworks.

- Often the cost of deploying a security mechanism is in the
infrastructure and not the implementation of the mechanism itself. There
limited set of mechanisms available to particular frameworks makes the
coordination and administration of security between applications that
use different frameworks more difficult. 

The first tasks of a SECMECH working group would be to document a set of
evaluation criteria/guidelines explaining what standards-track security
mechanisms need to do and how we will evaluate them and to document how
we're going to go about specifying a security mechanism for use in the
frameworks that are in scope.  The working group would also be chartered
to define a set of standards track mechanisms.  The mechanism work would
complete after the first two tasks have completed. 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap