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

[Brian Weis <[e-mail]>]

Hi George,

Thanks for your review. Some comments are embedded below.

On Feb 5, 2007, at 10:30 AM, [e-mail] wrote:

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

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

> hth,
>  George
>
> _______________________________________________
> MSEC mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/msec

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: [phone]
Email: [e-mail]

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