SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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


Home

Last updated: Mon Jul 01 13:19:05 2002
11044 messages in chronological order