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

From: [email-masked]
Date: Mon, 1 Jul 2002 09:56:29 -0400

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
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Christina Helbig [mailto:[email-masked]]
> Sent: Friday, June 28, 2002 7:37 PM
> To: [email-masked]'; [email-masked]
> 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: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, June 28, 2002 1:07 PM
> > To: Christina Helbig; [email-masked]
> > 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
> > [email-masked]         Cell: +1 (978) 394-7754
> > ---------------------------------------------------
> > 
> > > -----Original Message-----
> > > From: Christina Helbig [mailto:[email-masked]]
> > > Sent: Friday, June 28, 2002 2:03 PM
> > > To: 'Elizabeth Rodriguez'; [email-masked]
> > > 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:[email-masked]]
> > Sent: Thursday, June 27, 2002 2:41 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > 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
> >  
> > 
>

---

From: Christina Helbig <[email-masked]>
Date: Mon, 1 Jul 2002 10:05:04 -0700

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

> Sent: Monday, July 01, 2002 6:56 AM

---

From: [email-masked]
Date: Mon, 1 Jul 2002 15:40:03 -0400

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

> Sent: Monday, July 01, 2002 1:05 PM

---

From: Jonathan Trostle <[email-masked]>
Date: Mon, 1 Jul 2002 15:16:36 -0700

When a target ends up in the negative authentication cache, does that imply
that the initiator will not contact the target while it's in the cache, or
does  it imply that the initiator can contact the target but should not use
IPsec (if IPsec failed)? Or shouldn't use app level security if app level
security failed?

Jonathan

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Saturday, June 29, 2002 10:42 PM
To: [email-masked]; [email-masked]
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday,
July 1 at 8am EST

>One comment/question on the security draft below:
>
>p. 23: "Where iSNS is used without security, IP block storage protocol
>implementations MUST support a negative cache for authentication
>failures."
>
>Is it worth pointing out that when iSNS is used with security, then a
>negative cache MUST NOT be used? An attacker can cause authentication >to 
>fail through a DoS attack which could result in an entry being >added to 
>the negative cache.

There are two orthogonal issues here -- one is iSNS security, the other is 
IPS protocol security. If iSNS is not secured, then a peer might receive and

accept an iSNS packet from a rogue iSNS server. However, if the IPS session 
is subsequently secured, and mutually authenticated, the endpoint specified 
in the bogus discovery message will fail to authenticate. The argument is 
that this should result in a negative cache entry within the iSNS 
implementation, so as to prevent continual attempts to authenticate to bogus

peers.

If iSNS is secured, then presumably this would preclude a rogue iSNS server,

and the negative cache is unnecessary.

Do you have an issue with the negative cache in general, or just its use 
where iSNS is secured?

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---

From: Joshua Tseng <[email-masked]>
Date: Mon, 1 Jul 2002 15:43:17 -0700

I believe the initiator should be able to re-try authentication,
provided that such re-authentication attempts don't occur at
frequencies which could be interpreted as a DOS attack.  In
any case, authentication should NOT be turned off for a target
that is in the negative authentication cache.
 
Josh

-----Original Message-----
From: Jonathan Trostle [mailto:[email-masked]]
Sent: Monday, July 01, 2002 3:17 PM
To: 'Bernard Aboba'
Cc: [email-masked]'
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y
1 at 8am EST

Jonathan 

-----Original Message----- 
From: Bernard Aboba [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Saturday, June 29, 2002 10:42 PM 
To: [email-masked]; [email-masked] 
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, 
July 1 at 8am EST 

peers. 

<http://mobile.msn.com>

---

From: [email-masked]
Date: Mon, 1 Jul 2002 18:35:40 -0400

> When a target ends up in the negative authentication cache, does
> that imply that the initiator will not contact the target while
> it's in the cache, or does  it imply that the initiator can contact
> the target but should not use IPsec (if IPsec failed)? Or shouldn't
> use app level security if app level security failed?

The first - initiator will not contact the target while it's in the
cache under the assumption that authentication will just fail again.
As Bernard wrote, this protects against a denial of service attack
where a rogue iSNS server in league with a rogue iSCSI target causes
an initiator to repeatedly waste its time trying to talk to the target.

Would it help to require an administrative interface to clear entries
from the negative cache or the entire cache?

Thanks,
--David

-----Original Message-----
From: Jonathan Trostle [mailto:[email-masked]]
Sent: Monday, July 01, 2002 6:17 PM
To: 'Bernard Aboba'
Cc: [email-masked]'
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y
1 at 8am EST

-----Original Message----- 
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Saturday, June 29, 2002 10:42 PM 
To: [email-masked]; [email-masked] 
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, 
July 1 at 8am EST 

peers.

---

From: [email-masked]
Date: Mon, 1 Jul 2002 19:08:48 -0400

Jonathan,
 
So, is the existing text ok, or do you want something changed?
 
I don't think I see any harm
in using a negative authentication cache when iSNS is operated
securely, although, as Bernard noted, it's not necessary.
 
Thanks,
--David

-----Original Message-----
From: Jonathan Trostle [mailto:[email-masked]]
Sent: Monday, July 01, 2002 6:55 PM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y
1 at 8am EST

That helps to clarify it. I don't think that the draft should require an
administrative interface. 

Jonathan 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, July 01, 2002 3:36 PM 
To: [email-masked] 
Cc: [email-masked] 
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, 
Jul y 1 at 8am EST 

Thanks, 
--David 

-----Original Message----- 
From: Jonathan Trostle [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, July 01, 2002 6:17 PM 
To: 'Bernard Aboba' 
Cc: [email-masked]' 
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y

1 at 8am EST 

-----Original Message----- 

peers.

---

From: Jonathan Trostle <[email-masked]>
Date: Mon, 1 Jul 2002 15:54:51 -0700

Jonathan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 01, 2002 3:36 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday,
Jul y 1 at 8am EST

Thanks,
--David

-----Original Message-----
From: Jonathan Trostle [mailto:[email-masked]]
Sent: Monday, July 01, 2002 6:17 PM
To: 'Bernard Aboba'
Cc: [email-masked]'
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y
1 at 8am EST

-----Original Message----- 
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Saturday, June 29, 2002 10:42 PM 
To: [email-masked]; [email-masked] 
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, 
July 1 at 8am EST 

peers.

---

From: Jonathan Trostle <[email-masked]>
Date: Mon, 1 Jul 2002 16:35:09 -0700

It's fine as is.
 
Jonathan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 01, 2002 4:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y
1 at 8am EST

Jonathan,

 
Thanks,
--David

-----Original Message-----
From: Jonathan Trostle [mailto:[email-masked]]
Sent: Monday, July 01, 2002 6:55 PM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: IPS-All: Reminder - Security draft last call ends Monday, Jul y
1 at 8am EST

Jonathan 

-----Original Message----- 

Thanks, 
--David 

-----Original Message----- 

1 at 8am EST 

-----Original Message----- 

peers.