1 / 8

DTN Security Update

DTN Security Update. Stephen Farrell, Trinity College Dublin Susan Symmington, The MITRE Corp. Howard Weiss, Sparta Inc. IETF-65 Dallas March 2006. Document status. DTN Security Overview draft-irtf-dtnrg-sec-overview-01 Won’t cover today unless… Bundle Security Protocol Specification

page
Télécharger la présentation

DTN Security Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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)

  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

More Related