RE: [dtn-security] Comments on DTN Security Overview]

"Susan F. Symington" <susan@mitre.org> Fri, 01 April 2005 19:28 UTC

Received: from smtp-bedford-dr.mitre.org (smtp-bedford-dr-x.mitre.org [192.160.51.65]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j31JSUV12893 for <dtn-security@mailman.dtnrg.org>; Fri, 1 Apr 2005 11:28:30 -0800
Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with SMTP id j31JSTj22524 for <dtn-security@mailman.dtnrg.org>; Fri, 1 Apr 2005 14:28:29 -0500
Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (Postfix) with ESMTP id 7E13C4F8DB for <dtn-security@mailman.dtnrg.org>; Fri, 1 Apr 2005 14:28:29 -0500 (EST)
Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with ESMTP id j31JSTL22487; Fri, 1 Apr 2005 14:28:29 -0500
Message-Id: <200504011928.j31JSTL22487@smtp-bedford-dr.mitre.org>
Received: from mm122433-pc.mitre.org (128.29.14.8) by mailhub1.mitre.org with SMTP id 14760360; Fri, 01 Apr 2005 14:28:22 -0500
From: "Susan F. Symington" <susan@mitre.org>
To: <dtn-security@mailman.dtnrg.org>
Cc: "'Stephen Farrell'" <stephen.farrell@cs.tcd.ie>, "'Howard Weiss'" <Howard.Weiss@sparta.com>
Subject: RE: [dtn-security] Comments on DTN Security Overview]
Date: Fri, 1 Apr 2005 14:28:19 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01C536C7.0D3B7780"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-reply-to: <424996C4.9080605@sparta.com>
Thread-Index: AcU2E/ahVnnIYhSGRIynpFxVb5vjzgAzjLYA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: dtn-security-admin@mailman.dtnrg.org
Errors-To: dtn-security-admin@mailman.dtnrg.org
X-BeenThere: dtn-security@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
Reply-To: dtn-security@mailman.dtnrg.org
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-security/>

Howie,
 
Thanks for your comments. You zero in on some very important things that we
need to clarify.  I am interspersing my comments below.
 
-susan


  _____  

From: dtn-security-admin@mailman.dtnrg.org
[mailto:dtn-security-admin@mailman.dtnrg.org] On Behalf Of Howard Weiss
Sent: Tuesday, March 29, 2005 12:56 PM
To: dtn-security@mailman.dtnrg.org
Subject: [dtn-security] Comments on DTN Security Overview]


Susan,

I've gone through your DTN security overview.

First, thanks for writing all of this down.  This was good - we've talked
about a lot of pieces of this in various fragments of other stuff and its
nice that someone finally had the time and funding to sit down and seriously
write it all down.

At first I started reading it electronically but I hate to say it, I felt
handicapped that it was a text file and that I didn't have the ability to
insert comments and changes as in Word (wow did I just say I liked something
that Microsoft produced??).  So I ended up printing it out and writing stuff
in the margins which I was going to type up.  But then I just got lazy (the
mark of a good engineer - so one of my undergrad EE professors always use to
tell us) and I just scanned in the whole lot and made it into a PDF.  It
looks like you should be able to read my marginal comments - if you can read
my handwriting that is.  
[Susan] Sorry the text format was such a handicap. Since it's intended to be
an internet draft, I wrote it in xml; hence, the text file.  

I want to say up front that I have not read Stephen's comments - I wanted to
go through this first without being "tainted" by another reviewer.  And I
still have not gone back to read his comments so I have no idea how much
overlap there is.

Some general comments:

1. While I think this was a good thing to do, I have some serious problems
with what is being said.  Sometimes its not clear who is doing what with
whom.  The whole notion of source, destination, sender, receiver needs to be
revisited to make things clearer.  Plus there are times when you don't use
the term destination and use other terms in its place.  Its still confusing
without a road-map (which I had to draw to keep myself understanding).
[Susan] Your diagram will be helpful in making the terminology clear. I will
have to go through and make sure the terms are used consistently. 

2. While you mention that public key or symmetric key crypto can be used,
you state that the symmetric keys are between bundle router pairs.  Youch -
this implies that every two communicating entities would have to have a
symmetric pair.  Talk about an explosion of keying.  Way back when we
started talking about this we were thinking more along the lines of a
net/group symmetric key to keep things simple.  
[Susan] I was trying as best I could to write generally so that the overview
would hold true independent on the type of crypto being used and independent
of any particular algorithms. At least in the overview document. Key
management is a big problem that is simply not addressed in this document
for now. 
 
