Re: [SECMECH] Generally usable mechanism requirements

Clint Chaplin <clint.chaplin@gmail.com> Sun, 03 July 2005 00:38 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DosV9-000396-S5; Sat, 02 Jul 2005 20:38:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DosV8-00037g-Ck for secmech@megatron.ietf.org; Sat, 02 Jul 2005 20:38:26 -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 UAA15277 for <secmech@ietf.org>; Sat, 2 Jul 2005 20:38:24 -0400 (EDT)
Received: from wproxy.gmail.com ([64.233.184.203]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DosvP-0002E0-67 for secmech@ietf.org; Sat, 02 Jul 2005 21:05:35 -0400
Received: by wproxy.gmail.com with SMTP id 36so531652wra for <secmech@ietf.org>; Sat, 02 Jul 2005 17:38:16 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fmSz+Qvx5+RGETiDAuoJS1r2UDVefkIcjpShqEWjS7n4YfOiFsC93VWHXkYXEJx3UveWmQiNbjwO+rC6Vb8HW9S4j5NS9QtJuLymA4lXKSqehryrAoe4eezlQJOrHwI1AjeF41/GCaXfXP1A4kH42V5SpByNH9g4jRXDOhFITwY=
Received: by 10.54.27.45 with SMTP id a45mr2627969wra; Sat, 02 Jul 2005 17:38:16 -0700 (PDT)
Received: by 10.54.57.49 with HTTP; Sat, 2 Jul 2005 17:38:16 -0700 (PDT)
Message-ID: <d4083f66050702173878e1f64@mail.gmail.com>
Date: Sat, 2 Jul 2005 17:38:16 -0700
From: Clint Chaplin <clint.chaplin@gmail.com>
To: "Salowey, Joe" <jsalowey@cisco.com>
Subject: Re: [SECMECH] Generally usable mechanism requirements
In-Reply-To: <7210B31550AC934A8637D6619739CE6905781D71@e2k-sea-xch2.sea-alpha.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <7210B31550AC934A8637D6619739CE6905781D71@e2k-sea-xch2.sea-alpha.cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93e7fb8fef2e780414389440f367c879
Content-Transfer-Encoding: quoted-printable
Cc: secmech@ietf.org
X-BeenThere: secmech@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Clint Chaplin <clint.chaplin@gmail.com>
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

Comments inline; mostly typos...

On 7/1/05, Salowey, Joe <jsalowey@cisco.com> 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
> SECMECH@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/secmech
> 


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

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