Subject: [MSEC] weis-esp-group-counter, was MSEC status update (fwd)

From: [email-masked]
Date: Mon, 05 Feb 2007 13:30:27 -0500

Hi Brian and Lakshminath, 

<snip> 

> V.
> New work (to be adopted after asking for group's opinion):

<snip> 

> draft-weis-esp-group-counter-cipher-00: Ditto.

I do not have a strong objection to this draft being adopted as a MSEC 
working group item. However, there are several questions (problems?) that I 
wondered about when I did a quick superficial review of this draft. 

1) A fundamental problem is nonce or IV re-use, as recently discussed at 
length on CFRG. Wei Dai posted an good summary of those discussions and what 
to do about this problem about a week ago. I would suggest that this draft 
should include that guidance in its security considerations. That said, I 
suspect the risk of compromise is magnified in direct proportion to the size 
of the group membership. Instead of two endpoints, there are "N" endpoints 
that could accidently re-use a {SID, SSIV} pair, and this needs to be 
emphasized by this draft. There were about two dozen CFRG e-mail exchanges 
about random number generation, counter management, virtual machine 
interactions, and re-boot scenarios. At the least, the Sender-Specific IV 
(SSIV) field must be saved in a non-volatile storage after each use to avoid 
the scenario where a re-boot causes accidental {SID, SSIV} re-use. That way 
if a member re-boots then re-joins the same group, then it MUST also restart 
its SSIV at the last value used plus one. This is only one example. There 
are other cases mentioned by CFRG that need documentation. Perhaps the SID 
and SSIV must be qualified by a third field assigned by the GCKS, a 
"registration instance" counter? 

2) A second problem is the inability to scale to large groups because the 
per sender state that receivers must maintain to enforce anti-replay 
services. The draft does not mention anti-replay service or how it interacts 
in this multi-sender group scenario. The draft must state that anti-replay 
service is not recommended, or else explain how it is done such that it 
scales to a large group. 

3) The draft as written assumes that there is only a single cryptographic 
group and a single omnipotent GCKS. It seems to preclude any easy extension 
or accommodation for composite groups or distributed S-GCKS operations. In 
particular, the requirements in section 4 could be a source of complexity. 
Is an endpoint always required to interact with the same S-GCKS? Are all 
S-GCKS expected to know the SID of every potential group member? 

4) The assertion made in section 6, the Security Considerations, that the 
security is equivalent to that of a single sender is not true and should be 
replaced with text along the lines described above. 

hth,
  George

_______________________________________________
MSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/msec

---

From: Brian Weis <[email-masked]>
Date: Tue, 6 Feb 2007 21:44:50 -0800

Hi George,

Thanks for your review. Some comments are embedded below.

On Feb 5, 2007, at 10:30 AM, [email-masked] wrote:

> I do not have a strong objection to this draft being adopted as a  
> MSEC working group item. However, there are several questions  
> (problems?) that I wondered about when I did a quick superficial  
> review of this draft.
> 1) A fundamental problem is nonce or IV re-use, as recently  
> discussed at length on CFRG. Wei Dai posted an good summary of  
> those discussions and what to do about this problem about a week  
> ago. I would suggest that this draft should include that guidance  
> in its security considerations. That said, I suspect the risk of  
> compromise is magnified in direct proportion to the size of the  
> group membership. Instead of two endpoints, there are "N" endpoints  
> that could accidently re-use a {SID, SSIV} pair, and this needs to  
> be emphasized by this draft. There were about two dozen CFRG e-mail  
> exchanges about random number generation, counter management,  
> virtual machine interactions, and re-boot scenarios. At the least,  
> the Sender-Specific IV (SSIV) field must be saved in a non-volatile  
> storage after each use to avoid the scenario where a re-boot causes  
> accidental {SID, SSIV} re-use. That way if a member re-boots then  
> re-joins the same group, then it MUST also restart its SSIV at the  
> last value used plus one. This is only one example. There are other  
> cases mentioned by CFRG that need documentation. Perhaps the SID  

I'm aware of the CRFG thread, and will review it for additional  
security considerations text as you suggest. Regarding re-use of the  
SSIV, your suggestion may not be appropriate as there are some  
devices for which frequent writes to non-volatile storage (e.g.,  
NVRAM) are not appropriate. It was our intention that re-joins would  
be detected by the GCKS during re-registration, and that it would  
take appropriate action. I'll review Section 4 and clarify this.

> 2) A second problem is the inability to scale to large groups  
> because the per sender state that receivers must maintain to  
> enforce anti-replay services. The draft does not mention anti- 
> replay service or how it interacts in this multi-sender group  
> scenario. The draft must state that anti-replay service is not  
> recommended, or else explain how it is done such that it scales to  
> a large group.

Describing anti-replay services would make sense for a draft that is  
defining how multi-sender AH or ESP should be deployed. But his draft  
has a more modest goal of describing how multi-sender counter-mode  
ciphers can be deployed. The draft-ietf-msec-ipsec-extensions I-D  
gives the guidance you mention above. This guidance is certainly  
relevent to the esp-group-counter draft, but I don't think this  
document needs to do more than reference that I-D. I can add text  
pointing readers to that document for guidance on multi-sender SAs.

