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

[[e-mail]]

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: 

> 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