Re: [dtn] AD review of draft-ietf-dtn-bpsec-default-sc-02

["Birrane, Edward J." <[e-mail]>]

Zahed,
  
  I think we are getting close.  I have posted a -04 version of the document. 

  My comments are below and prefaced with [EB].

> In section 4.1 :
> 
> The BCB-AES-GCM security context shall have the security context
> 	   identifier specified in Section 5.1.
> 
> is this "shall" should be a "MUST" as described in Section 3.1?

[EB] Yes! Good catch. This has been updated in the -04 version of the draft.

 
> [ZS] Ok,  is this consensus documented somewhere? Meeting notes or email
> thread or whatever?

[EB] Specific to key communication, the intent from the DTNWG through the last call was to use an approved key wrap algorithm from NIST 800-38F (which really means AES-KW since we do not have keys which require the alternate padding variant). The attempt to leave room for "other key communication techniques" that were not requested by the WG is, on reflection, more likely to hurt interoperability than to provide additional utility. I simplified this language in -04 to state AES-KW as defined in NIST 800-38F.

[EB] The default security context is meant to be a simple context that can be easy to implement with well-understood algorithms - particularly since this security context is required as a normative reference for BPv7 and BPSec. We fully expect other security contexts to be defined over time (one based on COSE is in work now) which can capture more complex behavior. 


>     > * Section 4.3.2 :
>     >      Does this "security policy" refers to local security policy?
> 
>     C15: Yes.  Security policy at the source, verifier, or acceptor is meant to
> imply the local security policy at the node.
> 
> [ZS] Ok, then clearly stating that helps. It was clearly mention in the other
> place(s).

[EB] Agree! Change made.


> [ZS] I don't think removing the fragmentation section from this document to
> some other document actually helps. This is a very important aspect of the
> security context and I think it is better to be decisive about it now. If moved
> to BPSec then other documents , specially security context documentation,
> can just refer to it. The question really is, where does it make more sense put
> there it is in line with the context of the content of the document? Right now
> I see that is BPsec.

[EB] I'm certainly fine with keeping the text in this default security context document, and left it in for the -04 version of the document.

[EB] I would not want to add this to BPSec for two reasons: (1) It is possible that some security contexts may not have these specific fragmentation vulnerabilities, (2) the impact of fragmentation on security is akin to the impact of bundle modification on security (consider malicious fragmentation) and thus covered in BPSec already. 


> [ZS] I see the test vectors related to the applicability of the this document
> hence this need to be considered well. Failing to assure interoperability
> actually undermine the intention of this document, hence any tools to help
> achieving that goal is worth putting effort into. Also we need to make sure
> the test vector is actually usable by more than one implementation.  I would
> be happy if DTN WG comes up with a best way forward here.

[EB] My only concern regarding test vectors was that there is no new algorithm here. But they certainly don't hurt! I can generate some vectors for this document.

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839