Concluded WG Security Mechanisms (secmech)

Note: The data for concluded WGs is occasionally incorrect.

WG Name Security Mechanisms
Acronym secmech
Area Security Area (sec)
State Concluded
Charter charter-ietf-secmech-01 Approved
Document dependencies
Personnel Chair Joseph A. Salowey

Final Charter for Working Group

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.

  • 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 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.

  • 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.