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

[Christina Helbig <cbh@zyfer.com>]

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
> >  
> > 
>