[SECMECH] EAP methods and Generally Usable Authentication Mechanisms
"Salowey, Joe" <jsalowey@cisco.com> Wed, 13 July 2005 21:38 UTC
Received: from localhost.localdomain ([127.0.0.1] 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 ([132.151.1.176] 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 [132.151.6.1])
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 ([171.71.176.70]
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 (171.71.177.237)
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
[10.93.132.68])
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 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
- [SECMECH] EAP methods and Generally Usable Authen… Salowey, Joe