Subject: [dtn-security] Thoughts from a phone call today...
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Date: Mon, 04 Apr 2005 19:09:52 +0100
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>

Since we'd all read & commented Susan's document, Susan,
Howie and I had a phone call today to chat about that.
(If anyones interested in being part of any future such
phone calls, let us know, though we've nothing planned right
now.)

Subject to Susan or Howie correcting me, I think we more-or-
less agreed about the things below. We figured it'd be good
to first have whatever discussion (if any) we need on this
list and then forward the resulting concensus (if any!) to
the main dtn-interest list, since some of these positions
do represent changes. After that we can reflect the
appropriate changes to the security overview and (TBD)
protocol documents and go from there.

So, you should comment here if you care about this stuff.
(And if you don't: why are you reading this? :-)

Anyway here goes:-

- We think that whatever security primitives we define
   ought to be RECOMMENDED to implement and OPTIONAL to use
   (using RFC 2119 terminology). The main reasons for this
   are the very constrained hosts that may exist in some
   networks (e.g. sensor nets) which simply won't be able
   to implement crypto stuff, but also more practically,
   the fact that whatever key management scheme you care
   to define, there'll always be some cases where you
   can't get the keys in place before you want to send
   some bundles.

- On a related topic, if some DTN nodes which don't
   implement security (e.g. a collection of sensors) send
   their bundles via some more capable gateway bundle
   router, then we believe that that router ought to be
   able to "turn on" security for those bundles, for both
   end-to-end and hop-by-hop services. (This is not quite
   the same as a VPN tunnel, since there is only one
   "middlebox" which is required.)

- Due to the optional nature of security, we believe that
   each and every bundle router has to at least implicitly
   make a security policy decision as to how to handle
   all inbound bundles, and which (if any) security services
   to apply to outbound bundles. We think the PEP/PDP
   terminology common in AAA contexts might provide a useful
   way to think about this. We don't think that there's a
   need at this stage to define a standard way for DTNs to
   push/pull policy information around, given that there
   are standard ways to do that for many lower layers
   (e.g. RADIUS/DIAMETER/COPS etc.). This also calls into
   question the "special" category of security policy
   router, since every bundle router is making security
   policy decisions, even if for many routers, these are
   very, very simple ones (e.g. "well-formed=>forward").

- We think that DTNs ought to be able to provide more-or-less
   the same cryptographic security services as are provided by
   S/MIME or IPSec, but both for end-to-end and hop-by-hop uses
   (i.e. using PSH and BAH). In particular we consider that
   end-to-end confidentiality ought to be a security service
   that can be provided by DTNs. (If accepted, this would be a
   change to the status-quo.)

- We think that DTN security requires some key management
   scheme(s) be defined, but we're not sure that it'd be correct
   to pick one key management scheme and mandate that everywhere,
   i.e. saying that a kerberos or PKI or IBE based scheme is
   the one and only correct way to do DTN key managment would
   be a mistake. However, we also feel that we will need to
   define at least one key management scheme which is geared
   towards interoperability, even if this is somewhat at the
   expense of security! We may end up doing something like
   what's done with SSH, where initial connections are highly
   vulnerable against active attacks, but where, if those
   initial connections were not attacked, subsequent connections
   can be considered strongly protected.

- We still think that reactive fragmentation is a pain, but
   we can maybe handle it a bit better by having a flexible
   data structure for BAH which allows for inclusion of
   multiple authenticators each covering some headers and
   a (possibly empty) range of payload bytes. [Note: we're
   not sure where these'd be carried in the bundle.] This
   represents a slight generalisation of the "toilet paper"
   solution to reactive fragmentation.

- I probably forgot other stuff:-)

Stephen.

Date: Fri, 01 Apr 2005 12:17:11 -0800
From: Rabin Patra <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: [dtn-security] IBC for DTN
Sender: [email-masked]
Reply-To: [email-masked]

Hi Howard,

Thanks a lot for your comments -
my response is below.

Meanwhile, a more complete version of the paper is here:
http://deccan.cs.berkeley.edu/~rkpatra/cs261/dtnsec/docs/proposal/dtn_ibe.pdf
The paper still needs cleanup, it is still a draft.

Here is a web page we made for this:
http://deccan.cs.berkeley.edu/~rkpatra/cs261/dtnsec/docs/proposal/

It also has comments from people (including Susan).
I will also add the recent draft security overview from Susan.

Howard Weiss wrote:
> 
> I went thru Rabin's paper and your comments.  Nothing I've seen so far 
> has changed my opinion regarding IBE - I don't think it solves anything 
> wrt DTN.  For example:
> 
> 1. On encrypting a transmission, the source gains a "win" by not having 
> to cache the destination's public key or consult a certificate 
> authority.  However, the source does have to cache the destination ID 
> information (which is presumably much smaller than a certifcate but 
> nevertheless, its infomation that somehow has to be arrived at and 
> cached).    The destination loses because its got to go to a PKG to get 
> a private key to match the source.  I guess the private key could be 
> cached but there is still a first time penalty.  Bottom line: a zero sum 
> gain.
> 
> 2. On signing, the sender has to obtain a private key for the 
> destination from a PKG or have the private key already cached.  The 
> destination "wins" by not having to consult with any server to 
> authenticate.  Another zero sum gain. 
> 
> One side wins at the expense of the other side.  This scheme seems like 
> it would work well if there are many encrypting sources but few 
> receivers.  The win is that the sources don't have to consult with any 
> servers (or use precious cache space) before sending.  But the 
> destination has to pay the piper because of the number of private keys 
> that have to be obtained or cached.

Well there could be a difference in total number of
key lookups. Suppose there 'n' hosts and they all want to
talk to each other. In PKI there would be a total of n^2
public key lookups as each sender now has to lookup all
the receivers. In IBE, each receiver has to get its
private key only once - so we have around 'n'
private keys lookups with the PKG
(the trusted key server in IBE).
This savings might be important in DTNs.

> In either a PKI-like instantiation or an IBE-like instantiation, there 
> is still a trusted 3rd party server involved that must be consulted.  I 
> can envision ways in a PKI instantiation where there are no servers 
> (e.g., I only have a DTN CA cert and I need to talk to entity A so I 
> first send a "hello" to A and attach my public signed by the DTN CA; A 
> replies with "how are you" and sends its public, also signed by the DTN 
> CA back to me; now I can send something encrypted - costs one round trip 
> but does not involve an 3rd party server than could also be a single 
> point of failure).  I can't see how this could be done with IBE - at 
> least its not clear to me.

This roundtrip might not be acceptable in DTNs.
Its true that a 3rd party server is needed in IBE, but only
to get private keys. Once everybody has their private keys,
no round trip is necessary to setup communication.
Infact we can send encrypted data to hosts without
waiting for them to get private keys first.
Even in PKI, you have to get your public
key certificate once.

Things are more complicated with revocation -
which might be a desirable feature for DTNs.
PKI supports explicit revocation either by publishing lists
of revoked hosts that have to be pushed to all hosts
or by requiring an explicit key lookup at the sender side
for every send operation - might be difficult in DTNs.

With an IBE system, revocation
has to be implicit - by requiring hosts to get periodically
get new private keys by adding date or time information
in the public string.
By using hierarchical IBE, hosts need to go
only to their local PKG server to get their private keys.
Thus, we can bring both the decision making for revocation
(which also might be local to the receiver 'region')
as well as the private key generation together in time and space.
Now senders do not need to bother with any lookups for
validation - at the cost of implicit certification of
receivers over some time period.

We also use the same hierarchy to achieve more
fine grained control over revocation.

There are still other issues with IBE - for example,
hosts cannot generate their own key pairs - thus key escrow,
the fact that identities are sort of fixed - cannot be easily
changed (unlike public keys in PKI), need to have a common standard
for format of the public ID string etc.

- Rabin

> Howie
> 
> Susan F. Symington wrote:
> 
>> Howie,
>>  
>> I have attached the paper.  I had thought it was sent out in 
>> dtn-interest but I just checked and you are right, it was sent to me 
>> and two other people. You may want to mention to Kevin to tell Rabin 
>> to add you to his list so if he ever updates it, you will be included 
>> in the mailing. 
>>  
>> I am also attaching the comments that I sent back to Rabin. 
>>  
>> -susan
>>
>>     ------------------------------------------------------------------------
>>     *From:* Howard Weiss [mailto:[email-masked]]
>>     *Sent:* Monday, March 28, 2005 5:38 PM
>>     *To:* Susan F. Symington
>>     *Subject:* Reference in DTN Security Overview and Motivation
>>
>>     Susan,
>>
>>     I am going through your DTN security overview and motivation and
>>     came across a reference to a paper:
>>
>>     Patra, R.; "Using Identity Based Crytography for Security in
>>     DTNs," December 2004.
>>
>>     I haven't seen this - I have only heard Kevin allude to someone
>>     looking at IBE.  If you have it, can you send it to me?
>>
>>     Thanks,
>>
>>     Howie
>>
>>-- 
>>Howard Weiss
>>SPARTA, Inc.
>>7075 Samuel Morse Drive
>>Columbia, MD 21046
>>410.872.1515 x201
>>410.872.8079 (fax)
>>
>>    
>>
>>------------------------------------------------------------------------
>>
>>Using Identity based Cryptography for Security in DTNs
>>------------------------------------------------------
>>
>>This proposal describes an architecture based on Hierarchical Identity Based 
>>Encryption for providing security features in DTNs.
>>The aim is to provide confidentiality and integrity
>>for end-to-end communication as well as protection of the DTN 
>>infrastructure and efficient implementation of access control in a 
>>heterogeneous environment of hosts having varied connectivity.
>>
>>
>>The requirements for such a security architecture in DTNs are :
>>1> Implicit certification:
>>    This means that a source(A) should be able to encrypt and send a bundle to the
>>    destination(B) by using only B's public information such that B will be able
>>    to decrypt the message only if it is currently certified [9].
>>    Otherwise, senders will have to explicitly verify the current status of
>>    receivers (whether their public keys are still valid) from a third-party 
>>    trusted authority.
>>    - we also don't want senders to store for each possible destination either 
>>      a) a shared private symmetric key or b) a public key
>>    - third party certification queries may also be difficult in DTN like 
>>      heterogeneous environment where the server that has the ability to certify B 
>>      is in a different administrative region than A.
>>    - we also want to ensure that no single entity is forced to handle all 
>>      certification queries/requests - this will lead to overload and increased 
>>      latency for queries.
>>
>>2> Control over revocation over different time scales:
>>    Implicit certification eliminates the need for the sender to perform
>>    third-party certificate status queries. But in a DTN heterogeneous 
>>    environment where hosts with different levels of vulnerability might
>>    exist, we also want allow the system ( or the certificate
>>    authorities) to choose between between fine grained or coarse grained
>>    revocation for each host.
>>    i.e if a user is more trusted, the system might want to re-certify
>>    keys only every month as opposed to doing it every day.
>>    
>>
>>3> Authentication for infrastructure access control:
>>    As already suggested in [1], bundles should carry two headers i.e PSH that
>>    is signed by the original source, and BAH that is signed at each hop by the
>>    sender router.
>>    Thus we need two different types of authentication mechanisms:
>>    Router authentication (in BAH): This is used by routers to authenticate
>>      the previous hop routers. Every router might have its own specific access
>>      control policy for each router it interacts with. 
>>      Though this implies that it needs to be aware of their identities,
>>      it can be feasible as the routers might need to know only their 
>>      immediate neighbors in the DTN.
>>    Source authenticating (in PSH): 
>>     - This is used for end-to-end integrity of the bundles.
>>     - It is used by the destination host for authentication of the source of bundle.
>>     - It can also used by routers for global policy access control using 
>>       the identity of source endpoints. As routers cannot be
>>       possibly be aware of all the sources in the world, it would make more sense
>>       if these rights are encoded in the credentials (or a certificate)
>>       presented by the source along with the bundle.
>>       For example, if a source is given permission to send all its traffic 
>>       in the 'Urgent' class by the system, the all routers need to support this. 
>>     - Instead of using certificates (which can be long)  for encoding the 
>>       rights of the source, we want these rights to be encoded in the 
>>       identity of the source endpoint. 
>>       Then a successful authentication of the identity of the 
>>       source should mean that source has obtained that particular identity
>>       from the system.
>>       For example: A source 'A' possessing 'Urgent' class  would have the
>>       identity 'A.Urgent'. We need to make sure that these identities can
>>       only be provided by the system and cannot be forged by some adversary.
>>     - This would also mean that identities of would have to be part of the
>>       bundle in the PSH.
>>        
>>4> Complex access control policies:
>>    As DTNs can conceivably have multiple classes of service,
>>    we need efficient ways to represent more complex access control policies.
>>    One way is to support policies over simple boolean expressions.
>>    For example: for source A: Urgent OR Bulk class traffic.
>>      
>>
>>Assumptions and Threat Model:
>>-----------------------------
>>1> The DTN can have global access control policies that need to recognized by
>>   all routers in all administrative regions. However routers can have their
>>   own specific access control policies. (it is not clear if these should be
>>   allowed to override the former).
>>2> There is a set of trusted servers in the DTN that cannot be compromised by 
>>   adversaries. These servers will be used for key issuance, management and
>>   revocation.
>>   Other hosts (including routers) in the DTN can be compromised.
>>3> Adversaries can eavesdrop on all traffic, they can capture bundles 
>>   and also modify in flight bundles.
>>
>>
>>Types of Attacks:
>>1> Routing level attacks : Adversaries on compromising routers can
>>   can change routing entries to create routing dead-ends or loops.
>>2> Infrastructure level attacks: Adversaries can try to access the DTN 
>>   infrastructure without authorization. 
>>   They can try to flood the network or send bundles with 
>>   classes of service that are not allowed.
>>3> Data level attacks: Adversaries can eavesdrop on traffic and try to compromise 
>>   the confidentiality and integrity of the bundles in the DTN. 
>>   They can replay bundles.
>>
>>
>>    
>>Proposal:
>>---------
>>The basic proposal is to use a combination of Hierarchical Identity based
>>encryption (HIBE) and signatures (HIBS).
>>
>>
>>IBE in brief:
>>    An Identity Base Encryption (IBE) scheme is a public-key cryptosystem where 
>>    any string is a valid public key. In particular, email addresses and dates
>>    can be public keys.
>>    When Alice sends mail to Bob at [email-masked] she simply encrypts her 
>>    message using the public key string [email-masked]''. There is no need for
>>    Alice to obtain Bob's public key certificate. When Bob receives the 
>>    encrypted mail he contacts a third party, the Private Key Generator (PKG), 
>>    Bob authenticates himself to the PKG in the same way he would authenticate 
>>    himself to a CA and obtains his private key from the PKG.
>>
>>    IBE scheme consists of four algorithms: 
>>    (1) Setup: The PKG generates global system parameters and a master-key.
>>        The global system parameters need to be distributed to all hosts
>>        initially.
>>    (2) Extract: The PKG uses the master-key to generate the private key 
>>        corresponding to an arbitrary public key string ID, 
>>    (3) Encrypt: Source(A) encrypts messages using the public key ID of the
>>        destination, B.
>>    (4) Decrypt: B decrypts messages from A using the corresponding private key 
>>        that it obtained from the PKG.
>>    
>>    IBE has been proven to be secure against chosen cipher-text attacks in the 
>>    random oracle model.
>>    For more details please refer to [7]
>>    
>>    IBE based signatures schemes have also be proposed where the source can
>>    sign using its private key and the signature can be verified using the
>>    public ID string.
>>    
>>Hierarchy IBE [9] in brief:
>>    The main problem of plain IBE where the single PKG has to issue private
>>    keys for all users is mitigated by creating a hierarchy of PKGs.
>>    Hierarchy is established in the form of a tree where each 
>>    (and root) node can be a separate PKG.
>>    The identity of a particular node at level t is given by its 
>>    ID-tuple (ID1,ID2..IDt) where  ID_i corresponds to the i-th level node.
>>    For key extraction, each PKG(root or lower level one) at level t may
>>    obtain the private keys for its immediate children with ID tuple
>>    (ID1,ID2..IDt,ID_t+1).
>>    Encryption and decryption proceed similarly as IBE and the ID Tuple is used
>>    as the public key.
>>    Similar scheme can be developed for Hierarchical IB Signatures.
>>    It is also proven that HIBE is secure against collusion among lower level
>>    PKG servers.
>>
>>Bundle Transmission:
>>1> The source first uses the destination node's public ID string to encrypt
>>   the bundle. This cipher-text forms the payload of the bundle.
>>2> The PSH is then created over the payload and header (with appropriate
>>   fields zeroed out) by signing with the 
>>   source endpoint ID ( that encapsulates the requisite access control permissions).
>>   The integrity can be verified and the source identity can be 
>>   authenticated by all routers.
>>   This was one of the features desired in [1] (point 12). 
>>3> The BAH is created at each hop by the sending router. This can be done
>>   using some other cryptographic scheme (symmetric or assymmetric) also.
>>
>>Now lets see how the different requirements specified are solved:
>>1> Implicit certification:
>>    As is clear from the basic definition of IBE, a source need not know the
>>    public key of the destination before sending a bundle. 
>>    The burden of ensuring updated certification now rests on the 
>>    destination that now has to obtain the current valid private key 
>>    to be able to decrypt a received bundle.
>>
>>2> Use of hierarchy:
>>    This offers us two advantages:
>>    a> Efficient key distribution: Normal IBE has only one PKG server which 
>>      possesses the master key. This PKG is responsible for extracting private
>>      keys of all the users of the system. 
>>      By using hierarchy - a) we can first place local PKGs in every region so that
>>      destination nodes dont have to go far to get their private keys and
>>      also b) compromise of a lower level PKG does not compromise the whole
>>      system (as the master secret resides with the root PKG only).
>>      The naming scheme in HIBE also derives naturally from the naming in the DTN 
>>      architecture where the endpoint address consists of two parts - region
>>      ID and the region-specific ID.
>>      For example: if the endpoint address for Bob is 'bundles://Earth/Bob_IP', then
>>      a PKG can be placed on Earth with ID:'Earth'. For larger regions, we can
>>      further create more levels in the hierarchy.
>>
>>    b> Revocation control: 
>>      We do this by creating a sub-hierarchy for each host (in addition to the
>>      hierarchy over multiple PKGs created for key distribution). 
>>      The levels in this sub-tree would reflect the degree of control desired
>>      for revocation. Senders will use the ID tuples corresponding to the
>>      leaves of this tree for encryption.
>>      As this sub-tree is completely located at a particular
>>      host, the host can act as a PKG and extract private keys for this tree 
>>      on its own. We can control the leaves for which the host is able to generate
>>      private keys for itself by providing it private keys for only selected
>>      internal nodes of this tree.
>>      For example: the first level could be month, the second level date and 
>>       the third level: hour. Then the ID of a user Bob (in region Earth) would be
>>       Earth.Bob.May.24.12pm . 
>>       - The Earth region PKG can extract private keys for all IDs of the form 
>>         'Earth.*'. The Earth PKG can then choose to give Bob the private key 
>>         for 'Earth.Bob' if Bob is a highly trusted user. Now Bob can generate all 
>>         keys of the form 'Earth.Bob.<month>.<date>.<hour>. 
>>       - A less trusted user 'Alice' will be given the private key for
>>         'Earth.Alice.Nov' only - this will allow Alice to read messages only for
>>         month of November. For a bundle encrypted with the full ID string
>>         Earth.Alice.Nov.25.12pm, Alice will be forced to ask a new private
>>         key every hour.
>>       - For more paranoid uses, an extra level of the this tree could be a
>>         random ID. This would force the receiver to acquire a new private key
>>         for each bundle it receives. A sender can now encrypt the bundle 
>>         with 'Earth.Alice.Nov.25.12pm.<random_id>'.
>>       - A sender that wishes lower security( and lower latency) for a
>>         session can now encrypt it with 'Earth.Alice.Nov.25.12pm.0000', and Alice
>>         would have to go to the Earth PKG only once to decrypt this bundle.
>>      In general, the PKG server responsible for a user needs to compute a
>>      subset cover over the user subtree i.e the minimum set of nodes that cover
>>      all the IDs that are allowed and none of the IDs that are not allowed
>>      for that user. Then it needs to extract private keys for only those
>>      nodes in the subset cover.
>>      
>>    c> Fine grained access control:
>>     A similar scheme as above can be used for forming ID strings needed for
>>     authentication and access control as well.
>>     For this source users sign the bundles with the correct privilege
>>     desired. For example, if Alice desires 'Urgent' class of service, it will
>>     need to sign the bundle with the identity 'Alice.Urgent'. For this it
>>     needs to possess the private key corresponding to 'Alice.Urgent'. 
>>     Possession of a private key corresponding to an identity
>>     implies that the system also authorized you for the rights that are
>>     associated with that identity.
>>     This is possible in IBE because all private keys are generated by the PKGs.
>>     The same hierarchical ID structure can be used for revocation and
>>     granting of rights as well. The subtree below each host
>>     would now represent different privileges.
>>     For example: A highly valuable Bob can be given access to all classes
>>      of service by providing the private key for 'Earth.Bob.Nov.25' - Bob can
>>      then generate keys for 'Earth.Bob.Nov.25.Urgent' etc and use them for
>>      signing his bundles.
>>      A less valuable 'Alice' will only be given the private key for
>>      'Earth.Alice.Nov.25.Bulk'.
>>     However this mechanism requires the ID string to be included
>>     in the bundle header(PSH) for routers to use the correct key
>>     for authentication.
>>     This issue was raised in [1] as well for key rollover.
>>     This overall method of encoding the permissions of the user in the ID
>>     string is very similar to using accompanying certificates in traditional PKI.
>>
>>Why not PKI?:
>>-------------
>>1> Implicit certification is not possible as a source host is forced to 
>>   first acquire the identity(public key) of the destination before sending
>>   any bundle. It is also forced to check
>>   whether the destination is currently certified or not by making third-party
>>   queries.
>>2> Revocation is made much difficult in DTN and solutions like maintaining 
>>   a Certificate Revocation List(CRL) does not work for DTNs.
>>
>>Other issues and Disadvantages:
>>-------------------------------
>>1> Key escrow: 
>>    In IBE, the PKG can generate private keys for all users and thereby decrypt
>>    bundles destined for all users. This may not be always desirable.
>>    A related property is 'non-repudiability' which means that a receiver can
>>    prove that only the sender could have signed the bundle.
>>    Also, the compromise of the root PKG jeopardizes the entire system
>>    and all messages that were sent in the past.
>>
>>2> Standards issue:
>>    Since we try to encode revocation control(date etc) and access control
>>    identifiers in the ID strings, all entities in the DTN need to agree on a
>>    common format. This is similar to the problem faced in traditional PKI
>>    over the format of certificates.
>>    
>>3> Distribution of private keys:
>>    Since users ask the PKGs to generate private keys, they have to be transmitted 
>>    securely from the PKGs. This might mean that the PKGs share another key
>>    with every user just for the purpose of sending private keys.
>>
>>5> Distribution of system wide public parameters
>>    An IBE system installation needs to bootstrap all hosts with
>>    the public system parameters of the PKG. 
>>    This also might need to be updated if the root PKG is compromised.
>>
>>6> Replay attacks:
>>    Although we guarantee confidentiality and integrity, we do not have any
>>    mechanism to detect and handle replay attacks.
>>    
>>Other options and optimizations:
>>--------------------------------
>>1> Use of Certificate Based Encryption [8]:
>>   The 'key escrow' problem can be solved by using this variation where users
>>   are allowed to generate their own private keys.
>>   Senders are now able to user long lasting public keys without the need
>>   to worry about the current certification status of the destinations.
>>   This also solves the problem of securely delivering extracted private keys
>>   to each user.
>>2> Reducing overhead of using hierarchical IBE:
>>    Normal HIBE, both the length of signatures and the number of steps required
>>    for encryption are proportional to the number of levels in the ID tree.
>>    Some techniques based on the BGLS aggregated signature scheme can be used
>>    to reduce the decryption complexity.
>>3> If non-repudiability is not desired, them the scheme proposed in [10] can be
>>   used. Here the the MAC for authentication is same as the cipher-text for 
>>   encryption. It also uses the same public IDs and private keys as the standard
>>   scheme. So we can get both authentication(+integrity) and secrecy with
>>   little extra cost.
>>
>>
>>Implementation in DTN2 :
>>-----------------------
>>1> What are the basic building blocks that need to be supported in the DTN2
>>   architecture.
>>2> User management: [1] suggested that the DTN agent cannot possess the
>>   private keys. Applications should store the keys and call external
>>   entity to perform the encryption. 
>>
>>
>>
>>
>>
>>
>>References:
>>-----------
>>[1] Email correspondence on the dtn-interest mailing list
>>[2] Draft: "Identity based Encryption for Delay Tolerant Networks"
>>    A. Chakrabarti and K Fall.
>>    summary: proposes the use of IBE for both confidentiality as well
>>    as access control management in DTNs.
>>[3] Draft: "A Secure Tetherless Computing Architecture" by S.Keshav et al.
>>    summary: proposes a hierarchy of PKGs using HIBE and HIBS for efficient
>>     key management in the TCA.
>>[4] "Exploiting Hierarchical IBE for Access Control to Pervasive Computing
>>    Information"
>>    Urs Hengartner and Peter Steenkiste
>>    summary: proposes use of HIBE for both "encryption-based" and
>>     "proof-based" access control for client-server interactions.
>>     More emphasis on preventing leakage of information about access control
>>     policies
>>[5] "Hidden Credentials" 
>>    
>>    summary: use of IBE for hidden credential trust negotiation.
>>[6] "Identity based signatures"
>>    Paterson
>>    summary: one scheme for signatures based on the Boneh/Franklin scheme.
>>[7] "Identity based Encryption based on the Weil Pairing"
>>    Boneh and Franklin
>>    summary: this introduces the first concrete IBE scheme.
>>[8] "Certificate-Based Encryption and the Certificate Revocation Problem" 
>>    Craig Gentry
>>    summary: this talks about mitigating problems in IBE by proposing
>>     Certificate based Encryption(CBE) in which users can choose their own
>>     private key.
>>[9] "Hierarchical ID based Cryptography"
>>    Gentry and Silverberg
>>    summary: this extends the Boneh/Franklin IBE scheme 
>>[10]"Authenticated Identity-based Encryption"
>>    Ben Lynn
>>    summary: extends the Boneh/Franklin scheme to provide integrity of the
>>     message being encrypted.
>>      
>>
>>
>>  
>>
>>------------------------------------------------------------------------
>>
>>Rabin,
>>
>>Thank you very much for sending me your draft proposal for using IBE for security in DTNs. I appreciate having the opportunity to review it. There are a lot of good things in this paper. Of course, I won't be dwelling on them in my comments, it being the nature of comments to focus on areas that could be improved or clarified. I just want to make clear that my general reaction is very positive before I start pointing out areas that got me thinking.
>>
>>1. In your "Requirements" section, it seems to me that you have an additional implicit requirement that you really should make explicit, and that is the reuqirement of "Implicit public key distribution". This may seem obvious to someone who has been immersing himself in papers on IBE, but for the rest of us it is a novel concept, and I don't think it should be conflated with the concept of "implicit certification" as it now seems to be. By "Implicit public key distribution" I mean the ability of a user to derive the public key of an arbitrary user from some known information, such as his identity, thus eliminating the need for the user to obtain the public key from a third-party. I think your proposal would be more clear if you were to explicitly list "implicit public key distribution" (or whatever you choose to call it) as a separate requirement. It would also help to clarify the essence of "implicit certification", which is to addresses the issue of how a user who uses a 

