[SECMECH] EAP methods and Generally Usable Authentication Mechanisms

"Salowey, Joe" <jsalowey@cisco.com> Wed, 13 July 2005 21:38 UTC

Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsovp-0002Eu-B2; Wed, 13 Jul 2005 17:38:17 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsovo-0002D6-Jn for secmech@megatron.ietf.org; Wed, 13 Jul 2005 17:38:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16096 for <secmech@ietf.org>; Wed, 13 Jul 2005 17:38:14 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DspOH-0003QN-PQ for secmech@ietf.org; Wed, 13 Jul 2005 18:07:43 -0400
Received: from sj-core-1.cisco.com ( by sj-iport-1.cisco.com with ESMTP; 13 Jul 2005 14:38:06 -0700
X-IronPort-AV: i="3.93,288,1115017200"; d="scan'208"; a="648395321:sNHT27039556"
Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com []) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6DLc2vM008451; Wed, 13 Jul 2005 14:38:02 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Jul 2005 14:42:31 -0700
Message-ID: <7210B31550AC934A8637D6619739CE6905823019@e2k-sea-xch2.sea-alpha.cisco.com>
Thread-Topic: EAP methods and Generally Usable Authentication Mechanisms
Thread-Index: AcWH8yXXu3Tk062TTE6KqZjW0g+r0g==
From: "Salowey, Joe" <jsalowey@cisco.com>
To: <secmech@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: quoted-printable
Cc: eap@frascone.com
Subject: [SECMECH] EAP methods and Generally Usable Authentication Mechanisms
X-BeenThere: secmech@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <secmech.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/secmech>
List-Post: <mailto:secmech@lists.ietf.org>
List-Help: <mailto:secmech-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=subscribe>
Sender: secmech-bounces@lists.ietf.org
Errors-To: secmech-bounces@lists.ietf.org

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

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