But if there is to be source authentication, then the entity that possesses
the key is what gets authenticated as the source. If multiple nodes hold the
same key, then one can only authenticate down to the granularity of that
group and not authenticate any particular source. I guess we have to decide
if we think its okay to have net/group keys or not. In either case, I'm
hoping we can write a document that works whether the keys are specific to
each node or group keys, as well as whether the algorithms used require
symmetric keys or public/private key pairs.

3. Speaking of more confusion, there are a number of "bundle" terms used.
For example, "bundle agent," "bundle router," "bundle security policy
router."  Personally, I never envisioned a gaggle of devices - the bundle
agent was the same thing as the bundle router - maybe w/o a convergence
layer.   Do you really see a bunch of different flavor devices being
developed?
[Susan] I see the bundle agent as the implementation of the bundle protocol
-- as a bundle daemon. I envision a bundle agent operating at the bundle
layer in a DTN end system (the source host has a bundle agent,  and the
destination host has a bundle agent) and in DTN routers (every DTN router
along the way from source to destination also has a bundle agent). 
 
I do use the term "security policy router" to denote a DTN router that is
configured in a certain way. So, it's not really a different device, but a
device that is understood to be configured to make decisions regarding what
bundles to forward based on the value of the authentication information in
the PSH of the bundles. Stephen Farrel pointed out in his comments that in
theory every bunde router can make decisions regarding what bundles to
forward and I agree. I just find it useful to use the term security policy
router to denote a bundle router that is configured in a specific way. That
was my intention. I need to figure out a way to describe this in a way that
is less confusing. In your comments you say that it seems like the security
policy router acts like a front door firewall; yes, that is what I intended.


4. You've left out the use of keyed hashes - a la HMAC - that might suffice
for the hop-by-hop authentication.
[Susan] Yes. Sorry about that. It's hard to talk about this stuff in a
general enough way that it applies correctly to different types of
algorithms. We will need to address this specific solution when we define
the security protocol. 

5. Its also confusing who does payload security.  In one place it sounds
like its the application.  But in another place it sounds like its the
bundle agent.  It looks like you've adopted a model of the bundle agent
looking like a firewall/VPN router - that is, a standalone device acting
like a front-end.  However, I always envisioned a bundle "thing" more like
IPSec which can be run in either tunnel or transport mode.  It can be a
separate box or it can be part of the end system depending on the
environment.
[Susan] This touches on an issue that I have  brought up before and still am
not clear if everyone agrees on. My question has always been, where does the
PSH hash get signed? If the source bundle agent signs this hash, then the
source bundle agent is the entity that is authenticated as the source of the
bundle. Howeve, that bundle agent may serve several different DTN
applications. Ideally, we would like the DTN application to do the signing
and not have the bundle agent be privy to the secret key used to sign. This
way the specific source application would be the entity that is
authenticated as the source.


[Susan] I didn't think of myself as having adopted a model of the bundle
agent looking like a firewall/VPN router. I envision the bundle agent to be
a daemon running at the layer just below the application layer, probably in
the same box with the DTN application, but not necessarily. I have always
wondered, though, just where (in the application or the bundle agent) the
crypto for authentication was being performed. I don't believe we've ever
discussed the option of being able to choose to do it either above the
bundle layer or at the bundle layer a la transport versus network mode
IPsec. If we did have such a choice, wouldn't we need a way to signal this
in the protocol? This is obviously something fundamental that we need to all
think about and come to agreement on. 

6. The whole issue of "optional" security is coming back to haunt me.
First, do we have a definition of "optional?"  Is it like IPv4 where its
optional to implement and use or like IPv6 where its mandatory to implement
but optional to use?  Then there is the discussion about mixing secure DTN
elements with non-secure DTN elements.  On a global scale, I don't know how
that will work.  It could work on private DTNs but not on an Internet-like
DTN overlay where bundle agents sit on whatever network where-ever.
[Susan] Great point!  We need to think through and define exactly what is
meant by "optional".
 