> 3) The draft as written assumes that there is only a single  
> cryptographic group and a single omnipotent GCKS. It seems to  
> preclude any easy extension or accommodation for composite groups  
> or distributed S-GCKS operations. In particular, the requirements  
> in section 4 could be a source of complexity. Is an endpoint always  
> required to interact with the same S-GCKS? Are all S-GCKS expected  
> to know the SID of every potential group member?

We didn't intend to make restrictions regarding composite groups or  
distributed S-GCKS operations. But this is hard to answer without  
knowing exactly how the distributed GCKS system in a particular  
deployment works.

> 4) The assertion made in section 6, the Security Considerations,  
> that the security is equivalent to that of a single sender is not  
> true and should be replaced with text along the lines described above.

The actual sentence is: "When [this document's] recommendations are  
followed, the security of the crypto algorithms is equivalent to the  
conventional case in which there is a single sender." We believe that  
this is a true statement as long as the IVs are not reused (i.e., the  
recommendations in this document). But we'll certainly add points  
made on the CFRG thread as well, as you suggest.

Thanks,
Brian

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Brian Weis <[email-masked]>
Date: Tue, 6 Feb 2007 21:44:50 -0800

Hi George,

Thanks,
Brian

---

From: [email-masked]
Date: Wed, 07 Feb 2007 06:51:32 -0500

Hi Brian, 

To fully avoid the IV reuse problem in the general case, you probably need 
to encode a 4-tuple: {S-GCKS-ID, (re-)registration counter, SID, SSIV}. This 
approach would avoid the need write the SSIV to non-volatile storage and the 
potential problems that would occur if a group uses a distributed GCKS. 

I guess I'll stay tuned for the next revision of this draft. 

br,
  George 

Brian Weis writes: 

>> working group item. However, there are several questions  (problems?) 
>> that I wondered about when I did a quick superficial  review of this 
>> draft.
>> length on CFRG. Wei Dai posted an good summary of  those discussions and 
>> what to do about this problem about a week  ago. I would suggest that 
>> this draft should include that guidance  in its security considerations. 
>> That said, I suspect the risk of  compromise is magnified in direct 
>> proportion to the size of the  group membership. Instead of two 
>> endpoints, there are "N" endpoints  that could accidently re-use a {SID, 
>> SSIV} pair, and this needs to  be emphasized by this draft. There were 
>> about two dozen CFRG e-mail  exchanges about random number generation, 
>> counter management,  virtual machine interactions, and re-boot scenarios. 
>> At the least,  the Sender-Specific IV (SSIV) field must be saved in a 
>> non-volatile  storage after each use to avoid the scenario where a 
>> re-boot causes  accidental {SID, SSIV} re-use. That way if a member 
>> re-boots then  re-joins the same group, then it MUST also restart its 
>> SSIV at the  last value used plus one. This is only one example. There 
>> are other  cases mentioned by CFRG that need documentation. Perhaps the 
>> SID  and SSIV must be qualified by a third field assigned by the GCKS, a  
> I'm aware of the CRFG thread, and will review it for additional  security 
> considerations text as you suggest. Regarding re-use of the  SSIV, your 
> suggestion may not be appropriate as there are some  devices for which 
> frequent writes to non-volatile storage (e.g.,  NVRAM) are not 
> appropriate. It was our intention that re-joins would  be detected by the 
> GCKS during re-registration, and that it would  take appropriate action. 
> I'll review Section 4 and clarify this. 
> 
>> 2) A second problem is the inability to scale to large groups  because 
>> the per sender state that receivers must maintain to  enforce anti-replay 
>> services. The draft does not mention anti- replay service or how it 
>> interacts in this multi-sender group  scenario. The draft must state that 
>> anti-replay service is not  recommended, or else explain how it is done 
>> such that it scales to  a large group.
> 
> defining how multi-sender AH or ESP should be deployed. But his draft  has 
> a more modest goal of describing how multi-sender counter-mode  ciphers 
> can be deployed. The draft-ietf-msec-ipsec-extensions I-D  gives the 
> guidance you mention above. This guidance is certainly  relevent to the 
> esp-group-counter draft, but I don't think this  document needs to do more 
> than reference that I-D. I can add text  pointing readers to that document 
> for guidance on multi-sender SAs. 
> 
>> cryptographic group and a single omnipotent GCKS. It seems to  preclude 
>> any easy extension or accommodation for composite groups  or distributed 
>> S-GCKS operations. In particular, the requirements  in section 4 could be 
>> a source of complexity. Is an endpoint always  required to interact with 
>> the same S-GCKS? Are all S-GCKS expected  to know the SID of every 
>> potential group member?
> 
> distributed S-GCKS operations. But this is hard to answer without  knowing 
> exactly how the distributed GCKS system in a particular  deployment works. 
> 
>> 4) The assertion made in section 6, the Security Considerations,  that 
>> the security is equivalent to that of a single sender is not  true and 
>> should be replaced with text along the lines described above.
> 
> recommendations in this document). But we'll certainly add points  made on 
> the CFRG thread as well, as you suggest. 
> 
> Thanks,
> Brian 
> 
>> hth,
>>  George 
>>

---

From: [email-masked]
Date: Wed, 07 Feb 2007 06:51:32 -0500

Hi Brian, 

br,
  George