RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST

[Black_David@emc.com]

I think we're close to violent agreement.  For the AES example, as the
amount of material encrypted with the same key goes up, the attacker
has more ciphertext from the same key to work with - admittedly,
with AES the incremental advantage of more ciphertext is rather
small and it may take enormous amounts to gain any real advantage
over brute force.  In any case, this is not an issue with the IPS
Security draft.

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: Monday, July 01, 2002 1:05 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
> 
> 
> Hi, David
> I think it is not right that "any key is vulnerable to compromise from
> overuse,
> even if that use is only as part of generation of other 
> keys." Lets look for
> example simple to encryption with AES: there is no way known 
> better than
> brute force to get the key even if this key is used for encryption of
> arbitrary many plaintexts and all plaintext-ciphertext-pairs 
> are known.
> Correct me if I'm wrong.
> Greetings
> Christina
> 
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Monday, July 01, 2002 6:56 AM
> > To: Christina Helbig; ips@ece.cmu.edu
> > Subject: RE: IPS-All: Reminder - Security draft last call 
> ends Monday,
> > Jul y 1 at 8am EST
> > 
> > 
> > Excerpting 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
> > > >  
> > > > 
> > > 
> > 
>