p
>>ublic key derived from known information can be sure that the public key is still valid. The concept of getting the public key is separate from the concept of determining that the public key is still valid, and they should be treated as separate concepts. 
>>
>>2. Also in the "Requirements" section (#3, Authentication for Infrastructure access control) you say that you want the source's rights (permissions) to be encoded in  the identity of the source endpoint. But the permissions that are being requested are already encoded in the COS field. It seems a waste to also put the COS information in the source ID field. If the public key that is necessary to authenticate the bundle signature consists of a standard string composed of:
>>source endpoint id.COS.day/month/year/time(depending on granularity desired) then there is no need to put the COS information in the source ID field. 
>>By using the COS field as part of the public key encoding, you would have a straightforward mapping between the public key used both to authenticate the bundle and to thereby certify the right of the source to use this class of service, and the class of service rights that the bundle is requesting. This way, only the source ID and the validity period need be encoded in the source ID field. (Also, you may want to consider having the validity period encoded in a separate field of the bundle header rather than encoding it as part of the source ID field.) 
>>
>>3. In your section with the heading "Assumptions and Threat Model:" you have an aside stating that it is not clear if a given router's own specific access control policy should be allowed to override the global DTN access control policies that need to be recognized by all routers. My opinion is that a given router's own access control policy should be allowed to be more restrictive than the global access control policy, but it should not be allowed to be less restrictive than the global access control policy. In other words, all routers should be able to depend on all DTN bundle agents to enforce a given level of access control in determining what traffic they admit to the DTN from DTN applications; if a given router wants to be more restrictive on a given link within the DTN, that's its prerogative, and it should be able to do so (in fact, as I see it, the ability to be more restrictive is the whole point of having security policy routers). 
>>
>>4.In the "Types of Attacks" section you mention that adversaries may create routing loops. It should be noted that this is a problem that we have not yet addressed. Right now we don't have a way in the protocol to detect such an attack, and we don't really plan to be able to detect replays, so it isn't clear if or how we are planning to address this threat.
>>
>>5. In the "Bundle Transmission" section, step 2 does not make sense to me, and I think it may be an error that needs correcting. You say that the PSH is signed with the source endpoint ID. Don't you mean that it is signed with the PRIVATE KEY that corresponds to the source endpoint ID (and, if you accept my suggestion in item 2 above, it would be the private key that corresponds to the string formed by "source endpoint ID.COS.validity_time_period")? Then, any receiver can authenticate the source identity and its permissions by using the public key that is derived from the source endpoint id (or that may be exactly the source endpoint ID). 
>>
>>It should be noted (assuming I am understanding it correctly) that for any given validity time period, a single source may need to have as many as n private keys, where n is the number of different classes of service that can be represented. 
>>
>>6. In the "Bundle Transmission" section, step 3 surprises me. Don't you want to make a suggestion about how the BAH should be authenticated, or are you just leaving this for a later paper? If you are going to leave it out, which would be fine, then you should probably go back and refocus the paper to make it clear that you are really "only" addressing the end-to-end confidentiality and integrity security features of DTNs as provided by the PSH and "efficient implementation of access control in a heterogeneous environment of hosts ..." as provided by the PSH, but that discussion of infrastructure protection isn't within the scope of this paper.
>>
>>7. In your "Now lets see how the different requirements specified are solved:" section, you don't step through all the requirements that you originally proposed. This sort of thing causes those of us who are obsessive compulsive to develop all sorts of ticks and twitches. Addressing each requirements as it was originally raised would give readers like me just the sort of false sense of security that I need to sleep well at night. 
>>
>>8. In item 1 (Implicit certification) of the "Now lets see how the different requirements specified are solved:" section, you say that "a source need not know the public key of the destination before sending a bundle".  I think you really mean two things (and this goes back to my suggestion that you separate the concepts of key distribution from key certification).  I think you mean:
>> a) a source need not "look up" (as opposed to "know") the public key of the destination, and
>> b) a source need not obtain a destination's certification status before sending encrypted data to the destination as the bundle payload.
>>
>>9.In the "b> Revocation control:" section, it is worth noting (if I understandthe proposal correctly and completely) that the revocation mechanism being used is key expiration. There is no way to explicitly invalidate or revoke a private key from a user at an arbitrary time, once the key has been given to the user. Therefore, if a user Alice has been given a private key corresponding to the public key "Alice.October", this key will continue to work  through midnight on October 31, even if this key is compromised on October 1. For 30  more days, sources sending to Alice will encrypt bundle payload destined for Alice and send it to her thinking that its confidentiality is being protected even though it isnt. Therefore, the selection of the duration of a key's validity time period is an important choice and it would be good to make this clear to the reader. 
>>
>>Also, it isn't clear what the relationship is between the key's validity time period and the current real-world time. Is this relationship checked at the sender or at the recipient, or both? And how exactly is it checked?  For example,
>>If the current month is March, will a sender be allowed to encrypt a bundle that is being sent to Alice using the public key Alice.April? How about using the public key Alice.February? 
>>It seems that if the current month is March, senders should not be allowed to encrypt a bundle that is being sent to Alice using the public key Alice.February because the Alice.February key has expired and therefore it cannot be assumed to be safe to use it. 
>>
>>If Alice receives a bundle in the month of April but the bundle had been encrypted during the previous month, with the Alice.March key (which may very well happen in DTN), then what should Alice do? If she has cached the Alice.March key, then she will be able to decrypt the message, but should she? is her private key still valid?
>>
>>In other words, validity time periods may be such that a message that is sent during a validity time period will not be received until after that period is over. How should this be dealth with?  
>>
>>10. In the "Why not PKI?:" section, I am not convinced by your argument that the IBE scheme is better than the PKI scheme because when using PKI, the source host is forced to check whether the destination is currently certified or not by making third-party queries before it can send an encrypted bundle to the destination. (This is related to my comment in 9 above.) In a PKI scheme, when a source receives a destination's public key from the CA, can't that key come with a validity period, that says the key is good for the month of October, for example, and then it expires after that. If so, the source would not have to check the validity of that key before using it anytime during the month of October. The result is very similar to the result you get when using the IBE scheme using the sub-hierarchy scheme that corresponds to the month/day/hour of validity. In this respect, I don't see how the IBE scheme is any better than a PKI scheme that issues keys with validity time perio

d
>>s. Am I missing something? Both schemes seem to suffer from the fact that explicit revocation is not possible, making it impossible to revoke a certificate before its intended expiration date. At least in the PKI scheme it would be possible for a sender to query the CA to inquire whether the public key is still valid. There does not seem to be any analogous way for a sender using IBE to make such a query. To be safe, the user would have to use a random ID field in the ID string, in effect requiring a new public key to transmit each bundle (and therefore a new private key to decrypt each bundle). Distribution of the private key from the PKG to the DTN node is a not without its costs. Is there really an advantage to IBE over PKI in the respect that you mention in this section and, if so, can you please state it more clearly?
>>
>>11. In general, the paper would benefit if you were to make a more clear separation between the use of (and benefits of using) IBE for encrypting data versus for authenticating data, because those two operations are essentially the inverse of each other and they may be performed simultaneously on a given bundle sent in DTN. If the application data unit is encrypted and the bundle is signed using the PSH, then it isn't clear how the necessary public key and key validity information for both keys would be conveyed from source to destination. Your proposal talks of using the source ID field to convey the information necessary for the recipient to obtain the public key required to verify the bundle's PSH signature. How would the recipient know how to obtain the appropriate private key that it would also need to decrypt the application protocol data unit (APDU)? For example, if I understand your proposal correctly:
>>
>>On a bundle sent from Bob to Alice:
>>
>>Bob encrypts the APDU using the public key Alice.October and
>>Bob signs the bundle (in the PSH) with the private key corresponding to Bob.October.25.Urgent
>>
>>Upon receipt of the bundle, Alice would first use the public key Bob.October.25.Urgent to verify the signature in the PSH. Assuming the signature verified correctly, Alice would now get from her PKG (if she doesn't already have it) the private key corresponding to Alice.October and use it to decrypt the APDU.
>>
>>According to your proposal, the source ID has the information "Bob.October.25.Urgent" in it, so this is how Alice knows what public key to use to verify the signature in the PSH. How does Alice know that she needs the Alice.October private key (as opposed to the Alice.October.25 private key) to decrypt the APDU?  Is this string merely put into a new encryption keyID field that is carried in the bundle header?
>>
>>12. I hope IBE really woudl be secure in a DTN application and that that it will stand up to the test of time and increased scrutiny. It seems to be a genuine breakthrough that lots of folks have latched onto, but I don't feel qualified to make a judgement on its technical merits. Given that it hasn't had the scrutiny of PKI, I think it's important that DTN be designed so that it will work with both PKI and IBE. We need to be careful to define the protocols so that they don't have any hidden dependencies on the use of IBE.
>>
>>13. What about implementing IBE. Are there any implementations readily available that can be used with DTN2 or will this be something that will require a lot of development?
>>
>>Again, thanks for the opportunity to review this. I hope my comments help.
>>
>>-susan
>>
>>***********************************************************************
>>
>>Using Identity based Cryptography for Security in DTNs
>>------------------------------------------------------
>>
>>This proposal describes an architecture based on Hierarchical Identity Based 
>>Encryption for providing security features in DTNs.
>>The aim is to provide confidentiality and integrity
>>for end-to-end communication as well as protection of the DTN 
>>infrastructure and efficient implementation of access control in a 
>>heterogeneous environment of hosts having varied connectivity.
>>
>>
>>The requirements for such a security architecture in DTNs are :
>>1> Implicit certification:
>>    This means that a source(A) should be able to encrypt and send a bundle to the
>>    destination(B) by using only B's public information such that B will be able
>>    to decrypt the message only if it is currently certified [9].
>>    Otherwise, senders will have to explicitly verify the current status of
>>    receivers (whether their public keys are still valid) from a third-party 
>>    trusted authority.
>>    - we also don't want senders to store for each possible destination either 
>>      a) a shared private symmetric key or b) a public key
>>    - third party certification queries may also be difficult in DTN like 
>>      heterogeneous environment where the server that has the ability to certify B 
>>      is in a different administrative region than A.
>>    - we also want to ensure that no single entity is forced to handle all 
>>      certification queries/requests - this will lead to overload and increased 
>>      latency for queries.
>>
>>2> Control over revocation over different time scales:
>>    Implicit certification eliminates the need for the sender to perform
>>    third-party certificate status queries. But in a DTN heterogeneous 
>>    environment where hosts with different levels of vulnerability might
>>    exist, we also want allow the system ( or the certificate
>>    authorities) to choose between between fine grained or coarse grained
>>    revocation for each host.
>>    i.e if a user is more trusted, the system might want to re-certify
>>    keys only every month as opposed to doing it every day.
>>    
>>
>>3> Authentication for infrastructure access control:
>>    As already suggested in [1], bundles should carry two headers i.e PSH that
>>    is signed by the original source, and BAH that is signed at each hop by the
>>    sender router.
>>    Thus we need two different types of authentication mechanisms:
>>    Router authentication (in BAH): This is used by routers to authenticate
>>      the previous hop routers. Every router might have its own specific access
>>      control policy for each router it interacts with. 
>>      Though this implies that it needs to be aware of their identities,
>>      it can be feasible as the routers might need to know only their 
>>      immediate neighbors in the DTN.
>>    Source authenticating (in PSH): 
>>     - This is used for end-to-end integrity of the bundles.
>>     - It is used by the destination host for authentication of the source of bundle.
>>     - It can also used by routers for global policy access control using 
>>       the identity of source endpoints. As routers cannot be
>>       possibly be aware of all the sources in the world, it would make more sense
>>       if these rights are encoded in the credentials (or a certificate)
>>       presented by the source along with the bundle.
>>       For example, if a source is given permission to send all its traffic 
>>       in the 'Urgent' class by the system, the all routers need to support this. 
>>     - Instead of using certificates (which can be long)  for encoding the 
>>       rights of the source, we want these rights to be encoded in the 
>>       identity of the source endpoint. 
>>       Then a successful authentication of the identity of the 
>>       source should mean that source has obtained that particular identity
>>       from the system.
>>       For example: A source 'A' possessing 'Urgent' class  would have the
>>       identity 'A.Urgent'. We need to make sure that these identities can
>>       only be provided by the system and cannot be forged by some adversary.
>>     - This would also mean that identities of would have to be part of the
>>       bundle in the PSH.
>>        
>>4> Complex access control policies:
>>    As DTNs can conceivably have multiple classes of service,
>>    we need efficient ways to represent more complex access control policies.
>>    One way is to support policies over simple boolean expressions.
>>    For example: for source A: Urgent OR Bulk class traffic.
>>      
>>
>>Assumptions and Threat Model:
>>-----------------------------
>>1> The DTN can have global access control policies that need to recognized by
>>   all routers in all administrative regions. However routers can have their
>>   own specific access control policies. (it is not clear if these should be
>>   allowed to override the former).
>>2> There is a set of trusted servers in the DTN that cannot be compromised by 
>>   adversaries. These servers will be used for key issuance, management and
>>   revocation.
>>   Other hosts (including routers) in the DTN can be compromised.
>>3> Adversaries can eavesdrop on all traffic, they can capture bundles 
>>   and also modify in flight bundles.
>>
>>
>>Types of Attacks:
>>1> Routing level attacks : Adversaries on compromising routers can
>>   can change routing entries to create routing dead-ends or loops.
>>2> Infrastructure level attacks: Adversaries can try to access the DTN 
>>   infrastructure without authorization. 
>>   They can try to flood the network or send bundles with 
>>   classes of service that are not allowed.
>>3> Data level attacks: Adversaries can eavesdrop on traffic and try to compromise 
>>   the confidentiality and integrity of the bundles in the DTN. 
>>   They can replay bundles.
>>
>>
>>    
>>Proposal:
>>---------
>>The basic proposal is to use a combination of Hierarchical Identity based
>>encryption (HIBE) and signatures (HIBS).
>>
>>
>>IBE in brief:
>>    An Identity Base Encryption (IBE) scheme is a public-key cryptosystem where 
>>    any string is a valid public key. In particular, email addresses and dates
>>    can be public keys.
>>    When Alice sends mail to Bob at [email-masked] she simply encrypts her 
>>    message using the public key string [email-masked]''. There is no need for
>>    Alice to obtain Bob's public key certificate. When Bob receives the 
>>    encrypted mail he contacts a third party, the Private Key Generator (PKG), 
>>    Bob authenticates himself to the PKG in the same way he would authenticate 
>>    himself to a CA and obtains his private key from the PKG.
>>
>>    IBE scheme consists of four algorithms: 
>>    (1) Setup: The PKG generates global system parameters and a master-key.
>>        The global system parameters need to be distributed to all hosts
>>        initially.
>>    (2) Extract: The PKG uses the master-key to generate the private key 
>>        corresponding to an arbitrary public key string ID, 
>>    (3) Encrypt: Source(A) encrypts messages using the public key ID of the
>>        destination, B.
>>    (4) Decrypt: B decrypts messages from A using the corresponding private key 
>>        that it obtained from the PKG.
>>    
>>    IBE has been proven to be secure against chosen cipher-text attacks in the 
>>    random oracle model.
>>    For more details please refer to [7]
>>    
>>    IBE based signatures schemes have also be proposed where the source can
>>    sign using its private key and the signature can be verified using the
>>    public ID string.
>>    
>>Hierarchy IBE [9] in brief:
>>    The main problem of plain IBE where the single PKG has to issue private
>>    keys for all users is mitigated by creating a hierarchy of PKGs.
>>    Hierarchy is established in the form of a tree where each 
>>    (and root) node can be a separate PKG.
>>    The identity of a particular node at level t is given by its 
>>    ID-tuple (ID1,ID2..IDt) where  ID_i corresponds to the i-th level node.
>>    For key extraction, each PKG(root or lower level one) at level t may
>>    obtain the private keys for its immediate children with ID tuple
>>    (ID1,ID2..IDt,ID_t+1).
>>    Encryption and decryption proceed similarly as IBE and the ID Tuple is used
>>    as the public key.
>>    Similar scheme can be developed for Hierarchical IB Signatures.
>>    It is also proven that HIBE is secure against collusion among lower level
>>    PKG servers.
>>
>>Bundle Transmission:
>>1> The source first uses the destination node's public ID string to encrypt
>>   the bundle. This cipher-text forms the payload of the bundle.
>>2> The PSH is then created over the payload and header (with appropriate
>>   fields zeroed out) by signing with the 
>>   source endpoint ID ( that encapsulates the requisite access control permissions).
>>   The integrity can be verified and the source identity can be 
>>   authenticated by all routers.
>>   This was one of the features desired in [1] (point 12). 
>>3> The BAH is created at each hop by the sending router. This can be done
>>   using some other cryptographic scheme (symmetric or assymmetric) also.
>>
>>Now lets see how the different requirements specified are solved:
>>1> Implicit certification:
>>    As is clear from the basic definition of IBE, a source need not know the
>>    public key of the destination before sending a bundle. 
>>    The burden of ensuring updated certification now rests on the 
>>    destination that now has to obtain the current valid private key 
>>    to be able to decrypt a received bundle.
>>
>>2> Use of hierarchy:
>>    This offers us two advantages:
>>    a> Efficient key distribution: Normal IBE has only one PKG server which 
>>      possesses the master key. This PKG is responsible for extracting private
>>      keys of all the users of the system. 
>>      By using hierarchy - a) we can first place local PKGs in every region so that
>>      destination nodes dont have to go far to get their private keys and
>>      also b) compromise of a lower level PKG does not compromise the whole
>>      system (as the master secret resides with the root PKG only).
>>      The naming scheme in HIBE also derives naturally from the naming in the DTN 
>>      architecture where the endpoint address consists of two parts - region
>>      ID and the region-specific ID.
>>      For example: if the endpoint address for Bob is 'bundles://Earth/Bob_IP', then
>>      a PKG can be placed on Earth with ID:'Earth'. For larger regions, we can
>>      further create more levels in the hierarchy.
>>
>>    b> Revocation control: 
>>      We do this by creating a sub-hierarchy for each host (in addition to the
>>      hierarchy over multiple PKGs created for key distribution). 
>>      The levels in this sub-tree would reflect the degree of control desired
>>      for revocation. Senders will use the ID tuples corresponding to the
>>      leaves of this tree for encryption.
>>      As this sub-tree is completely located at a particular
>>      host, the host can act as a PKG and extract private keys for this tree 
>>      on its own. We can control the leaves for which the host is able to generate
>>      private keys for itself by providing it private keys for only selected
>>      internal nodes of this tree.
>>      For example: the first level could be month, the second level date and 
>>       the third level: hour. Then the ID of a user Bob (in region Earth) would be
>>       Earth.Bob.May.24.12pm . 
>>       - The Earth region PKG can extract private keys for all IDs of the form 
>>         'Earth.*'. The Earth PKG can then choose to give Bob the private key 
>>         for 'Earth.Bob' if Bob is a highly trusted user. Now Bob can generate all 
>>         keys of the form 'Earth.Bob.<month>.<date>.<hour>. 
>>       - A less trusted user 'Alice' will be given the private key for
>>         'Earth.Alice.Nov' only - this will allow Alice to read messages only for
>>         month of November. For a bundle encrypted with the full ID string
>>         Earth.Alice.Nov.25.12pm, Alice will be forced to ask a new private
>>         key every hour.
>>       - For more paranoid uses, an extra level of the this tree could be a
>>         random ID. This would force the receiver to acquire a new private key
>>         for each bundle it receives. A sender can now encrypt the bundle 
>>         with 'Earth.Alice.Nov.25.12pm.<random_id>'.
>>       - A sender that wishes lower security( and lower latency) for a
>>         session can now encrypt it with 'Earth.Alice.Nov.25.12pm.0000', and Alice
>>         would have to go to the Earth PKG only once to decrypt this bundle.
>>      In general, the PKG server responsible for a user needs to compute a
>>      subset cover over the user subtree i.e the minimum set of nodes that cover
>>      all the IDs that are allowed and none of the IDs that are not allowed
>>      for that user. Then it needs to extract private keys for only those
>>      nodes in the subset cover.
>>      
>>    c> Fine grained access control:
>>     A similar scheme as above can be used for forming ID strings needed for
>>     authentication and access control as well.
>>     For this source users sign the bundles with the correct privilege
>>     desired. For example, if Alice desires 'Urgent' class of service, it will
>>     need to sign the bundle with the identity 'Alice.Urgent'. For this it
>>     needs to possess the private key corresponding to 'Alice.Urgent'. 
>>     Possession of a private key corresponding to an identity
>>     implies that the system also authorized you for the rights that are
>>     associated with that identity.
>>     This is possible in IBE because all private keys are generated by the PKGs.
>>     The same hierarchical ID structure can be used for revocation and
>>     granting of rights as well. The subtree below each host
>>     would now represent different privileges.
>>     For example: A highly valuable Bob can be given access to all classes
>>      of service by providing the private key for 'Earth.Bob.Nov.25' - Bob can
>>      then generate keys for 'Earth.Bob.Nov.25.Urgent' etc and use them for
>>      signing his bundles.
>>      A less valuable 'Alice' will only be given the private key for
>>      'Earth.Alice.Nov.25.Bulk'.
>>     However this mechanism requires the ID string to be included
>>     in the bundle header(PSH) for routers to use the correct key
>>     for authentication.
>>     This issue was raised in [1] as well for key rollover.
>>     This overall method of encoding the permissions of the user in the ID
>>     string is very similar to using accompanying certificates in traditional PKI.
>>
>>Why not PKI?:
>>-------------
>>1> Implicit certification is not possible as a source host is forced to 
>>   first acquire the identity(public key) of the destination before sending
>>   any bundle. It is also forced to check
>>   whether the destination is currently certified or not by making third-party
>>   queries.
>>2> Revocation is made much difficult in DTN and solutions like maintaining 
>>   a Certificate Revocation List(CRL) does not work for DTNs.
>>
>>Other issues and Disadvantages:
>>-------------------------------
>>1> Key escrow: 
>>    In IBE, the PKG can generate private keys for all users and thereby decrypt
>>    bundles destined for all users. This may not be always desirable.
>>    A related property is 'non-repudiability' which means that a receiver can
>>    prove that only the sender could have signed the bundle.
>>    Also, the compromise of the root PKG jeopardizes the entire system
>>    and all messages that were sent in the past.
>>
>>2> Standards issue:
>>    Since we try to encode revocation control(date etc) and access control
>>    identifiers in the ID strings, all entities in the DTN need to agree on a
>>    common format. This is similar to the problem faced in traditional PKI
>>    over the format of certificates.
>>    
>>3> Distribution of private keys:
>>    Since users ask the PKGs to generate private keys, they have to be transmitted 
>>    securely from the PKGs. This might mean that the PKGs share another key
>>    with every user just for the purpose of sending private keys.
>>
>>5> Distribution of system wide public parameters
>>    An IBE system installation needs to bootstrap all hosts with
>>    the public system parameters of the PKG. 
>>    This also might need to be updated if the root PKG is compromised.
>>
>>6> Replay attacks:
>>    Although we guarantee confidentiality and integrity, we do not have any
>>    mechanism to detect and handle replay attacks.
>>    
>>Other options and optimizations:
>>--------------------------------
>>1> Use of Certificate Based Encryption [8]:
>>   The 'key escrow' problem can be solved by using this variation where users
>>   are allowed to generate their own private keys.
>>   Senders are now able to user long lasting public keys without the need
>>   to worry about the current certification status of the destinations.
>>   This also solves the problem of securely delivering extracted private keys
>>   to each user.
>>2> Reducing overhead of using hierarchical IBE:
>>    Normal HIBE, both the length of signatures and the number of steps required
>>    for encryption are proportional to the number of levels in the ID tree.
>>    Some techniques based on the BGLS aggregated signature scheme can be used
>>    to reduce the decryption complexity.
>>3> If non-repudiability is not desired, them the scheme proposed in [10] can be
>>   used. Here the the MAC for authentication is same as the cipher-text for 
>>   encryption. It also uses the same public IDs and private keys as the standard
>>   scheme. So we can get both authentication(+integrity) and secrecy with
>>   little extra cost.
>>
>>
>>Implementation in DTN2 :
>>-----------------------
>>1> What are the basic building blocks that need to be supported in the DTN2
>>   architecture.
>>2> User management: [1] suggested that the DTN agent cannot possess the
>>   private keys. Applications should store the keys and call external
>>   entity to perform the encryption. 
>>
>>
>>
>>
>>
>>
>>References:
>>-----------
>>[1] Email correspondence on the dtn-interest mailing list
>>[2] Draft: "Identity based Encryption for Delay Tolerant Networks"
>>    A. Chakrabarti and K Fall.
>>    summary: proposes the use of IBE for both confidentiality as well
>>    as access control management in DTNs.
>>[3] Draft: "A Secure Tetherless Computing Architecture" by S.Keshav et al.
>>    summary: proposes a hierarchy of PKGs using HIBE and HIBS for efficient
>>     key management in the TCA.
>>[4] "Exploiting Hierarchical IBE for Access Control to Pervasive Computing
>>    Information"
>>    Urs Hengartner and Peter Steenkiste
>>    summary: proposes use of HIBE for both "encryption-based" and
>>     "proof-based" access control for client-server interactions.
>>     More emphasis on preventing leakage of information about access control
>>     policies
>>[5] "Hidden Credentials" 
>>    
>>    summary: use of IBE for hidden credential trust negotiation.
>>[6] "Identity based signatures"
>>    Paterson
>>    summary: one scheme for signatures based on the Boneh/Franklin scheme.
>>[7] "Identity based Encryption based on the Weil Pairing"
>>    Boneh and Franklin
>>    summary: this introduces the first concrete IBE scheme.
>>[8] "Certificate-Based Encryption and the Certificate Revocation Problem" 
>>    Craig Gentry
>>    summary: this talks about mitigating problems in IBE by proposing
>>     Certificate based Encryption(CBE) in which users can choose their own
>>     private key.
>>[9] "Hierarchical ID based Cryptography"
>>    Gentry and Silverberg
>>    summary: this extends the Boneh/Franklin IBE scheme 
>>[10]"Authenticated Identity-based Encryption"
>>    Ben Lynn
>>    summary: extends the Boneh/Franklin scheme to provide integrity of the
>>     message being encrypted.
>>      
>>
>>
>>  
>>
> 
> -- 
> Howard Weiss
> SPARTA, Inc.
> 7075 Samuel Morse Drive
> Columbia, MD 21046
> 410.872.1515 x201
> 410.872.8079 (fax)
> 
> 

From: "Susan F. Symington" <[email-masked]>
To: <[email-masked]>
Cc: "'Stephen Farrell'" <[email-masked]>, "'Howard Weiss'" <[email-masked]>
Subject: RE: [dtn-security] Comments on DTN Security Overview]
Date: Fri, 1 Apr 2005 14:28:19 -0500
Sender: [email-masked]
Reply-To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00D6_01C536C7.0D3B7780
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Howard Weiss
Sent: Tuesday, March 29, 2005 12:56 PM
To: [email-masked]
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)

------=_NextPart_000_00D6_01C536C7.0D3B7780
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2604" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D658234217-01042005>Howie,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D658234217-01042005></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D658234217-01042005>Thanks for your comments. You zero in on some =
very=20
important things that we need to clarify.&nbsp; I am interspersing my =
comments=20
below.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D658234217-01042005></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D658234217-01042005>-susan</SPAN></FONT></DIV><BR>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of =
</B>Howard=20
  Weiss<BR><B>Sent:</B> Tuesday, March 29, 2005 12:56 PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> [dtn-security] =
Comments on=20
  DTN Security Overview]<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3D"Helvetica, Arial, sans-serif"><FONT =
size=3D2>Susan,<BR><BR>I've=20
  gone through your DTN security overview.<BR><BR>First, thanks for =
writing all=20
  of this down.&nbsp; This was good - we've talked about a lot of pieces =
of this=20
  in various fragments of other stuff and its nice that someone finally =
had the=20
  time and funding to sit down and seriously write it all =
down.<BR><BR>At first=20
  I started reading it electronically but I hate to say it, I felt =
handicapped=20
  that it was a text file and that I didn't have the ability to insert =
comments=20
  and changes as in Word (wow did I just say I liked something that =
Microsoft=20
  produced??).&nbsp; So I ended up printing it out and writing stuff in =
the=20
  margins which I was going to type up.&nbsp; But then I just got lazy =
(the mark=20
  of a good engineer - so one of my undergrad EE professors always use =
to tell=20
  us) and I just scanned in the whole lot and made it into a PDF.&nbsp; =
It looks=20
  like you should be able to read my marginal comments - if you can read =
my=20
  handwriting that is.&nbsp; <BR><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff>[Susan]&nbsp;Sorry the text format was such a =
handicap. Since=20
  it's intended to be an internet draft, I wrote it in xml; hence, the =
text=20
  file. </FONT></SPAN></FONT></FONT><FONT=20
  face=3D"Helvetica, Arial, sans-serif"><FONT size=3D2><SPAN=20
  class=3D658234217-01042005>&nbsp;</SPAN><BR><BR>I want to say up front =
that I=20
  have not read Stephen's comments - I wanted to go through this first =
without=20
  being "tainted" by another reviewer.&nbsp; And I still have not gone =
back to=20
  read his comments so I have no idea how much overlap there =
is.<BR><BR>Some=20
  general comments:<BR><BR>1. While I think this was a good thing to do, =
I have=20
  some serious problems with what is being said.&nbsp; Sometimes its not =
clear=20
  who is doing what with whom.&nbsp; The whole notion of source, =
destination,=20
  sender, receiver needs to be revisited to make things clearer.&nbsp; =
Plus=20
  there are times when you don't use the term destination and use other =
terms in=20
  its place.&nbsp; Its still confusing without a road-map (which I had =
to draw=20
  to keep myself understanding).<BR><SPAN =
class=3D658234217-01042005><FONT=20
  face=3DArial color=3D#0000ff>[Susan]&nbsp;Your diagram will be helpful =
in making=20
  the terminology clear. I will have to go through and make sure the =
terms are=20
  used consistently.&nbsp;</FONT></SPAN><BR><BR>2. While you mention =
that public=20
  key or symmetric key crypto can be used, you state that the symmetric =
keys are=20
  between bundle router pairs.&nbsp; Youch - this implies that every two =

  communicating entities would have to have a symmetric pair.&nbsp; Talk =
about=20
  an explosion of keying.&nbsp; Way back when we started talking about =
this we=20
  were thinking more along the lines of a net/group symmetric key to =
keep things=20
  simple.&nbsp; <BR><SPAN class=3D658234217-01042005><FONT face=3DArial=20
  color=3D#0000ff>[Susan]&nbsp;I was trying as best I could =
to&nbsp;write=20
  generally so that the&nbsp;overview would&nbsp;hold true independent =
on the=20
  type of crypto&nbsp;being used&nbsp;and independent of any particular=20
  algorithms. At least in the overview document. Key management is a big =
problem=20
  that is simply not addressed in this document for now.=20
  </FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=3D"Helvetica, Arial, sans-serif"><FONT size=3D2><SPAN=20
  class=3D658234217-01042005><FONT face=3DArial=20
  color=3D#0000ff></FONT></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D"Helvetica, Arial, sans-serif"><FONT size=3D2><SPAN=20
  class=3D658234217-01042005><FONT face=3DArial color=3D#0000ff>But if =
there is to be=20
  source authentication, then the entity that possesses the key is what =
gets=20
  authenticated as the source. If multiple nodes hold the same key, then =
one can=20
  only authenticate down to the granularity of that group and not =
authenticate=20
  any particular source. I guess we have to decide if we think its okay =
to have=20
  net/group keys or not. In either case, I'm hoping we can write a =
document that=20
  works whether the keys are specific to each node or group keys, as =
well as=20
  whether the algorithms used require symmetric keys or public/private =
key=20
  pairs.</FONT></SPAN><BR><BR>3. Speaking of more confusion, there are a =
number=20
  of "bundle" terms used.&nbsp; For example, "bundle agent," "bundle =
router,"=20
  "bundle security policy router."&nbsp; Personally, I never envisioned =
a gaggle=20
  of devices - the bundle agent was the same thing as the bundle router =
- maybe=20
  w/o a convergence layer.&nbsp;&nbsp; Do you really see a bunch of =
different=20
  flavor devices being developed?<BR><SPAN =
class=3D658234217-01042005><FONT=20
  face=3DArial color=3D#0000ff>[Susan]&nbsp;I see the bundle agent as =
the=20
  implementation of the&nbsp;bundle protocol -- as a bundle daemon. I =
envision a=20
  bundle agent operating at the bundle layer in a DTN end system (the =
source=20
  host has a bundle agent,&nbsp; and the destination host has a bundle =
agent)=20
  and in DTN routers (every DTN router along the way from source to =
destination=20
  also has a bundle agent).&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=3D"Helvetica, Arial, sans-serif"><FONT size=3D2><SPAN=20
  class=3D658234217-01042005></SPAN></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D658234217-01042005>I do use the term "security policy =
router"&nbsp;to=20
  denote a DTN router that is configured in a certain way. So, it's not =
really a=20
  different device, but a device that is understood to be configured to =
make=20
  decisions regarding what bundles to forward based on the value of the=20
  authentication information in the PSH of the bundles. Stephen Farrel =
pointed=20
  out in his comments that in theory every bunde router can make =
decisions=20
  regarding what bundles to forward and I agree. I just find it useful =
to use=20
  the term security policy router to denote a bundle router that is =
configured=20
  in a specific way. That was my intention. I need to figure out a way =
to=20
  describe this in a way that is less confusing. In your comments you =
say that=20
  it seems like the security policy router acts like a front door =
firewall; yes,=20
  that is what I intended. </SPAN></FONT></FONT><FONT=20
  face=3D"Helvetica, Arial, sans-serif"><BR><BR><FONT size=3D2>4. You've =
left out=20
  the use of keyed hashes - a la HMAC - that might suffice for the =
hop-by-hop=20
  authentication.<BR><SPAN class=3D658234217-01042005><FONT face=3DArial =

  color=3D#0000ff>[Susan]&nbsp;Yes. Sorry about that. It's hard to talk =
about this=20
  stuff in a general enough way that it applies correctly to different =
types of=20
  algorithms. We will need to address this specific solution when we =
define the=20
  security protocol.&nbsp;</FONT></SPAN><BR><BR>5. Its also confusing =
who does=20
  payload security.&nbsp; In one place it sounds like its the =
application.&nbsp;=20
  But in another place it sounds like its the bundle agent.&nbsp; It =
looks like=20
  you've adopted a model of the bundle agent looking like a firewall/VPN =
router=20
  - that is, a standalone device acting like a front-end.&nbsp; However, =
I=20
  always envisioned a bundle "thing" more like IPSec which can be run in =
either=20
  tunnel or transport mode.&nbsp; It can be a separate box or it can be =
part of=20
  the end system depending on the environment.<BR><SPAN=20
  class=3D658234217-01042005><FONT face=3DArial =
color=3D#0000ff>[Susan]&nbsp;This=20
  touches on an issue that I&nbsp;have&nbsp;&nbsp;brought up =
before&nbsp;and=20
  still am not clear&nbsp;if everyone agrees on. My question has=20
  always&nbsp;been, where does the PSH&nbsp;hash get signed?&nbsp;If=20
  the&nbsp;source bundle agent signs this hash, then the source bundle =
agent is=20
  the&nbsp;entity that is authenticated as the source of the=20
  bundle.&nbsp;Howeve, that bundle agent may serve several different DTN =

  applications. Ideally, we would like the DTN application to do the =
signing and=20
  not have the bundle agent be privy to the secret key used to sign. =
This way=20
  the&nbsp;specific source application would&nbsp;be the entity that is=20
  authenticated as the source.</FONT></SPAN></FONT></FONT></DIV><FONT=20
  face=3D"Helvetica, Arial, sans-serif"><SPAN =
class=3D658234217-01042005></SPAN>
  <DIV><BR><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff>[Susan]&nbsp;I didn't think of myself&nbsp;as having =
adopted a=20
  model of the bundle agent looking like a firewall/VPN router. I =
envision the=20
  bundle agent to be&nbsp;a daemon running at the layer just below the=20
  application layer, probably in the same box with the DTN application, =
but not=20
  necessarily. I&nbsp;have always wondered, though, just where (in the=20
  application or the bundle agent) the crypto&nbsp;for authentication =
was being=20
  performed. I don't believe we've ever discussed the option =
of&nbsp;being able=20
  to choose to do it either&nbsp;above the&nbsp;bundle layer or at the =
bundle=20
  layer a la transport&nbsp;versus network mode IPsec. If we did have =
such a=20
  choice, wouldn't we need&nbsp;a way to signal this in the =
protocol?&nbsp;This=20
  is obviously something fundamental that we need to all think about and =
come to=20
  agreement on.&nbsp;</FONT></SPAN><BR><BR>6. The whole issue of =
"optional"=20
  security is coming back to haunt me.&nbsp; First, do we have a =
definition of=20
  "optional?"&nbsp; Is it like IPv4 where its optional to implement and =
use or=20
  like IPv6 where its mandatory to implement but optional to use?&nbsp; =
Then=20
  there is the discussion about mixing secure DTN elements with =
non-secure DTN=20
  elements.&nbsp; On a global scale, I don't know how that will =
work.&nbsp; It=20
  could work on private DTNs but not on an Internet-like DTN overlay =
where=20
  bundle agents sit on whatever network where-ever.<BR><SPAN=20
  class=3D658234217-01042005><FONT face=3DArial =
color=3D#0000ff>[Susan]&nbsp;Great=20
  point!&nbsp;&nbsp;We need to think through and define exactly what is =
meant by=20
  "optional".</FONT></SPAN></FONT></DIV>
  <DIV><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff>The definition of "optional" that I had in mind was =
that an=20
  implementation of DTN would not necessarily have to include security =
features.=20
  However, any implementation of DTN that claims to implement security =
would=20
  have to do so as specified in the documents that we are developing.=20
  </FONT></SPAN></FONT></DIV>
  <DIV><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff>I guess this brings up the concept of such a node =
"operating" in=20
  secure mode or not. A node that does not even have security =
implemented can=20
  never operate in secure mode; that seems pretty obvious. A node that =
does have=20
  security implemented, though, could possibly operate in insecure mode =
or=20
  secure mode. (I guess; this is all off the top of my head here...) =
What is=20
  important is that in order for a network of interconnected nodes to =
provide=20
  security services, every one of those interconnected nodes must not =
only have=20
  security implemented, but be operating in secure mode.=20
  </FONT></SPAN></FONT></DIV>
  <DIV><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff>What does it mean to be operating in secure =
mode?&nbsp;If a node=20
  is operating in secure mode, then all bundles received must either =
have a BAH=20
  or be asserted as authenticated by the convergence layer. Whereas use =
of the=20
  PSH would be optional.</FONT></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D658234217-01042005></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D658234217-01042005>If=20
  Security is optional in this way, then we have the&nbsp;possibility =
that=20
  a&nbsp;DTN implementation that includes security could be adjacent to =
a DTN=20
  implementation that doesn't include security or that does include =
security but=20
  that isn't operating in secure mode, and we have to address this.=20
  &nbsp;Ideally, a secure DTN must consist only of interconnected DTN =
nodes that=20
  do implement security. However, what happens at the perimeter, when a =
secure=20
  node may be adjacent to an insecure one?&nbsp;&nbsp;Can a sender who =
is not on=20
  a secure DTN send to a recipient that is, and vice versa?&nbsp; Where =
would=20
  the protections start and stop?&nbsp; All that would need to be=20
  addressed.&nbsp; </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D658234217-01042005></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D658234217-01042005>With=20
  the overlay idea that I introduced (page 48) I was trying to have a =
way that=20
  two secure nodes could interoperate securely with one or more =
intervening=20
  insecure nodes. </SPAN></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
  class=3D658234217-01042005>For now, as Stephen suggested, it is =
probably too=20
  much in this document to try to tackle a mixed case in which network =
has=20
  insecure nodes interspersed with secure ones. We should just define =
the=20
  network such that a secure DTN network must consist only of =
interconnected DTN=20
  nodes that implement security. </SPAN></FONT></DIV><FONT face=3DArial=20
  color=3D#0000ff><SPAN class=3D658234217-01042005></SPAN></FONT>
  <DIV><BR><FONT size=3D2>Take a look at the comments and we can talk or =
meet or=20
  meet.<SPAN class=3D658234217-01042005>&nbsp;</SPAN></FONT></DIV><SPAN=20
  class=3D658234217-01042005></SPAN>
  <DIV><BR><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff>[Susan]&nbsp;I also have some responses to the =
comments that you=20
  wrote on the draft itself. You ask why we do authentication but not=20
  confidentiality.&nbsp; I'm not sure, maybe we should do=20
  both.&nbsp;</FONT></SPAN></FONT></DIV>
  <DIV><FONT size=3D2><SPAN =
class=3D658234217-01042005></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff>I agree key management is&nbsp;a major issue and needs =
closure,=20
  but I don't want to tackle it in this =
document.</FONT></SPAN></FONT></DIV>
  <DIV><FONT size=3D2><SPAN =
class=3D658234217-01042005></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff>Do you think we need to address how access control =
policy is set=20
  and updated in this document (page 15)</FONT>&nbsp;<FONT face=3DArial=20
  color=3D#0000ff>? We have a way for the convergence layer to signal =
that a=20
  bundle has been authenticated based on the regional network that was =
used to=20
  to deliver it. How does a node's policy regarding whether to signal =
bundles=20
  received from a certain network as authenticated get set? I don't =
know. It=20
  needs to be addressed. The question is do we have to address it in =
this=20
  document. </FONT></SPAN></FONT></DIV><SPAN =
class=3D658234217-01042005></SPAN>
  <DIV><BR><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff>The bundle protocol specification as currently written =
allows=20
  doing hashing without signing, but in the overview document I =
eliminated this=20
  as a possibility. Do you think we should have the option fo hashing =
without=20
  signing? (page 20). I don't like it because it can be misunderstood=20
  to&nbsp;provide a false sense of security.</FONT></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D658234217-01042005></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D658234217-01042005>We=20
  need better terminology.&nbsp; We all want to be able to say that a =
bundle =3D=20
  header + payload, but this is not consistent with the bundle protocol=20
  specification. In that, the payload is just one field in one of the =
bundle=20
  headers.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D658234217-01042005></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D658234217-01042005>It=20
  seems you think it would be unrealistic to use MACs between bundle =
routers to=20
  perform authentication because of the explosion of symmetric keys. And =
you may=20
  be right for most uses. I guess that I'm thinking we shouldn't =
disallow=20
  symmetric keying to be used just because we think it won't be =
realistic for=20
  most cases. If&nbsp;it makes sense for some cases, then it would be =
nice if we=20
  could write the specs so that it would be possible to do it in=20
  DTN.&nbsp;&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D658234217-01042005></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D658234217-01042005>I=20
  guess I"m okay with deleting the last part of section 4.5, starting =
with=20
  4.5.1. I think this would please Stephen as well. =
Stephen?</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D658234217-01042005></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D658234217-01042005>I=20
  see your points (page 31) that instead of putting fields in the header =
to=20
  support confidentiality, we could just let this information be carries =
as part=20
  of the payload metadata instead. However, somewhere we would still =
have to=20
  specify how this information is formatted. Is there a disadvantage to =
having=20
  it be part of the payload instead of part of a header field? You ask =
why don't=20
  we provide encryption of we are already providing authentication at =
the bundle=20
  layer. I don't know. I believe Stephen had a similar comment. Maybe we =
should=20
  provide encryption at the bundle layer. Do you know if there was any =
specific=20
  reason it was left out of the bundle protocol =
originally?</SPAN></FONT></DIV>
  <DIV><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff>I'm not sure what you mean by you "keys are crown =
jewels"=20
  comment (page 34).&nbsp;</FONT></SPAN></FONT></DIV><SPAN=20
  class=3D658234217-01042005></SPAN>
  <DIV><BR><FONT size=3D2><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff>I should delete mention of IBC from the document; key =
management=20
  won't be addressed in this&nbsp;overview=20
  document.&nbsp;</FONT></SPAN><BR><BR>I will also endeavor to look =
through=20
  Stephen's comments.<BR><SPAN class=3D658234217-01042005><FONT =
face=3DArial=20
  color=3D#0000ff>[Susan]&nbsp;Please look through my responses to =
Stephen's=20
  comments too; I believe that some of&nbsp;my responses to his=20
  comments&nbsp;are also applicable to some of the points you raise. =
&nbsp;=20
  Thanks again.&nbsp;With you and Stephen getting so involved we are =
going to=20
  make great progress.</FONT></SPAN></FONT></DIV>
  <DIV><FONT size=3D2><FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
  class=3D658234217-01042005></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT face=3DArial><FONT color=3D#0000ff><SPAN=20
  =
class=3D658234217-01042005>-susan&nbsp;</SPAN></FONT></FONT><BR><BR>Regar=
ds,<BR><BR>Howie<BR></FONT></FONT><BR></DIV><PRE class=3Dmoz-signature =
cols=3D"72">--=20
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

</PRE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00D6_01C536C7.0D3B7780--

From: "Susan F. Symington" <[email-masked]>
To: <[email-masked]>
Cc: "'Stephen Farrell'" <[email-masked]>, "'Howard Weiss'" <[email-masked]>
Subject: RE: [dtn-security] draft security overview and motivations document
Date: Fri, 1 Apr 2005 12:32:37 -0500
Sender: [email-masked]
Reply-To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00D3_01C536B6.E34C1890
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stephen,

Thanks for your comments. I am attaching my responses.

-susan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, March 22, 2005 8:19 AM
To: [email-masked]
Subject: Re: [dtn-security] draft security overview and motivations document

Hi Susan,

Susan F. Symington wrote:

> Attached is a first attempt at a security overview and motivations 
> document for DTN security.
>  
> Review and comment by all is solicited.

Turns out I've a plethora of comments!

First though: well done preparing this, I think its really
valuable and about time for us to seriously consider this stuff.

Second, I guess I have to confess, that I saw Susan's document
about a week ago so I been working on it on&off since then.

Anyway, here ya go!

Stephen.

------=_NextPart_000_00D3_01C536B6.E34C1890
Content-Type: text/plain;
	name="sym_response_to_motiv-notes-20050322.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="sym_response_to_motiv-notes-20050322.txt"

Overall:
--------

0. Brevity is good. The document's not brief enough:-)

Susan: Agree.

1. I'd suggest that this document be recast as something that describes =
a
snapshot of the DTNRG view on bundling security, rather than (as =
currently
seems to be the case) a requirements-type document. The main reason is =
that its
already very useful as-is, but we don't necessarily need to finalise =
every
detail before putting this to bed. Also, revisiting this to take account =
of the
final prtocool would be a pain, and not very worthwhile. Where necessary =
and
useful text from this could be inserted into the protocol document. =
Getting
this to the state where everyone's happy to decide any controversy by =
referring
back to this might be counterproductive. If this were agreed, I'd =
suggest a
quick tidy up, followed by submission to the RFC editor (maybe this'll =
be the
1st DTNRG RFC!).

Susan: This works for me.

2. The document seems (understandably given previous discussion) to =
focus too
much on cryptographic protection. I'd like to see more emphasis on =
specific
authorisation mechanisms. For example, it'd be nice to say why using =
SAML+XACML
at each bundle agent to decide whether or not to forward the bundle is =
good or
bad. Even if that combination isn't ideal, (which'd take a bit of =
thought to
establish), if it, or similar, could work, then the requirement for =
source
authentication may be easier to meet. In particular, if we assume that =
the SAML
assertions consumed by the policy enforcement point (PEP) are "fresh" =
then we
no longer need to bother thinking about source-credential revocation =
within the
network.  A successful case of kicking-to-touch/punting! Basically, =
maybe I'm
saying we ought to try think along the lines of rfc2906/7/8 about PDPs =
and PEPs
and DTN-AAA, that than take what I could term the current DTNSec type =
model.
(Ok, I confess - I'm a co-author on those RFCs, but it'd be interesting =
to see
the extent to which they, or the general PDP/PEP model, might usefully =
apply to
DTNs!)

Susan: Do you want to take a crack at writing text to express these =
ideas?=20

3. I'm not entirely comfortable with the "protect the infrastructure" =
argument,
(e.g. as stated at the start of section 2). While I don't disagree with =
lots of
the conclusions, I do believe that infrastructure is only provided for
applications, and infrasructure security likewise, so ultimately we do =
want to
protect application data. I'm not sure how I'd suggest restating this, =
but I do
think that we want to provide security tools for application data, (e.g.
key-mgmt for end2end integ).

Susan: I see your point that it only makes sense to protect the =
infrastructure from unauthorized use if you can also provide some =
security protections for the application data that is authorized to use =
the infrastructure. The DTN Architecture document states that the DTN =
security model is aimed at protecting the infrastructure from =
unauthorized use. Would it make you more comfortable if we took out the =
language about "the focus of security" and "secondary emphasis" and just =
talked about all the security protections without ranking them by =
importance?=20

4. The security goals, as stated, are open to being attacked on a number =
of
fronts (as happened in Minneapolis!). For example, the ability to =
disable a
compromised agent probably implies (giving someone) the ability to =
prevent an
authorized agent from forwarding bundles, so items 2 and 6 (from the =
list at
the start of section 2) are somewhat contradictory. Similarly, we saw at =
the
meeting that not detecting payload modification or replay is in conflict =
with
item 3 from the above list. I think that recasting DTN security along =
the lines
of the PDP/PEP model may help out here, but I also think that we do need =
to be
able to provide tools/techniques that do address e.g. payload =
modification and
replay.

Susan: Yes, I agree that the goals are open to attack. I thought it =
would be desirable to state the goals but I didn't mean to imply that we =
meet all the goals. For example, there is nothing in the document at all =
about how to achieve goal 6. Do you suggest that we not state the goals =
or that we restate them with qualifiers or what?

Susan: I also agree that we've got a fundamental and very difficult =
problem insofar as reactive fragmentation (which we want to be able to =
do) is not compatible with providing payload integrity on a hop-by-hop =
basis using the BAH authentication information field as currently =
defined in the Bundle Protocol Specification. This is a key issue that =
we need to address. A long time ago Bob Durst suggested a "toilet paper" =
approch to payload authentication that would enable bundles to be =
reactively fragmented and at the same time provide hop-by-hop payload =
authentication. We had dismissed this in favor of just not providing =
payload authentication at all. Now it seems that we may want to =
reconsider Bob's toilet paper approach, which basically involved =
formatting the payload as a series of segments of payload each followed =
by a MAC/Digital signature that authenticates that segment of payload.  =
Addressing this issue needs to be a high priority for us.

5. Other than being a bit silly, is there a specific reason not to =
provide
mechanisms that can be used to make it harder to do traffic analysis? If =
all it
amounted to was defining a "pad" bundle payload, and allowing agents to =
send
that whenever they want, then I can't see a good reason to not do this =
(even if
its not a compelling thing to be doing). I would agree that defining DTN
security so that it can provide something like a mix network with nymity =
is not
a serious goal (OTOH, if someone had a great idea for doing that, would =
it be
bad? Note: I don't have such an idea:-)

Susan: You have a good point. If all it amounts to is defining a "pad" =
payload, then we should probably do so to make it possible for folks to =
protect against traffic analysis if they want to.=20

6. Security is (correctly) stated as being optional. Therefore use of =
BAH is
optional. Therefore an authorized agent can simply send bundles which do =
not
contain a BAH. Therefore agents which support incoming BAH, MUST have a =
policy
DB (or rules, whatever) which determine whether a given DTN peer is, or =
is not,
allowed to send me this bundle, with this content and set of headers =
now.
That's a lot to get right. We might be able to tie this down a bit =
better later
on, say if BAH is turned on iff PSH is.

Susan:  I agree with everything you say in 6 but you lose me when you =
say "BAH is turned on iff PSH is". I don't understand why you would =
require BAH iff PSH is used. I consider use of BAH and PSH to be =
independent.

Susan: On another note, Howie Weiss has pointed out that we haven't =
really defined what we mean by security being "optional", and I fear =
that we may each have something a little different in mind. For example, =
I had in mind that security would be optional to implement. That is, an =
implementation could call itself an implementation of DTN but not =
implement security at all. However, if an implementation of DTN claimed =
to be secure, it would have to conform to the DTN security =
specifications. However, there is another possible understanding of =
"optional" a la IPv6 and IPsec, meaning that security in DTN would be =
mandatory to implement, but optional to use. My feeling is that it =
should be optional to implement and use. Is this how you envision it =
also?

7. This is almost a nit, but...Both IPSec and TLS provide for some =
ability to
do payload padding in order to disguise payloads where the payload =
length
determines the payload content, e.g. if the only options are "yes" and =
"no"
then length=3D2=3D>"no". If we're supporting confidentiality, then I'd =
be for
allowing the same thing here. Mind you, no-one ever uses this since =
there's no
sensible way to provide an API that anyone'd want to call.

Susan: If I understand you, then this is similar, but not exactly the =
same as your comment 5 above, and it seems reasonable to me.

8. I disagree with the "security policy router is a special agent" idea.
Basically, every agent has to make these decisions (by integrating a =
PEP), and
anything after that is a matter of local configuration (unless and until =
we
provide ways to signal in-band about some agent being a bottleneck for a =
region
or something).

Susan: Yes, I think you are right. Security Policy routers are really =
just DTN routers. They aren't a different species. They have the same =
bundle agent capabilities as other DTN routers.=20

Susan: At the same time, I guess I like having the term "security policy =
routers is that it conveys that these entities are distinguished from =
"generic" DTN routers by the fact that their policies regarding what =
bundles to forward may depend on being able to verify the PSH =
authentication information in the bundles that they receive for =
forwarding. This means that then they will require the cryptographic =
keys necessary to verify the validity of the PSH authentication =
information and also that they will have to receive all fragments of a =
PSH-protected bundle in order to be able to allow any portion of the =
bundle to be forwarded. If they don't have access to the proper keys or =
they don't receive all fragments of a bundle, then they will just be =
black holes for the affected bundles that they receive. Any DTN router =
can become a security policy router by configuring it properly and =
giving it access to the keys it will need to validate PSH authentication =
information.

Susan: So while I agree that security policy routers aren't special =
agents, I'm not clear about how I should change the text to get this =
across and also get across how they are different also. I'm not sure of =
what portion of the document inspired comment 8, so I'm not sure what =
exactly I have to fix to address your concern, but I would appreciate =
suggestions. Do you think we shouldn't have a special term called =
"security policy routers"?  What changes to the text would make this =
feel right to you?

9. Replay. I may or may not convince you, but I believe we do have to =
provide
replay detection mechanisms and maybe the Wed morning discussion in MSP =
went
some way towards us agreeing that. In any case, I don't think that this
document should be so deterministic (if you accept #1 above that is), so =
its ok
to say "replay: we're not sure yet" :-)

Susan:  I think this is a good solution for now--that is, discuss replay =
and say we aren't sure. The only reason we haven't protected against =
replay so far is that it seemed to require too much state--more than the =
benefits were worth.  I do worry that unintended routing loops could =
cause lots and lots of replays and that this situation might go =
undetected. Perhaps a good compromise would be to come up with a way to =
enable replays to be optionally detected. That is, if you wanted to =
configure a bundle agent to detect replays, you could. I guess this =
would mean that implementing replay detection would be mandatory, but =
using it would be optional. For now saying we're not sure is probably =
the best we can do.=20

Susan: Do you want to take a stab at defining how replay detection =
should be accomplished? I think that everyone agrees that providing =
replay detection has a lot of merits, but in past DTN RG discussions it =
just seemed that every way that we could come up with to provide replay =
detection required maintaining so much state that it wasn't worth it. In =
order to go back to the larger DTN RG and make a case for replay =
detection, we need to make clear the types of threats the infrastructure =
is vulnerable to without it, as well as how we propose it should be =
provided, so that it's cost/benefits could be better weighed.

10. I don't know but we may need to do more to support routing. Say if a =
new
route is announced, then a) that might be a sort-of broadcast message =
and hence
might e.g. have a different set of immutable headers (it'd certainly =
have to
use signing and not MACing) and b) an agent who's "installing" that =
route,
might have to make some kind of DTN connection to a security server if =
he's
never before been in touch with one of the regions in the announcement, =
for
example. At that stage we'd maybe have to define additional security =
rules say
matching values from the announced route and some of the stuff from the
security interchange. I know this is all very vague, but basically, the =
point
is that we might have to define specific routing security, which'd best =
be done
in a routing docuement and not here. For example, I'm not sure the =
discussion
of compromised routers and (presumably) MACing keys is in the right =
place (all
DTN agents are routers really, aren't they?)

Susan: So would an acceptable response to this comment be to replace all =
the text in 3.6 with the following: "Router and routing protocol =
security services will be vital to DTN security. However, this document =
does not yet address router or routing protocol security in DTNs"?=20

11. Traffic padding. While it may be silly in many DTN contexts to want =
to do
traffic padding, there will be contexts when it may make sense.  For =
example,
if a DTN bundle traverses the terrestrial Internet (which is highly =
likely for
many DTNs), then there may be reasons to disguise the existence of real
traffic. For example, if the "sensor" end of that DTN were of the
presence-detecting kind and takes a lot of trouble (e.g.  via =
spread-spectrum)
to try to hide a presence-detection, then it'd be a pity to leak the =
detection
to someone who only has to watch the SNMP counts on some bundle agent or
router. As section 4.1 implies, being able to support traffic padding =
requires
payload confidentiality but also requires confidentiality for some =
header
fields (mainly the destination addreess and port equivalents). I believe =
we
ought to make this possible, but I don't believe that we particularly =
need a
fully worked out, standard way to actually do traffic padding (e.g.  I =
don't
think we need to specify bahaviour for using delays for bundles just to =
diguise
routing behaviour). If we can figure out how to provide basic support =
for this,
then it could be appropriate to include it in an appendix, it certainly
oughtn't be anywhere near mandatory.

Susan: Unless you have a proposal that you want to write up, why don't =
we just for now say that the document does not provide for this, but it =
could be done at lower layers?

12. I believe that section 4.2 reflects a slightly unusual use of =
terminology.
In my mind at least, every bundle agent is making a network access =
control
choice whenever it decides to forward or deliver a bundle. So, of course =
I
don't buy the security policy router special category.

Susan: This comment seems to be the same as comment 8, so I won't reply =
separately.=20

13. Fragmentation is a pain, that's clear. Combining fragmentation with =
almost
any other service casues grief (e.g. aside from securtiy, CoS/QoS stuff =
has to
get confusing). So why don't we define a don't-fragment bit in the =
header, just
like in IP? That way, at least we can avoid the nasty cases where =
network
provisioning allows.=20

Susan:  This is a suggestion for the larger DTN group and is not =
specific to security. I will say that it doesn't seemt to solve =
anything, as reactive fragmentation is felt to be an essential part of =
DTN to enable data that does make it across a connection before it =
breaks can proceed without having to be resent. =20

14. Fragmentation again. I see a note from some "disruption" folks which
implies that maybe we've been thinking about only a subset of the types =
of
disruption they're considering. In particular, they seem to envisage =
more but
shorter outages. I think its fair to say (at least in my case) that I've
generally been thinking if the link went down, then it'd be down for the
remainder of the contact. So maybe we ought to try to figure out a =
scheme which
nicely handles mid-bundle outages. This changes the requirement for =
digesting
the payload from one where our ideal mechanism is "Verify MAC on first N =
bytes,
for any N", to one where we're after a scheme which allows "Verify MAC =
on
entire object minus some (probably contiguous) bytes". These are perhaps
sufficiently different problems that different approaches should be =
taken.  I
don't know.

Susan: I see your point. I think the "toilet paper" approach could be =
made to work in this scheme if we numbered the consecutive =
segment,authentication field pairs, but that's just off the top of my =
head. I don't really like the complicated nature of the toilet paper =
approach, and numbering the segments would just make it further =
complicated, so I'm not really advocating it, but it may be the best we =
can do.

15. Section 4.4 points out the correct fact that successfully verifying =
a MAC
means that either the claimed sender or else the verifier created the =
MAC.
While it might be impossible (given the protocol context) to get these
confused, its also considered good practice to ensure at the =
crypto-mechanism
level that this cannot occur. There are two ways to do this, either =
derive keys
based on the direction of communication, or else ensure that the =
to-be-MACed
data includes the sender-id. The former is the preferred way to achieve =
this,
since the latter is more vulnerable to evolutionary changes to the =
protocol, or
other re-uses of the MACing keys which don't identify the direction of
communication. In this context, where we probably cannot mandate a =
single key
derivation scheme for all DTNs, maybe the best we can do is to impose a
requirement that all key distribution schemes derive different keys for =
each
direction of communication. (If/when we specify key management schemes =
we
should really ensure that they all have this property of using different =
keys
for each purpose in each direction. This is done in TLS and IPSec and =
many
other reputable protocols and has little or no overhead.) To give =
another
example, and one that could easily happen, it would be potentially very =
bad to
use the same symmetric key to authenticate both a BAH and a PSH.=20

Susan: okay. This is not a subject that I know a lot about. Assuming you =
are right, we should probably make a note to include this as a =
requirement in a key management paper and mention it in section 4.4.

15. The DoS discussion focuses on whether senders are legitimate or not.
Generally the more interesting distinction is whether the originator is =
on-path
or off-path.  On-path DoS attacks are harder to make hard, whereas using =
random
values in counters etc. is quite effective in reducing the probability =
of
successful off-path attacks. At one stage it is also stated the replays =
are
difficult to mount; well that may be true or false, depending on the =
network in
question, but the point is that once you can send in a single packet its =
easy
to arrange to send in a million, and replaying is your first target if =
there's
a way for recipients to turn on authentication checks!

Susan: Perhaps we need to come up with an explicit description of what =
types of DoS attacks we are trying to protect against and what types we =
are willing to live with.

16. DoS and replay again. My main concern with the bundling protocol is =
to make
it harder to mount a battery depletion attack via replays (or more =
generally
via an adaptive attack). The problem is that many many DTNs will have =
nodes
which are vulnerable to battery depletion so we just have to do our best =
to
prevent those nodes being flooded. If bundles can be inserted into the =
DTN at
some other point(s) with a high probability that they'll eventually =
cause
traffic (and not even direct traffic, it could be NACKs or equivalent) =
to be
routed via the target node, then we've got a live DoS vulnerability =
which will
often partition an entire network. (Note that this is another strong =
argument
to integrity check the entire payload even hop-by-hop, so that =
application
layer cheating cannot result in the aimed-for misbehaviour.)

Susan: I don't recall battery depletion coming up in previous DTN RG =
discussion. It's probably worth bringing up to the larger group.

17. Application layer services. We seem to be agreed on the provision of =
data
integrity, origin authentication and application layer anti-replay =
protection,
all of which can be provided using the same mechanism, i.e. digital
signature/MAC, most likely using signature due to the ability validate =
the
signature at multiple locations. All good so far, but let's see the
consequences.=20

First, to be able to use MACing end-to-end (which is quite useful, even =
if
end-to-middle MACing isn't so useful), you need a key distribution =
scheme. The
examples of IPSec, Bluetooth and WEP, show that failing to provide such =
a key
distribution scheme limits the scope for deploying networks (ok, this =
can be
argued since the proximate causes differ in each case, but I belive its
substantially true).  That means that we need (at some point) to define =
one or
more ways to distribute symmetric keys end-to-end.  Now we could punt on =
this
and only allow that to occur out of band (e.g. during node =
provisioning), but
then we'd face the issue of key rollover which really has to be done =
in-band.
If we do provide in-band key rollover, the we absolutely require (an =
equivalent
to) an end-to-end confidentiality mechanism to be provided by the DTN, =
and not
by the applications. Remember that all of this is to maintain end-to-end =
MACing
to support data integrity, origin authentication and application layer
anti-replay, so the lesson is: if you provide end-to-end MACing and want =
the
network to scale, then you require an end-to-end data confidentiality =
mechanism
(note, a mechanism, not necesarily a service for applications).

Ok, someone who doesn't like this will say that this isn't needed to =
support
digital signatures. There are, however, cases where an equivalent =
mechanism is
required. For example, not all nodes can generate key pairs, and when =
one of
those nodes requires a new private key (required by good cryptographic
practice) that must be provided to such a node using a confidentiality
mechanism; if a private key must be moved from one node to another, say =
when
node hardware is being upgraded then again a confidentiality mechanism =
is
required. If an IBC scheme were to be used, then again the decyptor =
would have
to deal with the security server and may require a confidentiality =
mechanism.
There are also some schemes which make use of symmetric keys in order to
distribute new trusted public key information. Standard public key =
managment
protocols like CMP, CMC and XKMS all do include such confidentiality
mechanisms.

Certainly, this does not mean that every DTN node must include an
implementation of a confidentiality mechanism, nor does it mean that the
confidentiality mechanism must use the bundling protocol, nor the same =
routing,
nor need the key distribution protocols necessarily be delay or =
disruption
tolerant. However, it does require either the secret keys required are =
exposed
between the endpoints in question, or else that an end-to-end standard =
set of
key management data structures are required, which provide a fairly =
generic
confidentialtiy mechanism, at least for small, infrequently sent amounts =
of
data. The first option was tried by WAP (using TLS and then WTLS) but =
was one
of the main things which (it was claimed) caused reluctance amongst e.g. =
banks
to deploy secure banking via WAP (it may be more to the point that =
network
operators and banks have different buisness models, but nonetheless the =
claims
were made). And traditionally, end-to-end proponents (most Internet =
developers)
would argue strongly not to expose keying material in mid-network.

So, it appears that at least some, and arguably many, DTN nodes require =
an
end-to-end confidentiality mechanism, though not necessarily an =
end-to-end
confidentiality service for applications.  The question to ask though =
is: given
the above, is it really hard to extend this to provide key distribution =
for
such an end-to-end confidentiality service?=20

Susan: So you are suggesting that it may make sense to provide =
confidentiality at the bundle layer instead of requiring applications to =
perform their own encryption and decryption? In other words, bundle =
agents would perform encryption and decryption? =20

18. Combining end-to-end integrity and confidentiality. The document =
currently
allows for a flag indicating that the payload is encrypted. It also says =
that
the PSH digest is calculated over the cleartext payload. This means that
whenever the payload is encrpyted, the no middle-host can validate the =
PSH,
e.g. none of the "security policy routers" get to do their job. There =
are good
arguments for both ways of doing this (i.e. signing cleartext or signing
ciphertext), but signing the cleartext, then encrypting and including =
the
signature in clear is uncommon and has weaknesses. For example, if the
cleartext is guessable, then the signature allows for checking of =
guesses. As
it stands (i.e. if we reject my #17 above on an end-to-end =
confidentiality
service), probably best is for the PSH to contain a signature over =
ciphertext
and for data-origin-authentication to be provided in the same way as
confidentiality. (Note the PSH as reforumulated here doesn't provide
origin-authentication for the cleartext payload, since its possible that =
the
signer has stolen the ciphertext if the key managemnet scheme allows =
this.)

Susan: Does the document really say that the PSH digest is calculated =
over the cleartext payload?  I did not intend for it to say this and =
this is not what I had in mind. Please let me know where it says this.

19. Keys expire in any reasonable setting. Bundles expire too. Therefore =
one of
the things we have to do is define how these expiries relate. For =
example: is
it ok for a bundle expiry to succeed the expiry of the key with which =
you're
about to validate the bundle so long as the key was valid when the =
bundle was
protected? (SF's answer: probably.) There are a couple of these timing =
issues
that are fairly easy, but need addressing. Basically, everywhere a key =
is used
(BAH, PSH and application layer confid or whatever), you have to define =
how the
key lifecycle and bundle expiry match up.

Susan: Yes, these expiration cases would need to be defined. Let's add =
it to the list of things to do.

20. The security policy router as sinkhole threat is very serious. If I =
could
arrange (or know) that fragmentation will occur, as currently =
forumulated this
probably makes it pretty easy to DoS such a router by simply binning the =
last
fragment from all bundles that pass you by. (And the you here may not be =
a DTN
router, but some intra-regional node.) I'm not sure of the best approach =
to
take here, since it'll depend on the network, but I believe that if we =
abandon
the idea of "special" security policy routers and allow every router to =
have a
policy enforcment point, then we may make the problem more tractable. =
OTOH,
this is probably just a hard problem and hard cases will always exist
regardless of how a particular network looks (unless you totally turn =
off
fragmentation).

Susan: I don't understand how allowing every router to have a policy =
enforcement point would make this problem more tractable.

Susan: Fragmentation is felt to be extremely important in DTNs, =
particularly reactive fragmentation, so that the part of the bundle that =
was transferred successfully before a connection is lost can proceed on =
toward its destination without having to be resent. Turning off =
fragmentation is not going to be acceptable; we need to think in terms =
of fragmentation being something we need to accomodate.

Maybe the right thing (TM) here is to go back to the requirement and
momentarily forget about this solution. I belive that fragmentation and =
ingress
controls were largely motivated by earthstations, where the Earth's =
rotation
means you have to use >1 station to upload some data to a spacecraft, =
but you
really want strict ingress controls on the long haul links involved. If =
you
take the PEP model, then that requirement could be met by having a =
single PDP
for all of the Earthstations and which is stateful where each of the =
PEPs
contacts the PDP to check if sending this fragment is ok or not. I'm not
entirely sure this is the way to go, but it may well offer benefits =
compared to
the current "get all the fragments back together" approach.

Susan: If I understand you, then for this to work, each Earthstation =
would have to provide the fragments that it receives to the PDP so the =
PDP could reassemble the payload, verify the PSH, and make the decision. =
I've got no problem with defining something like this. In the absence of =
such a scheme being defined, however, users need should be forwarned =
that unless they pin the bundle's route through the security policy =
router (using source routing), the security policy router could become a =
sinkhole.=20

21. Combining algorithms. We support either signatures or MACs. Could it =
happen
that an originator mightn't know which to use for a certain destination?
Usually there are a few corner cases where its hard to code this up =
correctly.
In that case, one might want the option to include both a signature and =
a MAC.
Personally though I wouldn't do that, its probably better to either =
stick to
one or else allow any number of independent authenticators (e.g. =
including two
MACs with successive keys can be useful during rollover periods, and =
then a
signature for middle boxes to check en-route). For now, I'd be ok with =
just a
single authenticator in a PSH and this can probably be ignored for BAH =
(though
if the delay is significant enough, the key rollover problem might hit =
MACs
occasionally).

Susan: I  prefer to stick with a single authenticator now also, but good =
to bring this up.  Do other protocols deal with rollover by allowing two =
authenticators, for example, to be included?

22. Using region-native security instead of BAH. This needs to be done a =
bit
differently. Firstly, to be useful, the interface would have to expose
something about how the region secured the bundle - there's a big =
difference
between WEP and IPSec! There may also be a need to expose some naming
information too, e.g. if regional security used SSL, then it may help to =
know
the name or other stuff from the client certificate if one was used. =
Secondly,
10.2 states the either the bundle has a good BAH or else it MUST have =
been
secured by the region, or else it MUST be discarded. This is wrong, even =
with a
"NULL security is ok for this region" modifier. Basically, BAH should be
optional, as would regional security and the router's PEP has to decide =
if the
presence or absence of these is required or not in each case. Finally, =
IPSec
VPNs unfortunately do not offer this information, esp. if the =
convergence layer
isn't in the kernel, so there's a big class of region security that can =
be used
but cannot really be asserted to have been used at this layer. (The fix =
here is
to push up the IP addresses & ports and for the PEP to have a synched-up =
view
of the IPSec rules. Ugly, but there ya go.)

Susan: Is it really required that we expose how the region secured the =
bundle?  Why is it inadequate to simply have the bundle layer rely on =
the assertion of security made by the convergence layer?

23. As an input for section 11: Some DTNs will have a bunch of really
challenged nodes at their edges (say sensors) and its only when you get =
off
that network that the next DTN router ("Alice") will have sufficient CPU =
etc.
to be able to add a PSH or BAH. I'd like this to be allowed, but =
currently the
PSH case seems to be prevented. There was some mention of treating this =
as a
VPN tunnel in Minneapolis, i.e. running bundling in bundling and then =
having
Alice add a PSH to the outer layer of bundling, but that'd mean there =
needs to
be another router ("Bob") who's expecting Alice to do this and who's =
going to
act as the other end of the tunnel. I don't think this works! What I'd =
like is
for Alice to be able to add a PSH and for the middleboxes and final =
destination
to be able to decide (via their PEPs) whether that's ok or not for this =
bundle.
There may also be cases where PSH validation would similarly be done at =
a
middlebox (say if revocation support is turned on) and the final =
destination is
in the sensor network.  This might also be a useful mechanism to support =
some
security for sort-of broadcast bundles, where we separately secure the =
bundle
up to the equivalent of the mail-list exploder and thereafter.

Susan: Ahhhhh! (not that I don't like the idea; it's just that =
everything keeps getting more and more complicated.) This is sort of =
like a "tunnel-mode" DTN security.=20

Itsy-bitsy things:
-----------------

Susan: I only responded to those comments below that I didn't understand =
or didn't generally agree with.=20

1. LTP and Bundling. I think this document is just addressing bundling. =
It
ought to be clear that LTP is out of scope here.  Having said that, at =
some
point we ought consider common features, esp. wrt key distribution - I =
see no
reason for that to differ between LTP and bundling - the inclusion of =
some sort
of "key purpose" field should be enough to allow handling both.

2. p4, mainly the last para. X.509 certificates already expire, I think =
you're
saying that short-lived certificates without revocation support may be a =
better
option than long-lived certificates + revocation.

3. s1.1, para1. I don't think the weakest link argument is that good for
networks these days, given the way we use firewalls/VPN-gateways and =
other
middleboxes. Nor is that text really needed - I'd rephrase the para. to =
say
that DTN security depends on region security which depends on =
intra-region
security which depends on host security...

4. s1.3, end. Is secure-DTN-muticast a bridge-too-far? Seems v. =
ambitious for
this round of work, though perhaps you need it for darpa purposes.

5. s1.4, if this is a standards track document, then this section ought =
to be
using MUST/MAY/SHOULD, but if its a snapshot, must etc. are fine.

6. s1.4, definition of "source": is this deliberately silent as to the
distinction between the "proper" source and a potential spoofer?  If =
not, then
"source" needs to be re-defined to be the originator of the bundle when =
first
transmitted or similar. I think I'd prefer that definition. Should we =
also give
name to an attacking network entity?

Susan: what terminology do you suggest?=20

7. s1.4: "refers to [3] and [8]" I prefer not to use this style myself, =
rather
"refers to the bundle protocol specification [3] and the (still TBD) =
bundle
protocol security specification [8]."

8. s1.4, last para: This seems to be somewhat circular, since we're =
motivating
security here by referring to the PDUs which are motivated by this. =
Maybe this
text really belongs in the TBD security protocol spec.

9. s2, 1st sentence: I'm a bit uneasy with language like this that =
implies that
we "include the capability to...prevent access by unauthorized =
applications" -
basically, since this is, in general, impossible! Restating this and =
others
along the lines of "include services and/or mechanisms which...aid in
preventing or detecting access by unauthorized applications" would be =
better
IMO.

10. s3: why are we providing an overview of services that are not =
provided?

Susan: I thought there was merit in being explicit about what is =
included and what is not included as part of the overview. Perhaps that =
can be done without saying as much about the services that aren't =
provided.

11. s3.1: Arguably, there is no such security service as "protection =
against
DoS" - the argument being that you cannot prevent or really protect =
against all
DoSes. Instead, we should aim to provide tools which can mitigate =
attempted
DoS. So item 4 in the list at the start of 3.1 isn't really right.

12. s3.1.1, 3rd list item: bundle integrity allows detection of =
modifications
which are not supposed to occur, not those which are.

Susan: I'm not sure I get your point.

13. s3.2: The name of this section is odd. Sticking to the "goals" too =
closely
perhaps.

14. s3.3, 1st sentence: Regardless of what we end up doing *some* DTNs =
might
well include a security service for replay detection, so the sentence as
currently written, is false.

15. Crypto key terminology. The terms "public" and "private" should only =
IMO be
used wrt asymmetric algorithms like RSA, for symmetric algorithms like =
AES,
using "secret" is better.  This is pretty much the normal usage.

15. Bundle integrity. The term as currently used is somewhat misleading. =
I
thought that it did include the payload even for the BAH. However, I now
realise it doesn't. If we keep this kind of protection, then we ought =
not refer
to it as bundle integrity but rather as bundle header integrity.

Susan: I see your point.  This is a terminology problem that has to be =
cleared up with the larger DTN group. Scott Burleigh alluded to it at =
the last meeting. Technically, there is no concept of a DTN bundle =
consisting of a bundle header and a payload (though that is the way we =
tend to think about it). A bundle is a collection of headers, and the =
payload is just a field in one of the bundle headers.

16. Section 4.3, says: "Therefore, if the private keys of all of the =
nodes
along the path from source to destination have not been compromised, =
then the
bundle (except its payload) sent along this path from source to =
destination can
be verified by the destination node not to have been modified while =
in-transit
on the path from source to destination." This is false. The missing =
clause is
something like "and if all the bundle agents are operating correctly, =
and
without cheating". Note that software integrity is not the only issue, =
since
sometimes people do include malicious code in the original software, =
either
accidentally, or perhaps more commonly, intentionally (e.g. spyware of =
the
various commercial or governmental types:-).

17. Section 4.3, last para: This restates the fallacy from nit #16.

18. Section 4.4.1 and elsewhere. The use of the phrase "decrypt the hash =
value"
isn't quite correct, for example with HMAC the key is prepended to the
to-be-MACed data and  CBC-residue schemes use the key for each
cipher-block-sized chunk of to-be-MACed data. In both cases, there is no =
stage
of calculation where there's an unkeyed digest. This isn't a problem for
someone used to MACs, signatures etc., but could mislead a naive reader. =
Better
to talk of MACing/signing and MAC/signature checking. If you simply =
explain
first time you say "sign" that you include both signatures and MACs then =
that's
ok (its also done in the xmldsig specifications for example).

19. Section 4.4, "If private key cryptography...", this is an example of =
where
you really ought say "If secret key cryptography..."

20. Section 4.5, correctly says that you cannot prevent DoS, but goes =
wrong in
some of the discussion. For example, stating that: "Without valid, =
current
keys, a secure network can be brought to a standstill" is misguided. In =
actual
fact, the use of cryptography enables new DoSes (flipping one bit kills =
the
entire protected block of bytes). I think the right thing to do is just =
state
the DoS cannot be prevented, but can be ameliorated, and certainly that
protocols can be designed to be more or less DoS resistant. There can be =
no
reason to argue that a DTN should be a priori less DoS resistant. (Ok, I =
can't
resist: "Despite how futile..." is probably worse than even my =
English:-)

21. Setion 4.5.3, 5th list element, says that signatures are more easily =

replayed which is true. However, this could be prevented by including
(a hash of) the recipient tuple within the signature. (Though note that
this isn't standard PKCS#1 padding, it has been done in the past.)
Basically, most signatures (esp RSA) involve values significantly larger
than the hash-OID+hash-Value which PKCS#1 block type 1 uses and =
therefore
contain a number of random bytes (from memory about 90+ bytes of
random data). There's plenty of room there to include an additional
digest or two!

Susan: You've lost me here.

22. Section 4.5.3, 6th list element. Its not really good to argue that =
DTNs are
both more replay resistant and harder-to-protect due to the extended =
lifetimes
of bundles. In particular, each replayed bundle has a magnified effect =
since
it'll perhaps persist in the network much longer than in non DTN cases.

23. Section 4.5.3, 6th list element. There are purely local ways in =
which a
node can protect itself (and not the DTN in general!) against replays. =
Simply
keep a replay cache of the digests of the inbound bytes, perhaps with
additional counts and timing information (though that's not ususally =
done).
The node can then tailor its response based on the replay status of the
incoming message. (Note that the bytes input to digesting can be =
ecverything
receieved or else some sensible subset, or even multiple subsets so that
different partial replays can be spotted and handled as such). The cost =
of
doing this is memory and CPU for digesting which is normally not that =
bad. The
hard part here is knowing when to flush the replay cache entries.  There =
are a
range of options,s can be spotted and handled as such). The cost of =
doing this
is memory and CPU for digesting which is normally not that bad. The hard =
part
here is knowing when to flush the replay cache entries.  There are a =
range of
options, e.g., simply bounding the cache by size, or else more complex =
schemes
which flush entries based on age and the number of replay occurrences, =
or
whatever. (Since this is not an interoperability issue, programmers can =
more or
less do what they like here.) Finally, if a number of such nodes can =
share
information about their individual replay caches then the network as a =
whole
can be given relative good protection. Again this can be done without =
impacting
the basic protocol except that the rules for what is and is not an =
unexpected
replay need to be figured out. (This one's probably not really a nit is =
it;-)

Susan: Are you suggesting that since each node can perform its own =
replay detection without impacting the protocol, that we should just =
leave it at that and not mention replay detection as part of the =
protocol? In other words, it's just something optional that a person =
administering a node can do if it occurs to him? (I'm just trying to =
understand what you are getting at.)

24. Section 4.5.3.1.1. Each bundle/fragment in the network is uniquely
identifiable - by running its bytes through a digest. See #23 above.

Susan: Isn't it a lot more overhead to run a bundle through a digest =
than simply look at the contents of a small number of its fields?

25. Section 4.5.3.1.2. This only works if the same keying material is in =
place
allowing the BAH to be validated in both destinations. While it might =
happen
for signatures, I'd expect MACing to be far more common for BAH. There's =
no
good reason to have the same symmetric key usable for validation at two
different routers.

25. Section 5, 1st sentence: As before (#16) this also requires that the =
DTN
nodes on the path don't cheat.

26. Section 5.2.1. The description here is a little wrong. The main =
problem
with originator key compromise is that you don't know where copies of =
the key
are now available, and therefore you don't get origin authentication.
Modifying the bundle in-flight is also possible, but less likely.

27. Section 5.2.2. I think its not really necessary to say things like =
this.=20

28. Section 5.3.1. Again, too many words. This could all have been said =
in
section 5.2.

29. Section 5.4. This has all been said already!

30. Section 6. Again I think this has all been said already.

31. Page 40, says: "A source may use the Source Routing Header to ensure =
that a
given bundle, and therefore all fragments that may result from that =
bundle,
will pass through one or more specified security policy routers en route =
to its
destination." The problem with this is that the "will" is really a =
"should"
since the header is asking for something and not enforcing it. So if =
there's a
bad node somewhere on the (DTN or intra-regional) path, it'll still =
cheat,
maybe by deleting both this header and the BAH, and it may still be able =
to
arrange a DoS on the "security policy router."

32. Page 40, last para: what's this doing in a section about security
policy routers?

Susan: Crashing the party.

33. Section 7. This was probably changed after Minneapolis. I'm not sure =
if its
worthwhile trying to keep it up-to-date or not. Maybe it'd be ok to move =
the
2nd para to an earlier section and then delete the section entirely.

34. Section 10.1. The list of algorithms isn't quite right. Using HMAC =
means
only having one algorithm for #2 and #3, and when using signatures given =
the
pkcs#1 padding scheme includes the hashing OID in the signature block, =
its
usual to call e.g. rsaWithSha1 a signature algorithm, rather than saying =
we're
using sha-1 and we're using rsa. Main thing though is that with MACing
constructs you usually can't separate #2 from #3 (nor #4 from #5).

Susan: When we write the protocol document we are going to have to come =
up with a header format that is versatile enough that it includes the =
appropriate fields as determined by the algorithms used. I hope you have =
a better idea how to do this than I do.

------=_NextPart_000_00D3_01C536B6.E34C1890--

Date: Fri, 01 Apr 2005 15:18:01 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-security] Re: Reference in DTN Security Overview and Motivation
Sender: [email-masked]
Reply-To: [email-masked]

Hi Howie,

I agree with you, but I think its even a little worse.

Firstly, PEM was an existence proof that rigidly binding
naming and key management hierarchies together is liable
to not scale. Assuming that all nodes in all DTNs will be
named to match some IBE scheme's hierarchal requirements
is IMO not wise at all.

And once there are multiple independent PKGs in the
universe then the encryptor has to map from the decryptor's
name to the relevant PKG parameter set (and I don't
believe that any current scheme allows arbitrary numbers
of independent PKGs to have the same parameter sets,
though I could be wrong there, if not now then maybe
in future).

So, you need a form of "domain-cert" in any case, which
maps something like an X.509 NameConstraint extension into
a PKG parameter set. That structure had better have
origin authentication and integrity or else a bogus
PKG can start decrypting intercepted messages. So, hey:
we probably need it to be signed.

And then, maybe it'll have to be revoked, say whenever
the relevant domain installs a new PKG with different
parameters. So the encryptor still has to do a status
check, i.e. get a CRL or equivalent.

The fact that the certificate involved covers an entire
domain could be useful for some applications, but only
where the encryptor is going to be sending encrypted
messages to many different entities in the target
domain within a single cache-period. (Given that many
IBE schemes attempt to avoid end entity revocation
by requiring the decrytor to re-contact the PKG
periodically, it may be the case that any such
"domain-cert" can also only be cached for a short
cache-period.) So I don't believe that this actually
helps that much, if at all, for many applications
but I guess it might for some.

Secondly, I also believe there would be issues with
nodes which move from one PKG-domain (whether hierarchical
or independent) to another, which would be more likely
in a DTN since you'll want to talk to your local PKG in
a relatively-non-delayed manner. I don't believe that
the IBE schemes currently handle this kind of thing at
all, though again, I'm open to being educated some more
here.

Thirdly, the mandatory-escrow aspect of IBE is an
extremely serious disadvantage. While some applications
and environments can live with key-escrow there was
(in response to the US clipper and other initiatives)
a clear concensus amongst at least IETF participants
that mandatory key escrow is not something to build into
your core protocols. (I no longer have a reference for
that list, but there was a raging debate a few years
ago on this and the concensus was overwhelming that
the IETF at least ought not go there. I don't believe
the outcome would differ were the debate to be had
now.)

Fourthly, while PKI has its problems, it does represent
a technology that's mature enough and well enough
understood that there are lots of folks available that
can figure out how to tweak it to satisfy DTN requirements.
(And there's code there too!) We also know how to do
things like register into PKIs and kerberos domains,
handle changing passwords and keys etc. none of which
are solved problems for IBE schemes. Basically, IBE is
still much more bleeding-edge compared to other key
management schemes.

For this last reason and others, there is I believe a
winning case to be made for requiring fleixibility in
how key management is done in DTNs. Though we will
need to define at least one specifc way to do key
management - which has IMO to be primarily aimed at
supporting interoperability (with lesser emphases
on other factors, like crypto-cuteness;-).

My own guess is that starting with a PKI or
kerberos-like approach is probably best, but I wouldn't
rule out someone else figuring out an IBE approach that
satisfies some niche at a later date. I'd note in passing
though that affording such flexibility means that no
"one-size-fits-all" scheme can work, and I believe the
IBE scheme proposed below is inherently a "one-size-
fits-all" scheme and I'm not sure if there is an existing
IBE scheme which doesn't have that property.

To summarise: I think IBE is cute and we ought to
encourage folks to work on how it might be applied
to DTNs (with the contstraint the it has to work as
one of possibly many key management approaches). However,
I don't believe we should depend on IBE, nor should we
wait for the development of a DTN-friendly IBE
scheme - we ought to press ahead and define a key
management scheme that can work in the nearer term
and we ought to focus on a scheme that'll promote
interoperability, perhaps even at the expense of
other traditionally required features of key management
schemes (and there's a separate discussion to be had
about that!).

Regards,
Stephen.

Howard Weiss wrote:

> Susan,
> 
> I went thru Rabin's paper and your comments.  Nothing I've seen so far 
> has changed my opinion regarding IBE - I don't think it solves anything 
> wrt DTN.  For example:
> 
> 1. On encrypting a transmission, the source gains a "win" by not having 
> to cache the destination's public key or consult a certificate 
> authority.  However, the source does have to cache the destination ID 
> information (which is presumably much smaller than a certifcate but 
> nevertheless, its infomation that somehow has to be arrived at and 
> cached).    The destination loses because its got to go to a PKG to get 
> a private key to match the source.  I guess the private key could be 
> cached but there is still a first time penalty.  Bottom line: a zero sum 
> gain.
> 
> 2. On signing, the sender has to obtain a private key for the 
> destination from a PKG or have the private key already cached.  The 
> destination "wins" by not having to consult with any server to 
> authenticate.  Another zero sum gain. 
> 
> One side wins at the expense of the other side.  This scheme seems like 
> it would work well if there are many encrypting sources but few 
> receivers.  The win is that the sources don't have to consult with any 
> servers (or use precious cache space) before sending.  But the 
> destination has to pay the piper because of the number of private keys 
> that have to be obtained or cached.
> 
> In either a PKI-like instantiation or an IBE-like instantiation, there 
> is still a trusted 3rd party server involved that must be consulted.  I 
> can envision ways in a PKI instantiation where there are no servers 
> (e.g., I only have a DTN CA cert and I need to talk to entity A so I 
> first send a "hello" to A and attach my public signed by the DTN CA; A 
> replies with "how are you" and sends its public, also signed by the DTN 
> CA back to me; now I can send something encrypted - costs one round trip 
> but does not involve an 3rd party server than could also be a single 
> point of failure).  I can't see how this could be done with IBE - at 
> least its not clear to me.
> 
> Just my 2 cents.
> 
> Howie
> 
> Susan F. Symington wrote:
> 
>> Howie,
>>  
>> I have attached the paper.  I had thought it was sent out in 
>> dtn-interest but I just checked and you are right, it was sent to me 
>> and two other people. You may want to mention to Kevin to tell Rabin 
>> to add you to his list so if he ever updates it, you will be included 
>> in the mailing. 
>>  
>> I am also attaching the comments that I sent back to Rabin. 
>>  
>> -susan
>>
>>     ------------------------------------------------------------------------
>>     *From:* Howard Weiss [mailto:[email-masked]]
>>     *Sent:* Monday, March 28, 2005 5:38 PM
>>     *To:* Susan F. Symington
>>     *Subject:* Reference in DTN Security Overview and Motivation
>>
>>     Susan,
>>
>>     I am going through your DTN security overview and motivation and
>>     came across a reference to a paper:
>>
>>     Patra, R.; "Using Identity Based Crytography for Security in
>>     DTNs," December 2004.
>>
>>     I haven't seen this - I have only heard Kevin allude to someone
>>     looking at IBE.  If you have it, can you send it to me?
>>
>>     Thanks,
>>
>>     Howie
>>
>>-- 
>>Howard Weiss
>>SPARTA, Inc.
>>7075 Samuel Morse Drive
>>Columbia, MD 21046
>>410.872.1515 x201
>>410.872.8079 (fax)
>>
>>    
>>
>>------------------------------------------------------------------------
>>
>>Using Identity based Cryptography for Security in DTNs
>>------------------------------------------------------
>>
>>This proposal describes an architecture based on Hierarchical Identity Based 
>>Encryption for providing security features in DTNs.
>>The aim is to provide confidentiality and integrity
>>for end-to-end communication as well as protection of the DTN 
>>infrastructure and efficient implementation of access control in a 
>>heterogeneous environment of hosts having varied connectivity.
>>
>>
>>The requirements for such a security architecture in DTNs are :
>>1> Implicit certification:
>>    This means that a source(A) should be able to encrypt and send a bundle to the
>>    destination(B) by using only B's public information such that B will be able
>>    to decrypt the message only if it is currently certified [9].
>>    Otherwise, senders will have to explicitly verify the current status of
>>    receivers (whether their public keys are still valid) from a third-party 
>>    trusted authority.
>>    - we also don't want senders to store for each possible destination either 
>>      a) a shared private symmetric key or b) a public key
>>    - third party certification queries may also be difficult in DTN like 
>>      heterogeneous environment where the server that has the ability to certify B 
>>      is in a different administrative region than A.
>>    - we also want to ensure that no single entity is forced to handle all 
>>      certification queries/requests - this will lead to overload and increased 
>>      latency for queries.
>>
>>2> Control over revocation over different time scales:
>>    Implicit certification eliminates the need for the sender to perform
>>    third-party certificate status queries. But in a DTN heterogeneous 
>>    environment where hosts with different levels of vulnerability might
>>    exist, we also want allow the system ( or the certificate
>>    authorities) to choose between between fine grained or coarse grained
>>    revocation for each host.
>>    i.e if a user is more trusted, the system might want to re-certify
>>    keys only every month as opposed to doing it every day.
>>    
>>
>>3> Authentication for infrastructure access control:
>>    As already suggested in [1], bundles should carry two headers i.e PSH that
>>    is signed by the original source, and BAH that is signed at each hop by the
>>    sender router.
>>    Thus we need two different types of authentication mechanisms:
>>    Router authentication (in BAH): This is used by routers to authenticate
>>      the previous hop routers. Every router might have its own specific access
>>      control policy for each router it interacts with. 
>>      Though this implies that it needs to be aware of their identities,
>>      it can be feasible as the routers might need to know only their 
>>      immediate neighbors in the DTN.
>>    Source authenticating (in PSH): 
>>     - This is used for end-to-end integrity of the bundles.
>>     - It is used by the destination host for authentication of the source of bundle.
>>     - It can also used by routers for global policy access control using 
>>       the identity of source endpoints. As routers cannot be
>>       possibly be aware of all the sources in the world, it would make more sense
>>       if these rights are encoded in the credentials (or a certificate)
>>       presented by the source along with the bundle.
>>       For example, if a source is given permission to send all its traffic 
>>       in the 'Urgent' class by the system, the all routers need to support this. 
>>     - Instead of using certificates (which can be long)  for encoding the 
>>       rights of the source, we want these rights to be encoded in the 
>>       identity of the source endpoint. 
>>       Then a successful authentication of the identity of the 
>>       source should mean that source has obtained that particular identity
>>       from the system.
>>       For example: A source 'A' possessing 'Urgent' class  would have the
>>       identity 'A.Urgent'. We need to make sure that these identities can
>>       only be provided by the system and cannot be forged by some adversary.
>>     - This would also mean that identities of would have to be part of the
>>       bundle in the PSH.
>>        
>>4> Complex access control policies:
>>    As DTNs can conceivably have multiple classes of service,
>>    we need efficient ways to represent more complex access control policies.
>>    One way is to support policies over simple boolean expressions.
>>    For example: for source A: Urgent OR Bulk class traffic.
>>      
>>
>>Assumptions and Threat Model:
>>-----------------------------
>>1> The DTN can have global access control policies that need to recognized by
>>   all routers in all administrative regions. However routers can have their
>>   own specific access control policies. (it is not clear if these should be
>>   allowed to override the former).
>>2> There is a set of trusted servers in the DTN that cannot be compromised by 
>>   adversaries. These servers will be used for key issuance, management and
>>   revocation.
>>   Other hosts (including routers) in the DTN can be compromised.
>>3> Adversaries can eavesdrop on all traffic, they can capture bundles 
>>   and also modify in flight bundles.
>>
>>
>>Types of Attacks:
>>1> Routing level attacks : Adversaries on compromising routers can
>>   can change routing entries to create routing dead-ends or loops.
>>2> Infrastructure level attacks: Adversaries can try to access the DTN 
>>   infrastructure without authorization. 
>>   They can try to flood the network or send bundles with 
>>   classes of service that are not allowed.
>>3> Data level attacks: Adversaries can eavesdrop on traffic and try to compromise 
>>   the confidentiality and integrity of the bundles in the DTN. 
>>   They can replay bundles.
>>
>>
>>    
>>Proposal:
>>---------
>>The basic proposal is to use a combination of Hierarchical Identity based
>>encryption (HIBE) and signatures (HIBS).
>>
>>
>>IBE in brief:
>>    An Identity Base Encryption (IBE) scheme is a public-key cryptosystem where 
>>    any string is a valid public key. In particular, email addresses and dates
>>    can be public keys.
>>    When Alice sends mail to Bob at [email-masked] she simply encrypts her 
>>    message using the public key string [email-masked]''. There is no need for
>>    Alice to obtain Bob's public key certificate. When Bob receives the 
>>    encrypted mail he contacts a third party, the Private Key Generator (PKG), 
>>    Bob authenticates himself to the PKG in the same way he would authenticate 
>>    himself to a CA and obtains his private key from the PKG.
>>
>>    IBE scheme consists of four algorithms: 
>>    (1) Setup: The PKG generates global system parameters and a master-key.
>>        The global system parameters need to be distributed to all hosts
>>        initially.
>>    (2) Extract: The PKG uses the master-key to generate the private key 
>>        corresponding to an arbitrary public key string ID, 
>>    (3) Encrypt: Source(A) encrypts messages using the public key ID of the
>>        destination, B.
>>    (4) Decrypt: B decrypts messages from A using the corresponding private key 
>>        that it obtained from the PKG.
>>    
>>    IBE has been proven to be secure against chosen cipher-text attacks in the 
>>    random oracle model.
>>    For more details please refer to [7]
>>    
>>    IBE based signatures schemes have also be proposed where the source can
>>    sign using its private key and the signature can be verified using the
>>    public ID string.
>>    
>>Hierarchy IBE [9] in brief:
>>    The main problem of plain IBE where the single PKG has to issue private
>>    keys for all users is mitigated by creating a hierarchy of PKGs.
>>    Hierarchy is established in the form of a tree where each 
>>    (and root) node can be a separate PKG.
>>    The identity of a particular node at level t is given by its 
>>    ID-tuple (ID1,ID2..IDt) where  ID_i corresponds to the i-th level node.
>>    For key extraction, each PKG(root or lower level one) at level t may
>>    obtain the private keys for its immediate children with ID tuple
>>    (ID1,ID2..IDt,ID_t+1).
>>    Encryption and decryption proceed similarly as IBE and the ID Tuple is used
>>    as the public key.
>>    Similar scheme can be developed for Hierarchical IB Signatures.
>>    It is also proven that HIBE is secure against collusion among lower level
>>    PKG servers.
>>
>>Bundle Transmission:
>>1> The source first uses the destination node's public ID string to encrypt
>>   the bundle. This cipher-text forms the payload of the bundle.
>>2> The PSH is then created over the payload and header (with appropriate
>>   fields zeroed out) by signing with the 
>>   source endpoint ID ( that encapsulates the requisite access control permissions).
>>   The integrity can be verified and the source identity can be 
>>   authenticated by all routers.
>>   This was one of the features desired in [1] (point 12). 
>>3> The BAH is created at each hop by the sending router. This can be done
>>   using some other cryptographic scheme (symmetric or assymmetric) also.
>>
>>Now lets see how the different requirements specified are solved:
>>1> Implicit certification:
>>    As is clear from the basic definition of IBE, a source need not know the
>>    public key of the destination before sending a bundle. 
>>    The burden of ensuring updated certification now rests on the 
>>    destination that now has to obtain the current valid private key 
>>    to be able to decrypt a received bundle.
>>
>>2> Use of hierarchy:
>>    This offers us two advantages:
>>    a> Efficient key distribution: Normal IBE has only one PKG server which 
>>      possesses the master key. This PKG is responsible for extracting private
>>      keys of all the users of the system. 
>>      By using hierarchy - a) we can first place local PKGs in every region so that
>>      destination nodes dont have to go far to get their private keys and
>>      also b) compromise of a lower level PKG does not compromise the whole
>>      system (as the master secret resides with the root PKG only).
>>      The naming scheme in HIBE also derives naturally from the naming in the DTN 
>>      architecture where the endpoint address consists of two parts - region
>>      ID and the region-specific ID.
>>      For example: if the endpoint address for Bob is 'bundles://Earth/Bob_IP', then
>>      a PKG can be placed on Earth with ID:'Earth'. For larger regions, we can
>>      further create more levels in the hierarchy.
>>
>>    b> Revocation control: 
>>      We do this by creating a sub-hierarchy for each host (in addition to the
>>      hierarchy over multiple PKGs created for key distribution). 
>>      The levels in this sub-tree would reflect the degree of control desired
>>      for revocation. Senders will use the ID tuples corresponding to the
>>      leaves of this tree for encryption.
>>      As this sub-tree is completely located at a particular
>>      host, the host can act as a PKG and extract private keys for this tree 
>>      on its own. We can control the leaves for which the host is able to generate
>>      private keys for itself by providing it private keys for only selected
>>      internal nodes of this tree.
>>      For example: the first level could be month, the second level date and 
>>       the third level: hour. Then the ID of a user Bob (in region Earth) would be
>>       Earth.Bob.May.24.12pm . 
>>       - The Earth region PKG can extract private keys for all IDs of the form 
>>         'Earth.*'. The Earth PKG can then choose to give Bob the private key 
>>         for 'Earth.Bob' if Bob is a highly trusted user. Now Bob can generate all 
>>         keys of the form 'Earth.Bob.<month>.<date>.<hour>. 
>>       - A less trusted user 'Alice' will be given the private key for
>>         'Earth.Alice.Nov' only - this will allow Alice to read messages only for
>>         month of November. For a bundle encrypted with the full ID string
>>         Earth.Alice.Nov.25.12pm, Alice will be forced to ask a new private
>>         key every hour.
>>       - For more paranoid uses, an extra level of the this tree could be a
>>         random ID. This would force the receiver to acquire a new private key
>>         for each bundle it receives. A sender can now encrypt the bundle 
>>         with 'Earth.Alice.Nov.25.12pm.<random_id>'.
>>       - A sender that wishes lower security( and lower latency) for a
>>         session can now encrypt it with 'Earth.Alice.Nov.25.12pm.0000', and Alice
>>         would have to go to the Earth PKG only once to decrypt this bundle.
>>      In general, the PKG server responsible for a user needs to compute a
>>      subset cover over the user subtree i.e the minimum set of nodes that cover
>>      all the IDs that are allowed and none of the IDs that are not allowed
>>      for that user. Then it needs to extract private keys for only those
>>      nodes in the subset cover.
>>      
>>    c> Fine grained access control:
>>     A similar scheme as above can be used for forming ID strings needed for
>>     authentication and access control as well.
>>     For this source users sign the bundles with the correct privilege
>>     desired. For example, if Alice desires 'Urgent' class of service, it will
>>     need to sign the bundle with the identity 'Alice.Urgent'. For this it
>>     needs to possess the private key corresponding to 'Alice.Urgent'. 
>>     Possession of a private key corresponding to an identity
>>     implies that the system also authorized you for the rights that are
>>     associated with that identity.
>>     This is possible in IBE because all private keys are generated by the PKGs.
>>     The same hierarchical ID structure can be used for revocation and
>>     granting of rights as well. The subtree below each host
>>     would now represent different privileges.
>>     For example: A highly valuable Bob can be given access to all classes
>>      of service by providing the private key for 'Earth.Bob.Nov.25' - Bob can
>>      then generate keys for 'Earth.Bob.Nov.25.Urgent' etc and use them for
>>      signing his bundles.
>>      A less valuable 'Alice' will only be given the private key for
>>      'Earth.Alice.Nov.25.Bulk'.
>>     However this mechanism requires the ID string to be included
>>     in the bundle header(PSH) for routers to use the correct key
>>     for authentication.
>>     This issue was raised in [1] as well for key rollover.
>>     This overall method of encoding the permissions of the user in the ID
>>     string is very similar to using accompanying certificates in traditional PKI.
>>
>>Why not PKI?:
>>-------------
>>1> Implicit certification is not possible as a source host is forced to 
>>   first acquire the identity(public key) of the destination before sending
>>   any bundle. It is also forced to check
>>   whether the destination is currently certified or not by making third-party
>>   queries.
>>2> Revocation is made much difficult in DTN and solutions like maintaining 
>>   a Certificate Revocation List(CRL) does not work for DTNs.
>>
>>Other issues and Disadvantages:
>>-------------------------------
>>1> Key escrow: 
>>    In IBE, the PKG can generate private keys for all users and thereby decrypt
>>    bundles destined for all users. This may not be always desirable.
>>    A related property is 'non-repudiability' which means that a receiver can
>>    prove that only the sender could have signed the bundle.
>>    Also, the compromise of the root PKG jeopardizes the entire system
>>    and all messages that were sent in the past.
>>
>>2> Standards issue:
>>    Since we try to encode revocation control(date etc) and access control
>>    identifiers in the ID strings, all entities in the DTN need to agree on a
>>    common format. This is similar to the problem faced in traditional PKI
>>    over the format of certificates.
>>    
>>3> Distribution of private keys:
>>    Since users ask the PKGs to generate private keys, they have to be transmitted 
>>    securely from the PKGs. This might mean that the PKGs share another key
>>    with every user just for the purpose of sending private keys.
>>
>>5> Distribution of system wide public parameters
>>    An IBE system installation needs to bootstrap all hosts with
>>    the public system parameters of the PKG. 
>>    This also might need to be updated if the root PKG is compromised.
>>
>>6> Replay attacks:
>>    Although we guarantee confidentiality and integrity, we do not have any
>>    mechanism to detect and handle replay attacks.
>>    
>>Other options and optimizations:
>>--------------------------------
>>1> Use of Certificate Based Encryption [8]:
>>   The 'key escrow' problem can be solved by using this variation where users
>>   are allowed to generate their own private keys.
>>   Senders are now able to user long lasting public keys without the need
>>   to worry about the current certification status of the destinations.
>>   This also solves the problem of securely delivering extracted private keys
>>   to each user.
>>2> Reducing overhead of using hierarchical IBE:
>>    Normal HIBE, both the length of signatures and the number of steps required
>>    for encryption are proportional to the number of levels in the ID tree.
>>    Some techniques based on the BGLS aggregated signature scheme can be used
>>    to reduce the decryption complexity.
>>3> If non-repudiability is not desired, them the scheme proposed in [10] can be
>>   used. Here the the MAC for authentication is same as the cipher-text for 
>>   encryption. It also uses the same public IDs and private keys as the standard
>>   scheme. So we can get both authentication(+integrity) and secrecy with
>>   little extra cost.
>>
>>
>>Implementation in DTN2 :
>>-----------------------
>>1> What are the basic building blocks that need to be supported in the DTN2
>>   architecture.
>>2> User management: [1] suggested that the DTN agent cannot possess the
>>   private keys. Applications should store the keys and call external
>>   entity to perform the encryption. 
>>
>>
>>
>>
>>
>>
>>References:
>>-----------
>>[1] Email correspondence on the dtn-interest mailing list
>>[2] Draft: "Identity based Encryption for Delay Tolerant Networks"
>>    A. Chakrabarti and K Fall.
>>    summary: proposes the use of IBE for both confidentiality as well
>>    as access control management in DTNs.
>>[3] Draft: "A Secure Tetherless Computing Architecture" by S.Keshav et al.
>>    summary: proposes a hierarchy of PKGs using HIBE and HIBS for efficient
>>     key management in the TCA.
>>[4] "Exploiting Hierarchical IBE for Access Control to Pervasive Computing
>>    Information"
>>    Urs Hengartner and Peter Steenkiste
>>    summary: proposes use of HIBE for both "encryption-based" and
>>     "proof-based" access control for client-server interactions.
>>     More emphasis on preventing leakage of information about access control
>>     policies
>>[5] "Hidden Credentials" 
>>    
>>    summary: use of IBE for hidden credential trust negotiation.
>>[6] "Identity based signatures"
>>    Paterson
>>    summary: one scheme for signatures based on the Boneh/Franklin scheme.
>>[7] "Identity based Encryption based on the Weil Pairing"
>>    Boneh and Franklin
>>    summary: this introduces the first concrete IBE scheme.
>>[8] "Certificate-Based Encryption and the Certificate Revocation Problem" 
>>    Craig Gentry
>>    summary: this talks about mitigating problems in IBE by proposing
>>     Certificate based Encryption(CBE) in which users can choose their own
>>     private key.
>>[9] "Hierarchical ID based Cryptography"
>>    Gentry and Silverberg
>>    summary: this extends the Boneh/Franklin IBE scheme 
>>[10]"Authenticated Identity-based Encryption"
>>    Ben Lynn
>>    summary: extends the Boneh/Franklin scheme to provide integrity of the
>>     message being encrypted.
>>      
>>
>>
>>  
>>
>>------------------------------------------------------------------------
>>
>>Rabin,
>>
>>Thank you very much for sending me your draft proposal for using IBE for security in DTNs. I appreciate having the opportunity to review it. There are a lot of good things in this paper. Of course, I won't be dwelling on them in my comments, it being the nature of comments to focus on areas that could be improved or clarified. I just want to make clear that my general reaction is very positive before I start pointing out areas that got me thinking.
>>
>>1. In your "Requirements" section, it seems to me that you have an additional implicit requirement that you really should make explicit, and that is the reuqirement of "Implicit public key distribution". This may seem obvious to someone who has been immersing himself in papers on IBE, but for the rest of us it is a novel concept, and I don't think it should be conflated with the concept of "implicit certification" as it now seems to be. By "Implicit public key distribution" I mean the ability of a user to derive the public key of an arbitrary user from some known information, such as his identity, thus eliminating the need for the user to obtain the public key from a third-party. I think your proposal would be more clear if you were to explicitly list "implicit public key distribution" (or whatever you choose to call it) as a separate requirement. It would also help to clarify the essence of "implicit certification", which is to addresses the issue of how a user who uses a
 p
