1. DTN Security Update Stephen Farrell, Trinity College Dublin Susan Symmington, The MITRE Corp. Howard Weiss, Sparta Inc. IETF-65 Dallas March 2006

2. Document status DTN Security Overview –draft-irtf-dtnrg-sec-overview-01 Won’t cover today unless… Bundle Security Protocol Specification –draft-irtf-dtnrg-bundle-security-01 Comments to dtn-sec@mailman.dtnrg.org or to dtn- interest@dtnrg.org (usual subscription rules)dtn-sec@mailman.dtnrg.orgdtn- interest@dtnrg.org

3. Bundle security changes Aligned terminology with Bundle Protocol spec. Allow security headers to follow the payload, so nodes with small buffers can validate the security results in large bundles –Add a new field to the headers to correlate front/rear pairs –Ciphersuite ID is in front header; security result in rear Increased the # bits for indicating the ciphersuite Accommodated and use SDNVs Removed the discussion of bundle service API primitives and parameters (as in Bundle spec.)

4. Bundle security (quickly) Header types (BAH, PSH, CH = 2,3,4) and mandated use of canonical bundle header format Canonicalization for putting bundles with BAHs and PSHs in the correct form for security result calculation and verification –Strict and mutable c14n algs –Needs checking – typical place to go wrong. Three mandatory ciphersuites (one each for BAH, PSH, and CH) –BAH-HMAC –PSH-RSA-SHA256 –CH-RSA-AES-PAYLOAD-PSH

5. Big Open Issue - Combinations Question is really how much flexibility to allow in terms of combining PSH and CH –Example 1: order of application Node1 adds PSH (signs) Node2 adds CH (encrypts) Node3 verifies PSH (strips?) Node4 removes CH (decrypts) –Example 2: super encryption Its hard to get this right and the current draft probably doesn’t –And things get complex very quickly Guidance?

6. Other open issues Providing confidentiality for source, destination, and possibly other header fields Key Management (lack of a delay-tolerant method) –Research topic really Handling Replays –Some replays are desirable; how distinguish them? –Deleting “recently seen” messages is impractical in a DTN context Traffic Analysis –Not clear if there is a need for hiding traffic, but perhaps –Current known methods of doing so consume significant resources Routing Protocol Security Security Policy Distribution Multicast Security

7. Implementation It’d be really nice to get someone coding this stuff up –Any takers?

8. Plans Receive and incorporate comments on the two drafts Security overview document may be ready to go to (informational) RFC as is Bundle Security Protocol may need additional ciphersuites to handle more complex combinations of applying PSH/CH services; please make your preferences known Goal: submit both security specs into the RFC process by summer