The definition of "optional" that I had in mind was that an implementation
of DTN would not necessarily have to include security features. However, any
implementation of DTN that claims to implement security would have to do so
as specified in the documents that we are developing. 
 
I guess this brings up the concept of such a node "operating" in secure mode
or not. A node that does not even have security implemented can never
operate in secure mode; that seems pretty obvious. A node that does have
security implemented, though, could possibly operate in insecure mode or
secure mode. (I guess; this is all off the top of my head here...) What is
important is that in order for a network of interconnected nodes to provide
security services, every one of those interconnected nodes must not only
have security implemented, but be operating in secure mode. 
 
What does it mean to be operating in secure mode? If a node is operating in
secure mode, then all bundles received must either have a BAH or be asserted
as authenticated by the convergence layer. Whereas use of the PSH would be
optional.
 
If Security is optional in this way, then we have the possibility that a DTN
implementation that includes security could be adjacent to a DTN
implementation that doesn't include security or that does include security
but that isn't operating in secure mode, and we have to address this.
Ideally, a secure DTN must consist only of interconnected DTN nodes that do
implement security. However, what happens at the perimeter, when a secure
node may be adjacent to an insecure one?  Can a sender who is not on a
secure DTN send to a recipient that is, and vice versa?  Where would the
protections start and stop?  All that would need to be addressed.  
 
With the overlay idea that I introduced (page 48) I was trying to have a way
that two secure nodes could interoperate securely with one or more
intervening insecure nodes. For now, as Stephen suggested, it is probably
too much in this document to try to tackle a mixed case in which network has
insecure nodes interspersed with secure ones. We should just define the
network such that a secure DTN network must consist only of interconnected
DTN nodes that implement security. 


Take a look at the comments and we can talk or meet or meet. 


[Susan] I also have some responses to the comments that you wrote on the
draft itself. You ask why we do authentication but not confidentiality.  I'm
not sure, maybe we should do both. 
 
I agree key management is a major issue and needs closure, but I don't want
to tackle it in this document.
 
Do you think we need to address how access control policy is set and updated
in this document (page 15) ? We have a way for the convergence layer to
signal that a bundle has been authenticated based on the regional network
that was used to to deliver it. How does a node's policy regarding whether
to signal bundles received from a certain network as authenticated get set?
I don't know. It needs to be addressed. The question is do we have to
address it in this document. 


The bundle protocol specification as currently written allows doing hashing
without signing, but in the overview document I eliminated this as a
possibility. Do you think we should have the option fo hashing without
signing? (page 20). I don't like it because it can be misunderstood to
provide a false sense of security.
 
We need better terminology.  We all want to be able to say that a bundle =
header + payload, but this is not consistent with the bundle protocol
specification. In that, the payload is just one field in one of the bundle
headers.
 
It seems you think it would be unrealistic to use MACs between bundle
routers to perform authentication because of the explosion of symmetric
keys. And you may be right for most uses. I guess that I'm thinking we
shouldn't disallow symmetric keying to be used just because we think it
won't be realistic for most cases. If it makes sense for some cases, then it
would be nice if we could write the specs so that it would be possible to do
it in DTN.  
 
I guess I"m okay with deleting the last part of section 4.5, starting with
4.5.1. I think this would please Stephen as well. Stephen?
 
I see your points (page 31) that instead of putting fields in the header to
support confidentiality, we could just let this information be carries as
part of the payload metadata instead. However, somewhere we would still have
to specify how this information is formatted. Is there a disadvantage to
having it be part of the payload instead of part of a header field? You ask
why don't we provide encryption of we are already providing authentication
at the bundle layer. I don't know. I believe Stephen had a similar comment.
Maybe we should provide encryption at the bundle layer. Do you know if there
was any specific reason it was left out of the bundle protocol originally?
 
I'm not sure what you mean by you "keys are crown jewels" comment (page 34).



I should delete mention of IBC from the document; key management won't be
addressed in this overview document. 

I will also endeavor to look through Stephen's comments.
[Susan] Please look through my responses to Stephen's comments too; I
believe that some of my responses to his comments are also applicable to
some of the points you raise.   Thanks again. With you and Stephen getting
so involved we are going to make great progress.
 
-susan 

Regards,

Howie


-- 

Howard Weiss

SPARTA, Inc.

7075 Samuel Morse Drive

Columbia, MD 21046

410.872.1515 x201

410.872.8079 (fax)