[SECMECH] EAP methods and Generally Usable Authentication Mechanisms

I think it is possible to define reasonable EAP methods as
authentication mechanisms that can be used in SASL and GSS-API without
much additional work.   I think EAP mechanisms we standardize should be
generally useable.  From discussions on the secmech list and from the
GUAM draft (draft-salowey-guam-00) I think the following list would need
to be addressed to define an EAP mechanism that is generally useful:

1. Define a GSS-API OID and a SASL name, this could be done
algorithmically.  Some additional documentation would be required to
meet the SASL registration requirements and the mapping to GSS-API
calls. 

2. The protocol may require slight modification to allow the option for
the client to initiate the conversation.  This shouldn't be too
difficult since many protocols such as TLS is already client initiated. 

3. Support for a security layer - A security layer would have to be
defined to authenticate and encrypt data.  The best approach would be to
define a standard (or set of standard) encryption mechanism(s) that can
consume the key material exported from EAP.  It is probably necessary to
have a way to negotiate a protection mechanism, but it may be possible
to make this part of the GSS OID or SASL name so it can be negotiated
through other means. 

4. Cryptographic Binding/Channel Bindings(GSS)/Channel Bindings(EAP) -
This type of functionality has already been identified as something that
is useful for EAP methods. Many existing mechanism such as EAP-TLS do
not provide a way to provide external data to be validated or exported
in the authentication exchange.  Most protocols could be extended to
provide this functionality. 

5. Naming may be an issue, but it probably doesn't affect the mechanism
protocol itself, but rather how the mechanism represents names
externally.   This will probably require some specification in the
mechanism as to how to deal with names. The issue of naming is somewhat
tied to credentials and perhaps can be taken care in separate
specifications that deal with specific credential types such as X.509
certificates and apply across mechanisms that utilize the same
credential type. 

_______________________________________________
SECMECH mailing list
SECMECH@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/secmech