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

[Black_David@emc.com]

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.

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.

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

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.

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