11-080r2: Token security

david.black at emc.com david.black at emc.com
Tue Apr 19 13:28:45 PDT 2011


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

Kevin,
A cryptographic token implementation is not required.  Stop reading at the
example at the end of the first paragraph in r2, which does not require any
crypto.  None of the text beyond that example is intended to invalidate it as
a possible implementation.
I will endeavor to make this clearer in r3, starting by moving the
crypto-related material into its own subclause with a clear first sentence
that indicates that the subclause only applies to situations where some token
modifications are not detectable.  The relationship of crypto to “some
token modifications are not detectable” is that there needs to be a
cryptographic difficulty barrier to making an undetectable token
modification.
If all token modifications are detected, or the modified token will be
invalid for other reasons if a modification is not detected, there’s no
need for crypto.
Thanks,
--David
From: Kevin D Butt [mailto:kdbutt at us.ibm.com]
Sent: Tuesday, April 19, 2011 3:52 PM
To: Black, David
Cc: Black, David; owner-t10 at t10.org; t10 at t10.org
Subject: RE: 11-080r2: Token security
David,
I probably misstated secure.  I did mean cryptographic.  I admit, however,
that your requirements language confuses me and I interpret that to require a
cryptographic token.  It is not clear that the intent is otherwise - at least
to me.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
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/
From:	     <david.black at emc.com>
To:	   Kevin D Butt/Tucson/IBM at IBMUS
Cc:	   <t10 at t10.org>, <david.black at emc.com>
Date:	     04/19/2011 11:56 AM
Subject:	RE: 11-080r2: Token security
Sent by:	owner-t10 at t10.org
________________________________
Kevin,
Thanks for taking a look at the document.
There’s no requirement that tokens be secure in the sense that cryptography
is required in their implementation, but there is a requirement that token
modifications be detectable (i.e., it must not be possible for an application
client to edit a token and thereby obtain access to data that the token did
not grant when created).  All of the crypto-related requirements language is
introduced by the following words:
If the copy manager determination of whether a ROD token is valid cannot
detect all modifications to an issued ROD token
In addition, the previous sentence provides an example of how to avoid that
“If” (compare the entire token to a copy saved when it was created).  If
you’d like to weaken that quoted “If” text, or the related requirement
that the entire contents of the token be checked, I welcome suggested
alternative text and rationale.
The two comments in the FDF are fine with me, and I’ll reflect them in the
r3.  FWIW, SHA2-256 and SHA2-512 are examples of functions that may be used
to reduce a token to a smaller quantity of data on which validity is checked.
Thanks,
--David
From: Kevin D Butt [mailto:kdbutt at us.ibm.com]
Sent: Tuesday, April 19, 2011 1:39 PM
To: Black, David
Cc: T10 Reflector
Subject: 11-080r2: Token security
David,
Here is a little feedback.
Also, requiring that tokens are secure is something that earlier was said
wouldn't happen.  This is something we argued against.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
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/



More information about the T10 mailing list