Subject: [SECMECH] Generally usable mechanism requirements

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 1 Jul 2005 16:41:59 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/secmech

---

From: Clint Chaplin <[email-masked]>
Date: Sat, 2 Jul 2005 17:38:16 -0700

Comments inline; mostly typos...

> a standard PRF API to expose this functionality in GSSAPI mechanisms.

"EAP establishes and a cryptographic context."  Either something is
missing, or something is extra.  I couldn't figure out which.

> protection transform can be provided for mechanisms that don't provide

"it should be difficult to add since EAP"  Surely this is "it
shouldn't be difficult to add since EAP" (and don't call me Shirley)

> could be added to GSS-API through naming extensions.

"Channel Bindings (EAP) requires and interface"  and -> an.

> fragmentation, and confidentiality.

"GUAM mechanisms MAY support the following: It is also desirable for
GUAM mechanisms to support the following: resistance to dictionary
attacks,  fragmentation, and confidentiality."  I think perhaps two
thought collided in the above sentence, and infortunately both won;
either that or it's a cut and paste error.

> expired draft of IAKERB did meet this requirement.

"This is to support network access use cases where the only access
available to a network _is_ the authentication protocol executing
between two peers"

> authenticating parties may handle the messages.

"MUST expect _that_ an arbitrary number of proxies between the
authenticating parties may handle the messages."

-- 
Clint (JOATMON) Chaplin
Wireless Security Technologist
Wireless Standards Manager