Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h5BIEh302508 for ; Wed, 11 Jun 2003 14:14:43 -0400 (EDT) Received: by bache.ece.cmu.edu (Postfix, from userid 953) id C339997; Wed, 11 Jun 2003 14:14:42 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by bache.ece.cmu.edu (Postfix) with ESMTP id 86C4F7C; Wed, 11 Jun 2003 14:14:37 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix) id 1D2D289D8; Wed, 11 Jun 2003 14:14:21 -0400 (EDT) Received: from hazard.ece.cmu.edu (HAZARD.ECE.CMU.EDU [128.2.129.24]) by sos.ece.cmu.edu (Postfix) with ESMTP id 0D312894F for ; Wed, 11 Jun 2003 14:14:21 -0400 (EDT) Received: by hazard.ece.cmu.edu (Postfix) id E5A5675; Wed, 11 Jun 2003 14:14:20 -0400 (EDT) Received: by hazard.ece.cmu.edu (Postfix, from userid 953) id B640D7A; Wed, 11 Jun 2003 14:14:20 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by hazard.ece.cmu.edu (Postfix) with ESMTP id A23E775 for ; Wed, 11 Jun 2003 14:14:18 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix, from userid 363) id 7531989D9; Wed, 11 Jun 2003 14:14:18 -0400 (EDT) X-Original-To: ips@sos.ece.cmu.edu Received: from osgood.ece.cmu.edu (OSGOOD.ECE.CMU.EDU [128.2.129.25]) by sos.ece.cmu.edu (Postfix) with ESMTP id 1E98F894F for ; Wed, 11 Jun 2003 14:14:17 -0400 (EDT) Received: by osgood.ece.cmu.edu (Postfix) id 6904182; Wed, 11 Jun 2003 14:14:16 -0400 (EDT) Delivered-To: ips@ece.cmu.edu Received: by osgood.ece.cmu.edu (Postfix, from userid 953) id 2E1028E; Wed, 11 Jun 2003 14:14:16 -0400 (EDT) Received: from maho3msx2.corp.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by osgood.ece.cmu.edu (Postfix) with ESMTP id 0C0C282 for ; Wed, 11 Jun 2003 14:14:14 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Jun 2003 14:14:10 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CD56@corpmx14.corp.emc.com> From: Black_David@emc.com To: nramas@windows.microsoft.com, ips@ece.cmu.edu Subject: RE: iSCSI: Keys used in security negotiation stage Date: Wed, 11 Jun 2003 14:06:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33044.1FB28B50" Sender: owner-ips@ece.cmu.edu Precedence: bulk X-Spam-Status: No, hits=-8.2 required=5.0 tests=BAYES_20,HTML_50_60,HTML_FONT_COLOR_BLUE,NO_REAL_NAME, ORIGINAL_MESSAGE version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33044.1FB28B50 Content-Type: text/plain; charset="iso-8859-1" Yes, the set of keys usable during security negotiation is deliberately limited. The text in question might have been better phrased as "Other keys MUST NOT be used." --David -----Original Message----- From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com] Sent: Wednesday, June 11, 2003 1:31 PM To: ips@ece.cmu.edu Subject: iSCSI: Keys used in security negotiation stage Section 11 iSCSI Security Text Keys and Authentication Methods lists a set of keys that can be used in security negotiation stage. It also says "NO OTHER keys MAY be used". Is it safe to assume that any other key received during security negotiation stage is a protocol error? thanks! -lakshmi ------_=_NextPart_001_01C33044.1FB28B50 Content-Type: text/html; charset="iso-8859-1" Message
Yes, the set of keys usable during security negotiation is
deliberately limited.  The text in question might have been
better phrased as "Other keys MUST NOT be used."  --David
-----Original Message-----
From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com]
Sent: Wednesday, June 11, 2003 1:31 PM
To: ips@ece.cmu.edu
Subject: iSCSI: Keys used in security negotiation stage

Section 11 iSCSI Security Text Keys and Authentication Methods
lists a set of keys that can be used in security negotiation stage.
It also says "NO OTHER keys MAY be used". Is it safe to assume
that any other key received during security negotiation stage
is a protocol error?
 
thanks!
 -lakshmi
 
------_=_NextPart_001_01C33044.1FB28B50--