RE: [HOKEY] EMSK Issue

"Glen Zorn" <gzorn@arubanetworks.com> Wed, 19 March 2008 00:03 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32E543A6D99; Tue, 18 Mar 2008 17:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.147
X-Spam-Level:
X-Spam-Status: No, score=-100.147 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiMRNc3N1v1p; Tue, 18 Mar 2008 17:03:30 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21B728C2CE; Tue, 18 Mar 2008 17:03:28 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFFF28C563; Tue, 18 Mar 2008 08:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 517FqtVM8pwX; Tue, 18 Mar 2008 08:33:35 -0700 (PDT)
Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by core3.amsl.com (Postfix) with SMTP id 6128428C5DD; Tue, 18 Mar 2008 08:33:34 -0700 (PDT)
Received: from aruba-mx1.arubanetworks.com ([10.1.1.17]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 08:31:17 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [HOKEY] EMSK Issue
Date: Tue, 18 Mar 2008 08:31:15 -0700
Message-ID: <A3DA4C2546E1614D8ACC896746CDCF29E7BF6E@aruba-mx1.arubanetworks.com>
In-Reply-To: <47DF04FC.4060706@cs.umd.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [HOKEY] EMSK Issue
Thread-Index: AciIinAt9YhOZWe9Rru5XLPDygs6LwAf8axA
References: <47DF04FC.4060706@cs.umd.edu>
From: Glen Zorn <gzorn@arubanetworks.com>
To: Charles Clancy <clancy@cs.umd.edu>
X-OriginalArrivalTime: 18 Mar 2008 15:31:17.0974 (UTC) FILETIME=[1C23AF60:01C8890D]
X-Mailman-Approved-At: Tue, 18 Mar 2008 17:03:24 -0700
Cc: ietf@ietf.org, hokey@ietf.org, Bernard Aboba <bernarda@windows.microsoft.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Charles Clancy <> scribbled on :

> HOKEY,
> 
> From Bernard's "walled garden" LC comments, I've created the
> following issue below in the issue tracker.

Some of us don't subscribe to the IETF list (due to the extremely poor
S/N ratio).  Someone did forward me Bernard's original message & to me
it appears to fall squarely into the N category (either that or it is an
early April 1 RFC candidate).  I understand, though, that it is actually
receiving serious discussion on the IETF list, so I'm happy that you are
bringing some of that discussion to this forum.  Of course, common
courtesy would have required that the WG the work of which is being
disparaged in outrageous fashion be included in the discussion but
courtesy seems to be in short supply.

> 
> http://www.ltsnet.net:8080/hokey/issue39
> EMSK: applicability statement, scope
> 
> The EMSK document, as-is, allows (or more precisely does not
> disallow) for broader use of keys than it should.  

That may be somebody's claim; however, RFC 3748 says:

   Extended Master Session Key (EMSK)
      Additional keying material derived between the EAP client and
      server that is exported by the EAP method.  The EMSK is at least
      64 octets in length.  The EMSK is not shared with the
      authenticator or any other third party.  The EMSK is reserved for
      future uses that are not defined yet.

This doesn't appear to me to constrain the uses of the EMSK;
furthermore, since Bernard is not just one of the authors of 3748 but
also a co-Chair of the working group that published it, it seems like
the time & place to constrain the usage of the EMSK would have been
during the drafting of the RFC and in the eap WG.  

> There could
> be interoperability issues if applications require
> EAP-generated keys, breaking the layering of the Internet protocol
> stack. 

What does that mean?  How can _keys_ cause layer violations?

> 
> Some sort of statement regarding applicability and scoping of
> derived keys is necessary for this document.
> 
> --
> t. charles clancy, ph.d.                 eng.umd.edu/~tcc
> electrical & computer engineering, university of maryland
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www.ietf.org/mailman/listinfo/hokey
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf