Re: [SECMECH] Generally usable mechanism requirements

[Clint Chaplin <[e-mail]>]

Comments inline; mostly typos...

On 7/1/05, Salowey, Joe <[e-mail]> wrote:
> 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.

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


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

"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)



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


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


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


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


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

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




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

"MUST expect _that_ 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
> 


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

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