>>ublic key derived from known information can be sure that the public key is still valid. The concept of getting the public key is separate from the concept of determining that the public key is still valid, and they should be treated as separate concepts. 
>>
>>2. Also in the "Requirements" section (#3, Authentication for Infrastructure access control) you say that you want the source's rights (permissions) to be encoded in  the identity of the source endpoint. But the permissions that are being requested are already encoded in the COS field. It seems a waste to also put the COS information in the source ID field. If the public key that is necessary to authenticate the bundle signature consists of a standard string composed of:
>>source endpoint id.COS.day/month/year/time(depending on granularity desired) then there is no need to put the COS information in the source ID field. 
>>By using the COS field as part of the public key encoding, you would have a straightforward mapping between the public key used both to authenticate the bundle and to thereby certify the right of the source to use this class of service, and the class of service rights that the bundle is requesting. This way, only the source ID and the validity period need be encoded in the source ID field. (Also, you may want to consider having the validity period encoded in a separate field of the bundle header rather than encoding it as part of the source ID field.) 
>>
>>3. In your section with the heading "Assumptions and Threat Model:" you have an aside stating that it is not clear if a given router's own specific access control policy should be allowed to override the global DTN access control policies that need to be recognized by all routers. My opinion is that a given router's own access control policy should be allowed to be more restrictive than the global access control policy, but it should not be allowed to be less restrictive than the global access control policy. In other words, all routers should be able to depend on all DTN bundle agents to enforce a given level of access control in determining what traffic they admit to the DTN from DTN applications; if a given router wants to be more restrictive on a given link within the DTN, that's its prerogative, and it should be able to do so (in fact, as I see it, the ability to be more restrictive is the whole point of having security policy routers). 
>>
>>4.In the "Types of Attacks" section you mention that adversaries may create routing loops. It should be noted that this is a problem that we have not yet addressed. Right now we don't have a way in the protocol to detect such an attack, and we don't really plan to be able to detect replays, so it isn't clear if or how we are planning to address this threat.
>>
>>5. In the "Bundle Transmission" section, step 2 does not make sense to me, and I think it may be an error that needs correcting. You say that the PSH is signed with the source endpoint ID. Don't you mean that it is signed with the PRIVATE KEY that corresponds to the source endpoint ID (and, if you accept my suggestion in item 2 above, it would be the private key that corresponds to the string formed by "source endpoint ID.COS.validity_time_period")? Then, any receiver can authenticate the source identity and its permissions by using the public key that is derived from the source endpoint id (or that may be exactly the source endpoint ID). 
>>
>>It should be noted (assuming I am understanding it correctly) that for any given validity time period, a single source may need to have as many as n private keys, where n is the number of different classes of service that can be represented. 
>>
>>6. In the "Bundle Transmission" section, step 3 surprises me. Don't you want to make a suggestion about how the BAH should be authenticated, or are you just leaving this for a later paper? If you are going to leave it out, which would be fine, then you should probably go back and refocus the paper to make it clear that you are really "only" addressing the end-to-end confidentiality and integrity security features of DTNs as provided by the PSH and "efficient implementation of access control in a heterogeneous environment of hosts ..." as provided by the PSH, but that discussion of infrastructure protection isn't within the scope of this paper.
>>
>>7. In your "Now lets see how the different requirements specified are solved:" section, you don't step through all the requirements that you originally proposed. This sort of thing causes those of us who are obsessive compulsive to develop all sorts of ticks and twitches. Addressing each requirements as it was originally raised would give readers like me just the sort of false sense of security that I need to sleep well at night. 
>>
>>8. In item 1 (Implicit certification) of the "Now lets see how the different requirements specified are solved:" section, you say that "a source need not know the public key of the destination before sending a bundle".  I think you really mean two things (and this goes back to my suggestion that you separate the concepts of key distribution from key certification).  I think you mean:
>> a) a source need not "look up" (as opposed to "know") the public key of the destination, and
>> b) a source need not obtain a destination's certification status before sending encrypted data to the destination as the bundle payload.
>>
>>9.In the "b> Revocation control:" section, it is worth noting (if I understandthe proposal correctly and completely) that the revocation mechanism being used is key expiration. There is no way to explicitly invalidate or revoke a private key from a user at an arbitrary time, once the key has been given to the user. Therefore, if a user Alice has been given a private key corresponding to the public key "Alice.October", this key will continue to work  through midnight on October 31, even if this key is compromised on October 1. For 30  more days, sources sending to Alice will encrypt bundle payload destined for Alice and send it to her thinking that its confidentiality is being protected even though it isnt. Therefore, the selection of the duration of a key's validity time period is an important choice and it would be good to make this clear to the reader. 
>>
>>Also, it isn't clear what the relationship is between the key's validity time period and the current real-world time. Is this relationship checked at the sender or at the recipient, or both? And how exactly is it checked?  For example,
>>If the current month is March, will a sender be allowed to encrypt a bundle that is being sent to Alice using the public key Alice.April? How about using the public key Alice.February? 
>>It seems that if the current month is March, senders should not be allowed to encrypt a bundle that is being sent to Alice using the public key Alice.February because the Alice.February key has expired and therefore it cannot be assumed to be safe to use it. 
>>
>>If Alice receives a bundle in the month of April but the bundle had been encrypted during the previous month, with the Alice.March key (which may very well happen in DTN), then what should Alice do? If she has cached the Alice.March key, then she will be able to decrypt the message, but should she? is her private key still valid?
>>
>>In other words, validity time periods may be such that a message that is sent during a validity time period will not be received until after that period is over. How should this be dealth with?  
>>
>>10. In the "Why not PKI?:" section, I am not convinced by your argument that the IBE scheme is better than the PKI scheme because when using PKI, the source host is forced to check whether the destination is currently certified or not by making third-party queries before it can send an encrypted bundle to the destination. (This is related to my comment in 9 above.) In a PKI scheme, when a source receives a destination's public key from the CA, can't that key come with a validity period, that says the key is good for the month of October, for example, and then it expires after that. If so, the source would not have to check the validity of that key before using it anytime during the month of October. The result is very similar to the result you get when using the IBE scheme using the sub-hierarchy scheme that corresponds to the month/day/hour of validity. In this respect, I don't see how the IBE scheme is any better than a PKI scheme that issues keys with validity time peri
od
>>s. Am I missing something? Both schemes seem to suffer from the fact that explicit revocation is not possible, making it impossible to revoke a certificate before its intended expiration date. At least in the PKI scheme it would be possible for a sender to query the CA to inquire whether the public key is still valid. There does not seem to be any analogous way for a sender using IBE to make such a query. To be safe, the user would have to use a random ID field in the ID string, in effect requiring a new public key to transmit each bundle (and therefore a new private key to decrypt each bundle). Distribution of the private key from the PKG to the DTN node is a not without its costs. Is there really an advantage to IBE over PKI in the respect that you mention in this section and, if so, can you please state it more clearly?
>>
>>11. In general, the paper would benefit if you were to make a more clear separation between the use of (and benefits of using) IBE for encrypting data versus for authenticating data, because those two operations are essentially the inverse of each other and they may be performed simultaneously on a given bundle sent in DTN. If the application data unit is encrypted and the bundle is signed using the PSH, then it isn't clear how the necessary public key and key validity information for both keys would be conveyed from source to destination. Your proposal talks of using the source ID field to convey the information necessary for the recipient to obtain the public key required to verify the bundle's PSH signature. How would the recipient know how to obtain the appropriate private key that it would also need to decrypt the application protocol data unit (APDU)? For example, if I understand your proposal correctly:
>>
>>On a bundle sent from Bob to Alice:
>>
>>Bob encrypts the APDU using the public key Alice.October and
>>Bob signs the bundle (in the PSH) with the private key corresponding to Bob.October.25.Urgent
>>
>>Upon receipt of the bundle, Alice would first use the public key Bob.October.25.Urgent to verify the signature in the PSH. Assuming the signature verified correctly, Alice would now get from her PKG (if she doesn't already have it) the private key corresponding to Alice.October and use it to decrypt the APDU.
>>
>>According to your proposal, the source ID has the information "Bob.October.25.Urgent" in it, so this is how Alice knows what public key to use to verify the signature in the PSH. How does Alice know that she needs the Alice.October private key (as opposed to the Alice.October.25 private key) to decrypt the APDU?  Is this string merely put into a new encryption keyID field that is carried in the bundle header?
>>
>>12. I hope IBE really woudl be secure in a DTN application and that that it will stand up to the test of time and increased scrutiny. It seems to be a genuine breakthrough that lots of folks have latched onto, but I don't feel qualified to make a judgement on its technical merits. Given that it hasn't had the scrutiny of PKI, I think it's important that DTN be designed so that it will work with both PKI and IBE. We need to be careful to define the protocols so that they don't have any hidden dependencies on the use of IBE.
>>
>>13. What about implementing IBE. Are there any implementations readily available that can be used with DTN2 or will this be something that will require a lot of development?
>>
>>Again, thanks for the opportunity to review this. I hope my comments help.
>>
>>-susan
>>
>>***********************************************************************
>>
>>Using Identity based Cryptography for Security in DTNs
>>------------------------------------------------------
>>
>>This proposal describes an architecture based on Hierarchical Identity Based 
>>Encryption for providing security features in DTNs.
>>The aim is to provide confidentiality and integrity
>>for end-to-end communication as well as protection of the DTN 
>>infrastructure and efficient implementation of access control in a 
>>heterogeneous environment of hosts having varied connectivity.
>>
>>
>>The requirements for such a security architecture in DTNs are :
>>1> Implicit certification:
>>    This means that a source(A) should be able to encrypt and send a bundle to the
>>    destination(B) by using only B's public information such that B will be able
>>    to decrypt the message only if it is currently certified [9].
>>    Otherwise, senders will have to explicitly verify the current status of
>>    receivers (whether their public keys are still valid) from a third-party 
>>    trusted authority.
>>    - we also don't want senders to store for each possible destination either 
>>      a) a shared private symmetric key or b) a public key
>>    - third party certification queries may also be difficult in DTN like 
>>      heterogeneous environment where the server that has the ability to certify B 
>>      is in a different administrative region than A.
>>    - we also want to ensure that no single entity is forced to handle all 
>>      certification queries/requests - this will lead to overload and increased 
>>      latency for queries.
>>
>>2> Control over revocation over different time scales:
>>    Implicit certification eliminates the need for the sender to perform
>>    third-party certificate status queries. But in a DTN heterogeneous 
>>    environment where hosts with different levels of vulnerability might
>>    exist, we also want allow the system ( or the certificate
>>    authorities) to choose between between fine grained or coarse grained
>>    revocation for each host.
>>    i.e if a user is more trusted, the system might want to re-certify
>>    keys only every month as opposed to doing it every day.
>>    
>>
>>3> Authentication for infrastructure access control:
>>    As already suggested in [1], bundles should carry two headers i.e PSH that
>>    is signed by the original source, and BAH that is signed at each hop by the
>>    sender router.
>>    Thus we need two different types of authentication mechanisms:
>>    Router authentication (in BAH): This is used by routers to authenticate
>>      the previous hop routers. Every router might have its own specific access
>>      control policy for each router it interacts with. 
>>      Though this implies that it needs to be aware of their identities,
>>      it can be feasible as the routers might need to know only their 
>>      immediate neighbors in the DTN.
>>    Source authenticating (in PSH): 
>>     - This is used for end-to-end integrity of the bundles.
>>     - It is used by the destination host for authentication of the source of bundle.
>>     - It can also used by routers for global policy access control using 
>>       the identity of source endpoints. As routers cannot be
>>       possibly be aware of all the sources in the world, it would make more sense
>>       if these rights are encoded in the credentials (or a certificate)
>>       presented by the source along with the bundle.
>>       For example, if a source is given permission to send all its traffic 
>>       in the 'Urgent' class by the system, the all routers need to support this. 
>>     - Instead of using certificates (which can be long)  for encoding the 
>>       rights of the source, we want these rights to be encoded in the 
>>       identity of the source endpoint. 
>>       Then a successful authentication of the identity of the 
>>       source should mean that source has obtained that particular identity
>>       from the system.
>>       For example: A source 'A' possessing 'Urgent' class  would have the
>>       identity 'A.Urgent'. We need to make sure that these identities can
>>       only be provided by the system and cannot be forged by some adversary.
>>     - This would also mean that identities of would have to be part of the
>>       bundle in the PSH.
>>        
>>4> Complex access control policies:
>>    As DTNs can conceivably have multiple classes of service,
>>    we need efficient ways to represent more complex access control policies.
>>    One way is to support policies over simple boolean expressions.
>>    For example: for source A: Urgent OR Bulk class traffic.
>>      
>>
>>Assumptions and Threat Model:
>>-----------------------------
>>1> The DTN can have global access control policies that need to recognized by
>>   all routers in all administrative regions. However routers can have their
>>   own specific access control policies. (it is not clear if these should be
>>   allowed to override the former).
>>2> There is a set of trusted servers in the DTN that cannot be compromised by 
>>   adversaries. These servers will be used for key issuance, management and
>>   revocation.
>>   Other hosts (including routers) in the DTN can be compromised.
>>3> Adversaries can eavesdrop on all traffic, they can capture bundles 
>>   and also modify in flight bundles.
>>
>>
>>Types of Attacks:
>>1> Routing level attacks : Adversaries on compromising routers can
>>   can change routing entries to create routing dead-ends or loops.
>>2> Infrastructure level attacks: Adversaries can try to access the DTN 
>>   infrastructure without authorization. 
>>   They can try to flood the network or send bundles with 
>>   classes of service that are not allowed.
>>3> Data level attacks: Adversaries can eavesdrop on traffic and try to compromise 
>>   the confidentiality and integrity of the bundles in the DTN. 
>>   They can replay bundles.
>>
>>
>>    
>>Proposal:
>>---------
>>The basic proposal is to use a combination of Hierarchical Identity based
>>encryption (HIBE) and signatures (HIBS).
>>
>>
>>IBE in brief:
>>    An Identity Base Encryption (IBE) scheme is a public-key cryptosystem where 
>>    any string is a valid public key. In particular, email addresses and dates
>>    can be public keys.
>>    When Alice sends mail to Bob at [email-masked] she simply encrypts her 
>>    message using the public key string [email-masked]''. There is no need for
>>    Alice to obtain Bob's public key certificate. When Bob receives the 
>>    encrypted mail he contacts a third party, the Private Key Generator (PKG), 
>>    Bob authenticates himself to the PKG in the same way he would authenticate 
>>    himself to a CA and obtains his private key from the PKG.
>>
>>    IBE scheme consists of four algorithms: 
>>    (1) Setup: The PKG generates global system parameters and a master-key.
>>        The global system parameters need to be distributed to all hosts
>>        initially.
>>    (2) Extract: The PKG uses the master-key to generate the private key 
>>        corresponding to an arbitrary public key string ID, 
>>    (3) Encrypt: Source(A) encrypts messages using the public key ID of the
>>        destination, B.
>>    (4) Decrypt: B decrypts messages from A using the corresponding private key 
>>        that it obtained from the PKG.
>>    
>>    IBE has been proven to be secure against chosen cipher-text attacks in the 
>>    random oracle model.
>>    For more details please refer to [7]
>>    
>>    IBE based signatures schemes have also be proposed where the source can
>>    sign using its private key and the signature can be verified using the
>>    public ID string.
>>    
>>Hierarchy IBE [9] in brief:
>>    The main problem of plain IBE where the single PKG has to issue private
>>    keys for all users is mitigated by creating a hierarchy of PKGs.
>>    Hierarchy is established in the form of a tree where each 
>>    (and root) node can be a separate PKG.
>>    The identity of a particular node at level t is given by its 
>>    ID-tuple (ID1,ID2..IDt) where  ID_i corresponds to the i-th level node.
>>    For key extraction, each PKG(root or lower level one) at level t may
>>    obtain the private keys for its immediate children with ID tuple
>>    (ID1,ID2..IDt,ID_t+1).
>>    Encryption and decryption proceed similarly as IBE and the ID Tuple is used
>>    as the public key.
>>    Similar scheme can be developed for Hierarchical IB Signatures.
>>    It is also proven that HIBE is secure against collusion among lower level
>>    PKG servers.
>>
>>Bundle Transmission:
>>1> The source first uses the destination node's public ID string to encrypt
>>   the bundle. This cipher-text forms the payload of the bundle.
>>2> The PSH is then created over the payload and header (with appropriate
>>   fields zeroed out) by signing with the 
>>   source endpoint ID ( that encapsulates the requisite access control permissions).
>>   The integrity can be verified and the source identity can be 
>>   authenticated by all routers.
>>   This was one of the features desired in [1] (point 12). 
>>3> The BAH is created at each hop by the sending router. This can be done
>>   using some other cryptographic scheme (symmetric or assymmetric) also.
>>
>>Now lets see how the different requirements specified are solved:
>>1> Implicit certification:
>>    As is clear from the basic definition of IBE, a source need not know the
>>    public key of the destination before sending a bundle. 
>>    The burden of ensuring updated certification now rests on the 
>>    destination that now has to obtain the current valid private key 
>>    to be able to decrypt a received bundle.
>>
>>2> Use of hierarchy:
>>    This offers us two advantages:
>>    a> Efficient key distribution: Normal IBE has only one PKG server which 
>>      possesses the master key. This PKG is responsible for extracting private
>>      keys of all the users of the system. 
>>      By using hierarchy - a) we can first place local PKGs in every region so that
>>      destination nodes dont have to go far to get their private keys and
>>      also b) compromise of a lower level PKG does not compromise the whole
>>      system (as the master secret resides with the root PKG only).
>>      The naming scheme in HIBE also derives naturally from the naming in the DTN 
>>      architecture where the endpoint address consists of two parts - region
>>      ID and the region-specific ID.
>>      For example: if the endpoint address for Bob is 'bundles://Earth/Bob_IP', then
>>      a PKG can be placed on Earth with ID:'Earth'. For larger regions, we can
>>      further create more levels in the hierarchy.
>>
>>    b> Revocation control: 
>>      We do this by creating a sub-hierarchy for each host (in addition to the
>>      hierarchy over multiple PKGs created for key distribution). 
>>      The levels in this sub-tree would reflect the degree of control desired
>>      for revocation. Senders will use the ID tuples corresponding to the
>>      leaves of this tree for encryption.
>>      As this sub-tree is completely located at a particular
>>      host, the host can act as a PKG and extract private keys for this tree 
>>      on its own. We can control the leaves for which the host is able to generate
>>      private keys for itself by providing it private keys for only selected
>>      internal nodes of this tree.
>>      For example: the first level could be month, the second level date and 
>>       the third level: hour. Then the ID of a user Bob (in region Earth) would be
>>       Earth.Bob.May.24.12pm . 
>>       - The Earth region PKG can extract private keys for all IDs of the form 
>>         'Earth.*'. The Earth PKG can then choose to give Bob the private key 
>>         for 'Earth.Bob' if Bob is a highly trusted user. Now Bob can generate all 
>>         keys of the form 'Earth.Bob.<month>.<date>.<hour>. 
>>       - A less trusted user 'Alice' will be given the private key for
>>         'Earth.Alice.Nov' only - this will allow Alice to read messages only for
>>         month of November. For a bundle encrypted with the full ID string
>>         Earth.Alice.Nov.25.12pm, Alice will be forced to ask a new private
>>         key every hour.
>>       - For more paranoid uses, an extra level of the this tree could be a
>>         random ID. This would force the receiver to acquire a new private key
>>         for each bundle it receives. A sender can now encrypt the bundle 
>>         with 'Earth.Alice.Nov.25.12pm.<random_id>'.
>>       - A sender that wishes lower security( and lower latency) for a
>>         session can now encrypt it with 'Earth.Alice.Nov.25.12pm.0000', and Alice
>>         would have to go to the Earth PKG only once to decrypt this bundle.
>>      In general, the PKG server responsible for a user needs to compute a
>>      subset cover over the user subtree i.e the minimum set of nodes that cover
>>      all the IDs that are allowed and none of the IDs that are not allowed
>>      for that user. Then it needs to extract private keys for only those
>>      nodes in the subset cover.
>>      
>>    c> Fine grained access control:
>>     A similar scheme as above can be used for forming ID strings needed for
>>     authentication and access control as well.
>>     For this source users sign the bundles with the correct privilege
>>     desired. For example, if Alice desires 'Urgent' class of service, it will
>>     need to sign the bundle with the identity 'Alice.Urgent'. For this it
>>     needs to possess the private key corresponding to 'Alice.Urgent'. 
>>     Possession of a private key corresponding to an identity
>>     implies that the system also authorized you for the rights that are
>>     associated with that identity.
>>     This is possible in IBE because all private keys are generated by the PKGs.
>>     The same hierarchical ID structure can be used for revocation and
>>     granting of rights as well. The subtree below each host
>>     would now represent different privileges.
>>     For example: A highly valuable Bob can be given access to all classes
>>      of service by providing the private key for 'Earth.Bob.Nov.25' - Bob can
>>      then generate keys for 'Earth.Bob.Nov.25.Urgent' etc and use them for
>>      signing his bundles.
>>      A less valuable 'Alice' will only be given the private key for
>>      'Earth.Alice.Nov.25.Bulk'.
>>     However this mechanism requires the ID string to be included
>>     in the bundle header(PSH) for routers to use the correct key
>>     for authentication.
>>     This issue was raised in [1] as well for key rollover.
>>     This overall method of encoding the permissions of the user in the ID
>>     string is very similar to using accompanying certificates in traditional PKI.
>>
>>Why not PKI?:
>>-------------
>>1> Implicit certification is not possible as a source host is forced to 
>>   first acquire the identity(public key) of the destination before sending
>>   any bundle. It is also forced to check
>>   whether the destination is currently certified or not by making third-party
>>   queries.
>>2> Revocation is made much difficult in DTN and solutions like maintaining 
>>   a Certificate Revocation List(CRL) does not work for DTNs.
>>
>>Other issues and Disadvantages:
>>-------------------------------
>>1> Key escrow: 
>>    In IBE, the PKG can generate private keys for all users and thereby decrypt
>>    bundles destined for all users. This may not be always desirable.
>>    A related property is 'non-repudiability' which means that a receiver can
>>    prove that only the sender could have signed the bundle.
>>    Also, the compromise of the root PKG jeopardizes the entire system
>>    and all messages that were sent in the past.
>>
>>2> Standards issue:
>>    Since we try to encode revocation control(date etc) and access control
>>    identifiers in the ID strings, all entities in the DTN need to agree on a
>>    common format. This is similar to the problem faced in traditional PKI
>>    over the format of certificates.
>>    
>>3> Distribution of private keys:
>>    Since users ask the PKGs to generate private keys, they have to be transmitted 
>>    securely from the PKGs. This might mean that the PKGs share another key
>>    with every user just for the purpose of sending private keys.
>>
>>5> Distribution of system wide public parameters
>>    An IBE system installation needs to bootstrap all hosts with
>>    the public system parameters of the PKG. 
>>    This also might need to be updated if the root PKG is compromised.
>>
>>6> Replay attacks:
>>    Although we guarantee confidentiality and integrity, we do not have any
>>    mechanism to detect and handle replay attacks.
>>    
>>Other options and optimizations:
>>--------------------------------
>>1> Use of Certificate Based Encryption [8]:
>>   The 'key escrow' problem can be solved by using this variation where users
>>   are allowed to generate their own private keys.
>>   Senders are now able to user long lasting public keys without the need
>>   to worry about the current certification status of the destinations.
>>   This also solves the problem of securely delivering extracted private keys
>>   to each user.
>>2> Reducing overhead of using hierarchical IBE:
>>    Normal HIBE, both the length of signatures and the number of steps required
>>    for encryption are proportional to the number of levels in the ID tree.
>>    Some techniques based on the BGLS aggregated signature scheme can be used
>>    to reduce the decryption complexity.
>>3> If non-repudiability is not desired, them the scheme proposed in [10] can be
>>   used. Here the the MAC for authentication is same as the cipher-text for 
>>   encryption. It also uses the same public IDs and private keys as the standard
>>   scheme. So we can get both authentication(+integrity) and secrecy with
>>   little extra cost.
>>
>>
>>Implementation in DTN2 :
>>-----------------------
>>1> What are the basic building blocks that need to be supported in the DTN2
>>   architecture.
>>2> User management: [1] suggested that the DTN agent cannot possess the
>>   private keys. Applications should store the keys and call external
>>   entity to perform the encryption. 
>>
>>
>>
>>
>>
>>
>>References:
>>-----------
>>[1] Email correspondence on the dtn-interest mailing list
>>[2] Draft: "Identity based Encryption for Delay Tolerant Networks"
>>    A. Chakrabarti and K Fall.
>>    summary: proposes the use of IBE for both confidentiality as well
>>    as access control management in DTNs.
>>[3] Draft: "A Secure Tetherless Computing Architecture" by S.Keshav et al.
>>    summary: proposes a hierarchy of PKGs using HIBE and HIBS for efficient
>>     key management in the TCA.
>>[4] "Exploiting Hierarchical IBE for Access Control to Pervasive Computing
>>    Information"
>>    Urs Hengartner and Peter Steenkiste
>>    summary: proposes use of HIBE for both "encryption-based" and
>>     "proof-based" access control for client-server interactions.
>>     More emphasis on preventing leakage of information about access control
>>     policies
>>[5] "Hidden Credentials" 
>>    
>>    summary: use of IBE for hidden credential trust negotiation.
>>[6] "Identity based signatures"
>>    Paterson
>>    summary: one scheme for signatures based on the Boneh/Franklin scheme.
>>[7] "Identity based Encryption based on the Weil Pairing"
>>    Boneh and Franklin
>>    summary: this introduces the first concrete IBE scheme.
>>[8] "Certificate-Based Encryption and the Certificate Revocation Problem" 
>>    Craig Gentry
>>    summary: this talks about mitigating problems in IBE by proposing
>>     Certificate based Encryption(CBE) in which users can choose their own
>>     private key.
>>[9] "Hierarchical ID based Cryptography"
>>    Gentry and Silverberg
>>    summary: this extends the Boneh/Franklin IBE scheme 
>>[10]"Authenticated Identity-based Encryption"
>>    Ben Lynn
>>    summary: extends the Boneh/Franklin scheme to provide integrity of the
>>     message being encrypted.
>>      
>>
>>
>>  
>>
> 
> -- 
> Howard Weiss
> SPARTA, Inc.
> 7075 Samuel Morse Drive
> Columbia, MD 21046
> 410.872.1515 x201
> 410.872.8079 (fax)
> 
>