[SECMECH] Generally usable mechanism requirements
"Salowey, Joe" <jsalowey@cisco.com> Fri, 01 July 2005 23:37 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DoV4x-0006Qv-Vt; Fri, 01 Jul 2005 19:37:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DoV4x-0006Qq-7R
for secmech@megatron.ietf.org; Fri, 01 Jul 2005 19:37:51 -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 TAA07213
for <secmech@ietf.org>; Fri, 1 Jul 2005 19:37:47 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1DoVV0-00044a-TG
for secmech@ietf.org; Fri, 01 Jul 2005 20:04:47 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
by sj-iport-2.cisco.com with ESMTP; 01 Jul 2005 16:37:42 -0700
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 j61NbdvM000613
for <secmech@ietf.org>; Fri, 1 Jul 2005 16:37:39 -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: Fri, 1 Jul 2005 16:41:59 -0700
Message-ID: <7210B31550AC934A8637D6619739CE6905781D71@e2k-sea-xch2.sea-alpha.cisco.com>
Thread-Topic: Generally usable mechanism requirements
Thread-Index: AcV+ld66rocWJwP6Tcmhot82Ay6fAg==
From: "Salowey, Joe" <jsalowey@cisco.com>
To: <secmech@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Content-Transfer-Encoding: quoted-printable
Cc:
Subject: [SECMECH] Generally usable mechanism requirements
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
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 SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech
- [SECMECH] Generally usable mechanism requirements Salowey, Joe
- Re: [SECMECH] Generally usable mechanism requirem… Clint Chaplin
- RE: [SECMECH] Generally usable mechanism requirem… Salowey, Joe