|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am ESTExcerpting the important point: > o.k. Lets see what I have understand now: If PFS by rekeying is not > mandatory to use (and this is the situation) then you can established with > DH exchange a key (referred here now by me as long-term key) and use other > protocols, e.g. Basic Quick Mode or Stealthkey, to derive multiple keys > (referred here as short-term keys) from the long-term key. The compromise > of short-term keys must not compromise the long-term key. This formulation > should be also conform with Paul Koning's comment. Yes, with a slight clarification of "must not" - "when properly used, compromise of short-term keys must not compromise the long-term key". Eventually, any key is vulnerable to compromise from overuse, even if that use is only as part of generation of other keys. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Christina Helbig [mailto:cbh@zyfer.com] > Sent: Friday, June 28, 2002 7:37 PM > To: 'Black_David@emc.com'; ips@ece.cmu.edu > Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, > Jul y 1 at 8am EST > > > David, thank you for the time for answer. Comments inside: > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Friday, June 28, 2002 1:07 PM > > To: Christina Helbig; ips@ece.cmu.edu > > Subject: RE: IPS-All: Reminder - Security draft last call > ends Monday, > > Jul y 1 at 8am EST > > > > > > Christina, > > > > Thanks for your comments. I don't think there are technical issues > > in the two areas of concern you've raised - could you please check > > the following discussion and see if it's ok? > > > > I. Rekeying and PFS > > > > The requirement for PFS is "MUST implement" (must support) > > not "MUST use". > > Christina's text appears to be objecting to a "MUST use" > > requirement - if > > so, this is not a problem, as the requirement is "MUST implement", > > which is the intention of the "must support" wording in > section 2.1 of > > the security draft. > o.k. I understood. > > > > II. Manual keying and PFS > > > > Section 5.9 was not intended to provide an exception to the > > "MUST NOT use" > > manual keying requirement stated in Section 2.3.3. The > > Section 5.9 text > > should be clarified to make this clear. > > > o.k. > > > Second, if PFS would be not mandatory by rekeying then you > > can use manual > > > keying together with other protocols for frequent > rekeying, e.g. our > > > proposal. > > > > I don't think there's an issue here, but some terminology > > clarification is > > in order - in essence properly designed "manual keying together with > > other protocols for frequent rekeying" is "preshared keying" and is > > allowed (in fact it's required). > > > > The term "manual keying" describes situations in which keys are > > preconfigured > > (manually) and then those keys are used as the session keying > > material for > > the SAs that carry traffic - rekeying is accomplished by (manually) > > configuring new keys. Manual keying is forbidden (MUST NOT use) for > > IP Storage due to the inability to automatically generate new secure > > session keys. > > > > The term "preshared keying" describes situations in which the > > preconfigured > > keys are used to derive multiple session keys in a fashion > > that compromise > > of a session key does not imply compromise or serious > weakening of the > > preconfigured keys (IKE uses a keyed prf [usually a hash] to > > obtain this > > property). Pre-shared keying is REQUIRED (MUST implement). > > > o.k. Lets see what I have understand now: If PFS by rekeying is not > mandatory to use (and this is the situation) then you can > established with > DH exchange a key (referred here now by me as long-term key) > and use other > protocols, e.g. Basic Quick Mode or Stealthkey, to derive > multiple keys > (referred here as short-term keys) from the long-term key . > The compromise > of short-term keys must not compromise the long-term key. > This formulation > should be also conform with Paul Koenigs comment. > > The StealthKey mechanism described in > > draft-helbig-stealthkey-01.txt is > > a preshared keying mechanism that can automatically generate new > > (short-term) session keys, and hence is not forbidden by the > > requirement > > that manual keying MUST NOT be used. OTOH, StealthKey is not > > specified > > in any of the IP Storage protocol drafts. > > > o.k. We try to get some attention from the IPSec working > group for this > proposal. I think this is the right WG. I was only concerned > that we have no > chance to use this for IP Storage protocols but the right > understanding of > Internet-Standards is really a skill after long-training. > Thank you > Christina > > Thanks, > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > -----Original Message----- > > > From: Christina Helbig [mailto:cbh@zyfer.com] > > > Sent: Friday, June 28, 2002 2:03 PM > > > To: 'Elizabeth Rodriguez'; ips@ece.cmu.edu > > > Subject: RE: IPS-All: Reminder - Security draft last call > > ends Monday, > > > Jul y 1 at 8am EST > > > > > > > > > These are my IPS Security draft last call comments. I'm also > > > impressed about > > > the good work others have done. > > > > > > I have problems with following text about rekeying and > > manual keying. > > > > > > I. Rekeying and PFS: > > > > > > First there are two statements, which I think are not consistent: > > > > > > a) 2.1. Security requirements > > > ...The IP block storage security protocols must support perfect > > > forward secrecy in the rekeying process. > > > > > > b) 2.2. Resource constraints > > > Computational horsepower should be available to perform a > > > reasonable amount > > > of exponentiation as part of authentication and key derivation for > > > connection setup. The same is true of rekeying, although the > > > ability to avoid exponentiation for rekeying may be desirable (but > > > is not an absolute requirement). > > > > > > In RFC 2409 is a clear definition of PFS for IKE: > > > 3.3 Perfect Forward Secrecy > > > When used in the memo Perfect Forward Secrecy (PFS) refers to > > > the notion > > > that compromise of a single key will permit access to only > > > data protected by > > > a single key. For PFS to exist the key used to protect > > > transmission of data > > > MUST NOT be used to derive any additional keys, and if the > > key used to > > > protect transmission of data was derived from some other > > > keying material, > > > that material MUST NOT be used to derive any more keys. > > > > > > If a) is the requirement than you can never avoid > exponentiation for > > > rekeying because otherwise you must use keying material to > > > derive more than > > > one key. > > > > > > Second I think PFS should not be a requirement for rekeying, > > > only a nice to > > > have. Why? > > > > > > There is currently a discussion about PFS and rekeying by SOI > > > in the IPSec > > > list and here is what I wrote and nobody opposed me (what not > > > mean that I'm > > > right ;-) > > > > > > "IMO there is a mix of the issue of PFS and rekeying in the > > > discussion. > > > 1. Rekeying is needed if the amount of with the same key > > > encrypted data goes > > > beyond specific values, because of some passive attacks > against the > > > encrypted data (dependable also of the encryption algorithm > > > and its mode) > > > and the active attack of replaying by ESP after the sequence > > > number counter > > > has started again. > > > 2. The need for PFS by the process of rekeying is not based > > > on protection > > > against this attacks under 1. > > > 3. The property of PFS is an advantage in the case of > > > unauthorized access to > > > secret information used to generate the communication keys. > > > If this secret > > > information can be secured against unauthorized access then > > > rekeying can be > > > done without the property of PFS. > > > 4. On the other hand there is always a need by IKE to > protect secret > > > information against unauthorized access used for phase 1 > > > authentication. If > > > the protection of this secret information in the system is > > > sufficient why > > > should there the protection of another secret information be > > > insufficient? > > > > > > My proposal is: Rekeying is necessary under specific > > > circumstances, which > > > should be described. PFS is not needed if the secret > > > information used to > > > generate different communication keys is protected against > > > unauthorized > > > access in the same manner like the phase 1 authentication secret." > > > > > > The main reason for avoiding mandatory PFS by rekeying, I > > think is the > > > computational overhead. I have mentioned in the SOI discussion: > > > > > > "I found different statements about the CPU time necessary for one > > > exponentiation between 30ms and some seconds. In the > > > draft-ietf-ips-security-13.txt it's time for rekeying for one > > > SA by 10Gbps > > > and 3DES in CBC mode all 27.5s or before 2^35 bytes are sent. > > > Assume the > > > case of some hundred SAs per peer with permanently > > > irregularly distributed > > > traffic between the SAs. Then rekeying at time is necessary > > > for every SA all > > > 27.5 s. This looks like a computational border, so you must have > > > amount-based rekeying in this case and encrypted bytes or > > > blocks must be > > > counted for every SA. Is that a computational border too?" > > > > > > There was no answer like "This is no problem". > > > > > > Last I like to mention the possibility to rekey without > > exchanges (and > > > without PFS). We have developed a protocol for frequent > > > rekeying without > > > exchanges and would be happy if some folks could have a look > > > at this and say > > > if it makes sense or not > > > (<http://www.rfc-editor.org/internet-drafts/draft-helbig-steal > > thkey-01.txt>) > > > > II. Manual keying and PFS: > > > > First there are again two statements, which I think are not > > consistent: > > > > > > c) 2.3.3. IKE > > ...Manual keying MUST NOT be used since it does not provide > > the necessary > > rekeying support. > > > > d) 5.9 Use of AES in counter mode > > > > ...The implication of this is that it is almost always an > error to use > > IPsec manual keying with counter mode, except when the > implementation > > takes heroic measures to maintain state across sessions. > > > > That means there is an exception from MUST NOT? > > > > Second, if PFS would be not mandatory by rekeying then you > > can use manual > > keying together with other protocols for frequent rekeying, e.g. our > > proposal. > > Thank you for your patient regarding my bad English. > > Christina > > > > > -----Original Message----- > > > From: Elizabeth Rodriguez [mailto:elizabeth.g.rodriguez@123mail.net] > > Sent: Thursday, June 27, 2002 2:41 PM > > To: ips@ece.cmu.edu > > Cc: Elizabeth.G.Rodriguez@123mail.net > > Subject: IPS-All: Reminder - Security draft last call ends > > Monday, July > > 1 at 8am EST > > > > > > Just a reminder to all to get your last call comments on the > > security draft in. > > The cutoff is Monday July 1 at 8am EST > > > > Thanks, > > > > Elizabeth > > > > >
Home Last updated: Mon Jul 01 13:19:05 2002 11044 messages in chronological order |