[SECMECH] Generally usable mechanism requirements

["Salowey, Joe" <[e-mail]>]

Here are some requirements for generally useful authentication
mechanisms

1. MUST support GSS-API, EAP and SASL frameworks.  This means that the
mechanism MUST be identifiable in any of these framework and have an EAP
ID, GSS-OID and SASL name.  Note that any GSSAPI mechanism can be
automatically mapped into the SASL mechanism namespace through the use
of the GSS-* SASL mechanism family.

2. MUST support mutual authentication. We may have some discussion as to
what this means, for example in systems it is not uncommon for an entity
to be authenticated to a realm or domain instead of the exact peer it is
communicating with.  A mechanism MAY support the capability to
authenticate only one side or provide anonymous authentication. 

3. MAY support identity privacy of one of the peers.  A mechanism should
document if it supports identity privacy, which parties identity is
protected and how it works. 

4. MUST support key derivation based on the authentication.  This is the
way EAP establishes and a cryptographic context.  GSS-API is working on
a standard PRF API to expose this functionality in GSSAPI mechanisms. 

5. MUST support a security layer.  This is a requirement of SASL and
GSS-API mechanisms.  GSS-API wrap and mic style protection should be
provided.  Although this is not part of the definition of an EAP
mechanism it should be difficult to add since EAP provides key material
which can be used as a basis for cryptographic functions.  A generic
protection transform can be provided for mechanisms that don't provide
their own.  

6. MUST support the ability to provide cryptographic binding to an
encapsulating channel.  This is identified as channel bindings in
GSS-API and cryptographic binding in EAP.  This provides an interface
into a mechanism that accepts external channel data  and the mechanism
implementations validate that both sides provided the same data.  

7. MUST support the ability to communicate attributes that are
authenticated as part of the authentication exchange and validated
external to the mechanism.  This is referred to in EAP as channel
bindings.   Channel Bindings (EAP) requires and interface into a
mechanism that accepts data to be sent in an authenticated manner to the
other party and a interface to obtain authenticated data from the other
party to be validated outside the mechanism.  It is possible that this
could be added to GSS-API through naming extensions. 

8. MUST provide messages to allow the authentications to be initiated
from either side.  This is necessary since EAP is always server
initiated and GSSAPI is always 'client' initiated.  This may just
involve an extra message in the exchange. 

9. MUST provide documentation to describe the mechanism properties
defined in [RFC3748]. GUAM mechanisms MUST support the following:
generation of keying material, mutual authentication, shared state
equivalence, replay protection, integrity protection, cryptographic
binding, session independence, and ciphersuite negotiation protection.
GUAM mechanisms MAY support the following: It is also desirable for GUAM
mechanisms to support the following: resistance to dictionary attacks,
fragmentation, and confidentiality.

10. MUST provide an option for a peer to get required credentials
in-band.  This is to support network access use cases where the only
access available to a network the authentication protocol executing
between two peers.  Kerberos GSS-API mechanism is an example of a
mechanism that does not support this since credential acquisition from
the KDC MUST happen out of band to the authentication mechanism.  The
expired draft of IAKERB did meet this requirement. 

11. MUST expect than an arbitrary number of proxies between the
authenticating parties may handle the messages.

12. SHOULD accept target names in host based service name format.  If
the mechanism makes use of a target name it should accept the name in
host based service name format. 

In general the issue of naming requires more discussion.  EAP has NAI
which is mainly for routing purposes and is in general external to a
mechanism (although a mechanism can choose to use an NAI name format).
SASL has an authorization ID which can be communicated by the mechanism.
The mapping from authentication ID to authorization ID needs to be
validated and authorized. I don't really think this mapping belongs in
the mechanism, rather it should happen external to the mechanism
(perhaps within another component), but this probably requires that name
are exported form mechanisms in some agreed upon format. 


_______________________________________________
SECMECH mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/secmech