RE: [SECMECH] Generally usable mechanism requirements

"Salowey, Joe" <jsalowey@cisco.com> Tue, 05 July 2005 18:25 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dps6i-00088z-BT; Tue, 05 Jul 2005 14:25:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dps6f-00083p-WD for secmech@megatron.ietf.org; Tue, 05 Jul 2005 14:25:18 -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 OAA03349 for <secmech@ietf.org>; Tue, 5 Jul 2005 14:25:16 -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 1DpsS3-0000fT-GF for secmech@ietf.org; Tue, 05 Jul 2005 14:47:24 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Jul 2005 11:19:30 -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 j65IJRvM026534; Tue, 5 Jul 2005 11:19:28 -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
Subject: RE: [SECMECH] Generally usable mechanism requirements
Date: Tue, 05 Jul 2005 11:23:50 -0700
Message-ID: <7210B31550AC934A8637D6619739CE6905781EE9@e2k-sea-xch2.sea-alpha.cisco.com>
Thread-Topic: [SECMECH] Generally usable mechanism requirements
Thread-Index: AcV/aDYfvDqfWfG/TvOxpZNM4sNJMgCJOLwg
From: "Salowey, Joe" <jsalowey@cisco.com>
To: Clint Chaplin <clint.chaplin@gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: quoted-printable
Cc: secmech@ietf.org
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

Thanks Clint, 

<snip>
> > 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.
> 
[Joe] I originally intended it to read "EAP establishes and exports a
cryptographic context."

> 
> > 
> > 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)
> 

[Joe] Yes.

> > 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.
> 

[Joe] It should read "GUAM mechanisms MAY support the following:
resistance to dictionary attacks, fragmentation, and confidentiality.

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