Re: [dtn-interest] Comments on RFC 6257

["Burleigh, Scott C (313B)" <[e-mail]>]

Hi, Michael.  You raise some good points, but I think this might not be the right time to take them all up individually.

Starting about seven months ago -- or even earlier, for some aspects of BSP -- there has been growing agreement among many of us that the Bundle Security Protocol is unnecessarily complex in several fundamental ways.  Ed Birrane at Johns Hopkins APL has drafted a revised, much simplified BSP specification that I believe he plans to post as an Internet Draft as soon as some administrative obstacles can be hurdled.  That draft omits from BSP some functionality that could instead be provided by a bundle-in-bundle encapsulation mechanism, and an Internet Draft that defines such a mechanism was posted on April 1 (http://datatracker.ietf.org/doc/draft-irtf-burleigh-bibe/).

I am hoping we'll be able to spend some time on the proposed revisions at IETF 87 in late July / early August and, ideally, arrive at some consensus within DTNRG as to how to proceed.  If we come out of that meeting with some agreement, then I think it would then make sense to revisit your comments at that time in the light of the simpler draft spec.

Scott

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Michael Noisternig
Sent: Tuesday, June 18, 2013 2:12 AM
To: [e-mail]
Subject: [dtn-interest] Comments on RFC 6257

Part (3/3) of my review: Comments on the Bundle Security Protocol document.

I consider the Bundle Security Protocol to be overly and unnecessarily complex in its current specification. I acknowledge the need for a BAB vs. PIB, but I don't see why the PCB should be so radically different from the PIB and not integrated with the PIB. The need for an ESB hasn't become clear to me. Rather than specifying a separate ciphersuite for each security block it would be preferable to split them into canonicalization & algorithms & parameters supported by a ciphersuite. 
In general, if the security processing would be modeled more akin to an actual encapsulation (tunneling) mechanism (yes, the Payload Block may still stay as is) some of the issues identified could potentially be avoided. I will try to express my thoughts more clearly in my comments below when addressing specific parts of the document.

2.1. Abstract Security Block, EID-references:
"If one or more references are present,
       flags in the ciphersuite ID field, described below, specify which."
As per RFC 5050, the EID references are preceded by a counter value. The document does not say what to do when there is a mismatch with the security EID flags. Also, it is not actually the ciphersuite ID field but the ciphersuite flags field.

Security-destination:
If a security-destination is present in some security block but bundle routers are not required to support the bundle security protocol this creates a routing problem. The problem would be avoided if some kind of tunnelling encapsulation were chosen for the security processing such that the security destination appears as the destination EID in the Primary Bundle Block.

3rd-last paragraph on the correlator field:
"This can be used to place a BAB that contains
    the ciphersuite information at the "front" of a (probably large)
    bundle, and another correlated BAB that contains the security-result
    at the "end" of the bundle."
Why is this flexibility wanted? Why isn't the result prescribed to be always at the end? In that case, why do we need to correlate blocks and not say "BAB requires a header block at the front and a trailer block at the end", without some correlation value.

2.2. Bundle Authentication Block:
I acknowledge the need for hop-by-hop vs. end-to-end security processing and I accept that a separate type be defined for hop-by-hop rather than end-to-end authentication, mainly for proper selection of the canonicalization algorithm (a next-hop destination could be selected via a broadcast endpoint in the PIB). But I think other than that there shouldn't be any discrepancies in order to minimize complexity; e.g., partial processing should be supported by both BAB and PIB.

"For the case using two related BAB instances, the first instance is
    as defined above, except the ciphersuite ID MUST be documented as a
    hop-by-hop authentication ciphersuite that requires two instances of
    the BAB."
What is the benefit of treating these as two separate ciphersuites? I think this should be covered by the canonicalization mechanism rather than by a separate ciphersuite, adding to unnecessary complexity.

2.3. Payload Integrity Block
Why do we need a PIB and not use a PCB with an integrity-only "cipher"suite? I am not convinced there is a need for both PIB and PCB. 
After all, they are end-to-end security blocks and refer to the same security link between source and destination. An integrated PIB+PCB could just as easily indicate the presence of a MAC or signature, which intermediate nodes may verify.

"The ciphersuite MAY process less than the entire original bundle
       payload.
Is this also supported for the BAB or not? (It doesn't seem so but it should be.)

"if the ciphersuite processes less than the complete, original bundle
       payload, the ciphersuite-parameters of this block MUST specify
       which bytes of the bundle payload are protected."
Does this refer to the fragment-range security-parameter or is it really part of the ciphersuite spec?

"The use of a generally available key is RECOMMENDED if custodial
    transfer is employed and all nodes SHOULD verify the bundle before
    accepting custody."
Why is this being recommended? Isn't the use of BABs satisfactory?

2.4. Payload Confidentiality Block:
"It is strongly RECOMMENDED that a data integrity mechanism be used in
    conjunction with confidentiality, and that encryption-only
    ciphersuites NOT be used."
One might prefer signatures over MACs. After all, what is the point of having PIBs when integrity should be part of PCBs?

"Fragmentation, reassembly, and custody transfer are adversely
    affected by a change in size of the payload due to ambiguity about
    what byte range of the original payload is actually in any particular
    fragment.  Ciphersuites SHOULD place any payload expansion, such as
    authentication tags (integrity check values) and any padding
    generated by a block-mode cipher, into an integrity check value item
    in the security-result field (see Section 2.6) of the confidentiality
    block."
Can this be elaborated? It is not clear what issue is being described here.

"Ciphersuites SHOULD define super-encryption such that, as well as re-
    encrypting the payload, it also protects the parameters of earlier
    encryption."
Why should this be part of the ciphersuite spec?

"Multiple related PCB instances are required if both the payload and
    PIBs and PCBs in the bundle are to be encrypted."
So where is the PCB that encrypts the payload positioned?

"In this scenario, the payload is encrypted
    using a BEK.  Several PCBs contain the BEK encrypted using different
    KEKs, one for each destination."
How do receivers know which key to take for decryption? By taking the "previous" key decoded?

"Any additional bytes generated as a result of encryption and/or
       authentication processing of the payload SHOULD be placed in an
       "integrity check value" field (see Section 2.6) in the security-
       result of the first PCB."
I think the PCB is poorly designed. It should support carriage of ICVs in a correlated block after the Payload Block just as PIBs and BABs do. 
(And then get rid of PIBs.)

2.5. Extension Security Block:
"Extension security blocks provide protection for non-payload-related
    portions of a bundle."
Why is a separate security block being defined? This is not clear.

2.6. Parameters and Result Fields:
"key-information: key material encoded or protected by the key
       management system and used to transport an ephemeral key protected
       by a long-term key.  This item is discussed further in
       Section 2.7."
I take it that ephemeral/session keys can only be updated using long-term keys? I.e., only using key transport and not key derivation?

3.2. Processing Order of Security Blocks:
This section includes a paragraph discussing the issue of overlapping security paths. In particular, it states that "The bundle security scheme does not deal with security paths that
    overlap partially but not completely.  The security policy for a node
    MUST avoid specifying, for a bundle, a security-destination that
    causes a conflict with any existing security-destination in that
    bundle."
While obviously this should be avoided it actually is transparent to bundle security. In practice, if that happens, the bundle would have to be partially routed backwards.

3.4.1. Strict Canonicalization:
"we omit all PIB security-
    results for all PIB ciphersuites.  All security-result length fields
    are included, even though their corresponding security-result data
    fields are omitted."
Why should this be done? It prevents us from detecting tinkering with inner PIB security results.

3.4.2. Mutable Canonicalization:
"[Variable-length SDNVs] are canonicalized in unpacked form, as eight-byte fixed-width
    fields in network byte order."
What is the benefit of this?

It later states that
"Encoding does not need
       optimization since the values are never sent over the network."
But encoding also does not need access rate optimizations, so I do not see the point in re-encoding from SDNV to standard binary values.

3.5. Endpoint ID Confidentiality:
"If endpoint ID
    confidentiality is required, then bundle-in-bundle encapsulation can
    solve this problem in some instances."
How is this supported in the protocol?

3.6. Bundles Received from Other Nodes, 7th paragraph:
"If the bundle has one or more PIBs for which the receiving node is
    the bundle's PIB-destination... [...] Otherwise, if the PIB verifies, ..."
I am wondering, should this be set in plural, "If all PIBs verify, ..."?

3.8. Bundle Fragmentation and Reassembly, last paragraph:
"Note: various fragments MAY have additional security blocks added at
    this or later stages, and it is possible that correlators will
    collide.  In order to facilitate uniqueness, ciphersuites SHOULD
    include the fragment-offset of the fragment as a high-order component
    of the correlator."
Can this be elaborated?

4. Mandatory Ciphersuites:
"The BAB ciphersuite is based on shared secrets using HMAC.  The PIB
    ciphersuite is based on digital signatures using RSA with SHA-256."
I have mentioned the complexity of defining two separate ciphersuites (modulo canonicalization) for BAB and PIB before. In relation to this, why only a MAC for the former and only a signature for the latter?

4.1. BAB-HMAC:
"Strict canonicalization supports digesting of a fragment-bundle.  It
    does not permit the digesting of only a subset of the payload"
Why? I see no purpose in this restriction.

"If a forwarder wishes to apply more than one
    correlated BAB pair, then this can be done.  [...] the forwarder MUST
    insert all the "up front" BABs, and their "at back" "partners"
    (without any security-result), before canonicalizing."
As per 3.4.1., why are security-results being omitted?

4.2. PIB-RSA-SHA256:
"Because the signature field in SignedData SignatureValue is a
    security-result field, the entire key-information item MUST be placed
    in the block's security-result field, rather than security-
    parameters."
Not clear. This needs to be elaborated.

4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB:
What is "RSA" doing in the name? Shouldn't this rather be GCM? (The same question applies to 4.4. ESB-RSA-AES128-EXT.)

"Encryption is done using the AES algorithm in Galois/Counter Mode
    (GCM)"
I assume integrity check values are intended to be 128 bits in size. 
This seems like a lot of overhead for bandwidth-constrained networks, and certainly is more than needed for most security applications. On the other hand, GCM has the caveat of not being appropriate for small tag sizes. As such, I do not see GCM as a good choice for a mandatory ciphersuite.

Speaking of tag sizes, specifying different ciphersuites for all possible sizes is quite inflexible and potentially results in an exponential specification of ciphersuites. I think the ciphersuite should include a specification of admissible tag sizes.

7. Security Considerations:
"A message that fails the signature check will not be
    processed through the computationally intensive decryption pass."
Compared to a signature verification symmetric decryption is cheap (unless the payload is extraordinarily huge).

"Should exposure of either the source EID or the
    signerInfo be considered an interesting vulnerability, then some form
    of bundle-in-bundle encapsulation would be required as a mitigation."
Again... how to do bundle-in-bundle encapsulation?

"If a BAB ciphersuite uses digital signatures but doesn't include the
    security-destination (which for a BAB is the next host), then this
    allows the bundle to be sent to some node other than the intended
    adjacent node.  Because the BAB will still authenticate, the
    receiving node might erroneously accept and forward the bundle.  When
    asymmetric BAB ciphersuites are used, the security-destination field
    SHOULD therefore be included in the BAB."
Not sure I agree. It might be on purpose that no specific next-hop is being specified (e.g., when using anycast transmission to some next security hop, or when using broadcast transmission).
_______________________________________________
dtn-interest mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/dtn-interest