KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI

Black_David at emc.com Black_David at emc.com
Tue Oct 13 17:21:33 PDT 2009


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0910136_f.htm">HTML-formatted message</a>

Kevin,
To be precise, what's actually exchanged is key exchange material.
Whether
that material is actually a public key is a potential matter of
hair-splitting,
as *if* one wants to view it as a member of a key pair, that key pair is
usually ephemeral and in particular, the key is not associated with any
identity
(e.g., the key exchange material is not being used to establish
authentication).
FWIW, the security community does not generally view an ephemeral DH
exchange
(at least the mod-P variety) as involving key pairs.
I think I just "won" an action to write a proposal for November that:
- Changes "format" to "binary representation" in the crucial location.
- Corrects the ECP key binary representation mistake in RFC 4753.
- Makes the vague reference to "registry" more precise (at the very
least
    a Table number and column header are called for).
I'm unlikely to use the phrase "public key" in that proposal ;-).
Thanks,
--David
________________________________
	From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
	Sent: Tuesday, October 13, 2009 7:31 PM
	To: Black, David; Tim Johnson; David L Swanson; Lou Dickens
	Cc: t10 at t10.org
	Subject: RE: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
	David, 
	Thank you for your reply.  If I read what you said correctly,
then the value for the ECP group would also be the public key.	But I
think I am missing something because that doesn't make sense that they
are both the same thing and we don't state that straight out in SPC-4. 
	As for the wording change, changing "format" to "binary
representation" makes the text read 
	>>> 
	The KEY EXCHANGE DATA field contains the sender's Diffie-Hellman
public value for this key exchange. The <binary representation> of key
exchange data is as specified in the reference cited in that registry
for the value used." 
	>>>> 
	This still leaves me hanging on what "the reference cited in
that registry for the value used" is referring to. 
	This sounds like a double or triple indirection and it is not
very clear. 
	Thanks, 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware
	MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
	Tel: 520-799-5280
	Fax: 520-799-2723 (T/L:321)
	Email address: kdbutt at us.ibm.com
	http://www-03.ibm.com/servers/storage/
<http://www-03.ibm.com/servers/storage/&gt;  
From:	<Black_David at emc.com> 
To:	Kevin D Butt/Tucson/IBM at IBMUS, <t10 at t10.org> 
Date:	10/13/2009 04:10 PM 
Subject:	RE: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
________________________________
	Kevin, 
	> The question of the format is to be used is not clear since it
is not clear what the reference cited is.
	> This still bugs me. If this field is simply the public key
(with prepended zeros to pad to the length of
	> the prime modulus (if that function was chosen), why not just
say that. 
	For a mod-P group, that's exactly what it is.  For ECP, the
answer is a
	more complex form of "yes" because the representation turns out
to be
	partially implicit. 
	> Now in http://tools.ietf.org/html/rfc4753
<http://tools.ietf.org/html/rfc4753&gt;  there is a mention of using a KE
format for ECP group generated
	> public key in section 7. In the section which follows there
are some examples. 
	Unfortunately, RFC 4753 got it wrong - there's a very important
erratum that
	invalidates all of its examples - only the x value is passed,
not both the
	x and y values, see: 
	http://www.rfc-editor.org/errata_search.php?rfc=4753
<http://www.rfc-editor.org/errata_search.php?rfc=4753&gt;	
	We will need to fix this in SPC-4. 
	> In these examples there are 2 DWORDs preceding the public key.
The first is the number of bytes
	> of the payload. The second is the group number in the upper
half of the DWORD. 
	Not exactly - those examples are complete IKE KEi and KEr
payloads, so
	they contain the entire payload headers, with the NEXT PAYLOAD
field
	set to zero in each case for the purpose of the example.  For
IKEv2-SCSI,
	these payload headers are specified as bytes 0-7 in table 427
(SPC-4 rev 21). 
	> So, does the format then depend on which D-H group is being
used? 
	Yes and no:
	- Yes, you have to know whether it's a mod P group vs. an ECP
group in
	   order to figure out what to do with the key exchange
material.
	   Trying to use a mod-P DH value as an ECP x coordinate or
vice-versa
	   is not going to work very well :-).
	- No, the payload format is common; headers plus key exchange
material. 
	> Just the public key if it's a mod P group, and the public key
preceded by these two DWORDs if it's an ECP group? 
	No, it's always the "public key".  The two DWORDS are payload
headers
	that are already specified in SPC-4 Table 427. 
	> My questions are: 
	> 1) Is the answer, Just the public key if it's a mod P group?
	Yes. 
	> 2) What can be done in SPC-4 to clear up the confusion?  Can
this be more detailed or can there be an example added?
	At the very least, we need to fix the mistake in RFC 4753.  If
we changed
	"format" to "binary representation" would that help? 
	Thanks,
	--David 
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org
<mailto:owner-t10 at t10.org> ] On Behalf Of Kevin D Butt
	Sent: Tuesday, October 13, 2009 12:45 PM
	To: t10 at t10.org
	Subject: KEY EXCHANGE DATA and confusion in SPC-4 IKEv2-SCSI
	T10 Security experts, 
	I am receiving requests to clarify what is intended for the key
exchange data field in the key exchange payload for the D-H portion of
IKEv2-SCSI.  I must admit I cannot figure it out.  We always get wrapped
around the wording, " The format of key exchange data is as specified in
the reference cited in that registry for the value used"  What is the
reference cited and what is the registry?  Then, since the term format
is used, it leads one to believe there is something more than just a
public key. 
	Here is a note I received that highlights the confusion: 
	Is the key data field of the .key exchange payload is simply the
public key from the agreed upon D-H group? What makes this confusing is
the SPC-4 standard in section 7.6.3.5.3 Key Exchange Payload which
states 
	The KEY EXCHANGE DATA field contains the sender's Diffie-Hellman
public value for this key exchange. The format of 
	key exchange data is as specified in the reference cited in that
registry for the value used. 
	The question of the format is to be used is not clear since it
is not clear what the reference cited is.This still bugs me. If this
field is simply the public key (with prepended zeros to pad to the
length of the prime modulus (if that function was chosen), why not just
say that. Mentioning a format makes it sound like there is more to it.
Now in http://tools.ietf.org/html/rfc4753
<http://tools.ietf.org/html/rfc4753&gt;  there is a mention of using a KE
format for ECP group generated public key in section 7. In the section
which follows there are some examples. In these examples there are 2
DWORDs preceding the public key. The first is the number of bytes of the
payload. The second is the group number in the upper half of the DWORD.
In http://tools.ietf.org/html/rfc2408
<http://tools.ietf.org/html/rfc2408&gt; , the Internet Security Association
and Key Management Protocol (ISAKMP), section 3.7 defines the key
exchange payload which includes a Key Exchange Data field. Again, it
seems this field depends on the D-H group. although this (ISAKMP)
standard is more general. 
	So, does the format then depend on which D-H group is being
used? Just the public key if it's a mod P group, and the public key
preceded by these two DWORDs if it's an ECP group? 
	My questions are: 
	1) Is the answer, Just the public key if it's a mod P group? 
	2) What can be done in SPC-4 to clear up the confusion?  Can
this be more detailed or can there be an example added? 
	thanks, 
	Kevin D. Butt
	SCSI & Fibre Channel Architect, Tape Firmware
	MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
	Tel: 520-799-5280
	Fax: 520-799-2723 (T/L:321)
	Email address: kdbutt at us.ibm.com
	http://www-03.ibm.com/servers/storage/
<http://www-03.ibm.com/servers/storage/&gt;  



More information about the T10 mailing list