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

[Christina Helbig <cbh@zyfer.com>]

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