RFC 6257
Bundle Security Protocol Specification
4. Mandatory Ciphersuites
This section defines the mandatory ciphersuites for this specification. There is currently one mandatory ciphersuite for use with each of the security block types BAB, PIB, PCB, and ESB. The BAB ciphersuite is based on shared secrets using HMAC. The PIB ciphersuite is based on digital signatures using RSA with SHA-256. The PCB and ESB ciphersuites are based on using RSA for key transport and AES for bulk encryption. In all uses of CMS eContent in this specification, the relevant eContentType to be used is id-data as specified in [RFC5652]. The ciphersuites use the mechanisms defined in Cryptographic Message Syntax (CMS) [RFC5652] for packaging the keys, signatures, etc., for transport in the appropriate security block. The data in the CMS object is not the bundle data, as would be the typical usage for CMS. Rather, the "message data" packaged by CMS is the ephemeral key, message digest, etc., used in the core code of the ciphersuite. In all cases where we use CMS, implementations SHOULD NOT include additional attributes whether signed or unsigned, authenticated or unauthenticated.4.1. BAB-HMAC
The BAB-HMAC ciphersuite has ciphersuite ID value 0x001. BAB-HMAC uses the strict canonicalization algorithm in Section 3.4.1. Strict canonicalization supports digesting of a fragment-bundle. It does not permit the digesting of only a subset of the payload, but only the complete contents of the payload of the current bundle,
which might be a fragment. The fragment-range item for security- parameters is not used to indicate a fragment, as this information is digested within the primary block. The variant of HMAC to be used is HMAC-SHA1 as defined in [RFC2104]. This ciphersuite requires the use of two related instances of the BAB. It involves placing the first BAB instance (as defined in Section 2.2) just after the primary block. The second (correlated) instance of the BAB MUST be placed after all other blocks (except possibly other BAB blocks) in the bundle. This means that, normally, the BAB will be the second and last blocks of the bundle. If a forwarder wishes to apply more than one correlated BAB pair, then this can be done. There is no requirement that each application "wrap" the others, but the forwarder MUST insert all the "up front" BABs, and their "at back" "partners" (without any security-result), before canonicalizing. Inserting more than one correlated BAB pair would be useful if the bundle could be routed to more than one potential "next hop" or if both an old and a new key were valid at sending time, with no certainty about the situation that will obtain at reception time. The security-result is the output of the HMAC-SHA1 calculation with the input being the result of running the entire bundle through the strict canonicalization algorithm. Both required BAB instances MUST be included in the bundle before canonicalization. Security-parameters are OPTIONAL with this scheme, but if used, then the only field that can be present is key-information (see Section 2.6). In the absence of key-information, the receiver is expected to be able to find the correct key based on the sending identity. The sending identity MAY be known from the security-source field or the content of a previous-hop block in the bundle. It MAY also be determined using implementation-specific means such as the convergence layer.4.2. PIB-RSA-SHA256
The PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02. PIB-RSA-SHA256 uses the mutable canonicalization algorithm in Section 3.4.2, with the security-result data field for only the "current" block being excluded from the canonical form. The
resulting canonical form of the bundle is the input to the signing process. This ciphersuite requires the use of a single instance of the PIB. 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. If the bundle being signed has been fragmented before signing, then we have to specify which bytes were signed in case the signed bundle is subsequently fragmented for a second time. If the bundle is a fragment, then the ciphersuite-parameters MUST include a fragment- range field, as described in Section 2.6, specifying the offset and length of the signed fragment. If the entire bundle is signed, then these numbers MUST be omitted. Implementations MUST support the use of the "SignedData" type as defined in [RFC5652], Section 5.1, with SignerInfo type SignerIdentifier containing the issuer and serial number of a suitable certificate. The data to be signed is the output of the SHA256 mutable canonicalization process. RSA is used with SHA256 as specified for the id-sha256 signature scheme in [RFC4055], Section 5. The output of the signing process is the SignatureValue field for the PIB. "Commensurate strength" cryptography is generally held to be a good idea. A combination of RSA with SHA-256 is reckoned to require a 3076-bit RSA key according to this logic. Few implementations will choose this length by default (and probably some just will not support such long keys). Since this is an experimental protocol, we expect that 1024- or 2048-bit RSA keys will be used in many cases, and that this will be fine since we also expect that the hash function "issues" will be resolved before any standard would be derived from this protocol.4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB
The PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite has ciphersuite ID value 0x003. This scheme encrypts PIBs, PCBs, and the payload. The key size for this ciphersuite is 128 bits. Encryption is done using the AES algorithm in Galois/Counter Mode (GCM) as described in [RFC5084]. Note: parts of the following description are borrowed from [RFC4106].
The choice of GCM avoids expansion of the payload, which causes problems with fragmentation/reassembly and custody transfer. GCM also includes authentication, essential in preventing attacks that can alter the decrypted plaintext or even recover the encryption key. GCM is a block cipher mode of operation providing both confidentiality and data integrity. The GCM encryption operation has four inputs: a secret key, an initialization vector (IV), a plaintext, and an input for additional authenticated data (AAD), which is not used here. It has two outputs, a ciphertext whose length is identical to the plaintext, and an authentication tag, also known as the integrity check value (ICV). For consistency with the description in [RFC5084], we refer to the GCM IV as a nonce. The same key and nonce combination MUST NOT be used more than once. The nonce has the following layout: +----------------+----------------+----------------+----------------+ | salt | +----------------+----------------+----------------+----------------+ | | | initialization vector | | | +----------------+----------------+----------------+----------------+ Figure 6: Nonce Format for PCB-RSA-AES128-PAYLOAD-PIB-PCB The salt field is a four-octet value, usually chosen at random. It MUST be the same for all PCBs that have the same correlator value. The salt need not be kept secret. The initialization vector (IV) is an eight-octet value, usually chosen at random. It MUST be different for all PCBs that have the same correlator value. The value need not be kept secret. The key (bundle encryption key, BEK) is a 16-octet (128 bits) value, usually chosen at random. The value MUST be kept secret, as described below. The integrity check value is a 16-octet value used to verify that the protected data has not been altered. The value need not be kept secret. This ciphersuite requires the use of a single PCB instance to deal with payload confidentiality. If the bundle already contains PIBs or PCBs, then the ciphersuite will create additional correlated blocks to protect these PIBs and PCBs. These "additional" blocks replace the original blocks on a one-to-one basis, so the number of blocks
remains unchanged. All of these related blocks MUST have the same correlator value. The term "first PCB" in this section refers to the single PCB if there is only one or, if there are several, then to the one containing the key-information. This MUST be the first of the set. First PCB - the first PCB MAY contain a correlator value, and MAY specify security-source and/or security-destination in the EID-list. If not specified, the bundle-source and bundle-destination, respectively, are used for these values, as with other ciphersuites. The block MUST contain security-parameters and security-result fields. Each field MAY contain several items formatted as described in Section 2.6. Security-parameters key-information salt IV (this instance applies only to payload) fragment offset and length, if bundle is a fragment Security-result ICV Subsequent PCBs MUST contain a correlator value to link them to the first PCB. Security-source and security-destination are implied from the first PCB; however, see the discussion in Section 2.4 concerning EID-list entries. They MUST contain security-parameters and security-result fields as follows: Security-parameters IV for this specific block Security-result encapsulated block The security-parameters and security-result fields in the subsequent PCBs MUST NOT contain any items other than these two. Items such as key and salt are supplied in the first PCB and MUST NOT be repeated.
Implementations MUST support use of "enveloped-data" type as defined in [RFC5652], Section 6, with RecipientInfo type KeyTransRecipientInfo containing the issuer and serial number of a suitable certificate. They MAY support additional RecipientInfo types. The "encryptedContent" field in EncryptedContentInfo contains the encrypted BEK that protects the payload and certain security blocks of the bundle. The Integrity Check Value from the AES-GCM encryption of the payload is placed in the security-result field of the first PCB. If the bundle being encrypted is a fragment-bundle, we have to specify which bytes are encrypted in case the bundle is subsequently fragmented again. If the bundle is a fragment, the ciphersuite- parameters MUST include a fragment-range field, as described in Section 2.6, specifying the offset and length of the encrypted fragment. Note that this is not the same pair of fields that appear in the primary block as "offset and length". The "length" in this case is the length of the fragment, not the original length. If the bundle is not a fragment, then this field MUST be omitted. The confidentiality processing for payload and other blocks is different, mainly because the payload might be fragmented later at some other node. For the payload, only the bytes of the bundle payload field are affected, being replaced by ciphertext. The salt, IV, and key values specified in the first PCB are used to encrypt the payload, and the resultant authentication tag (ICV) is placed in an ICV item in the security-result field of that first PCB. The other bytes of the payload block, such as type, flags, and length, are not modified. For each PIB or PCB to be protected, the entire original block is encapsulated in a "replacing" PCB. This replacing PCB is placed in the outgoing bundle in the same position as the original block, PIB or PCB. As mentioned above, this is one-to-one replacement, and there is no consolidation of blocks or mixing of data in any way. The encryption process uses AES-GCM with the salt and key values from the first PCB, and an IV unique to this PCB. The process creates ciphertext for the entire original block and an authentication tag for validation at the security-destination. For this encapsulation process, unlike the processing of the bundle payload, the authentication tag is appended to the ciphertext for the block, and the combination is stored into the encapsulated block item in the security-result.
The replacing block, of course, also has the same correlator value as the first PCB with which it is associated. It also contains the block-specific IV in security-parameters, and the combination of original-block-ciphertext and authentication tag, stored as an encapsulated block item in the security-result. If the payload was fragmented after encryption, then all those fragments MUST be present and reassembled before decryption. This process might be repeated several times at different destinations if multiple fragmentation actions have occurred. The size of the GCM counter field limits the payload size to 2^39 - 256 bytes, about half a terabyte. A future revision of this specification will address the issue of handling payloads in excess of this size.4.4. ESB-RSA-AES128-EXT
The ESB-RSA-AES128-EXT ciphersuite has ciphersuite ID value 0x004. This scheme encrypts non-payload-related blocks. It MUST NOT be used to encrypt PIBs, PCBs, or primary or payload blocks. The key size for this ciphersuite is 128 bits. Encryption is done using the AES algorithm in Galois/Counter Mode (GCM) as described in [RFC5084]. Note: parts of the following description are borrowed from [RFC4106]. GCM is a block cipher mode of operation providing both confidentiality and data origin authentication. The GCM authenticated encryption operation has four inputs: a secret key, an initialization vector (IV), a plaintext, and an input for additional authenticated data (AAD), which is not used here. It has two outputs, a ciphertext whose length is identical to the plaintext, and an authentication tag, also known as the Integrity Check Value (ICV). For consistency with the description in [RFC5084], we refer to the GCM IV as a nonce. The same key and nonce combination MUST NOT be used more than once. The nonce has the following layout:
+----------------+----------------+---------------------------------+ | salt | +----------------+----------------+---------------------------------+ | | | initialization vector | | | +----------------+----------------+---------------------------------+ Figure 7: Nonce Format for ESB-RSA-AES128-EXT The salt field is a four-octet value, usually chosen at random. It MUST be the same for all ESBs that have the same correlator value. The salt need not be kept secret. The initialization vector (IV) is an eight-octet value, usually chosen at random. It MUST be different for all ESBs that have the same correlator value. The value need not be kept secret. The data encryption key is a 16-octet (128 bits) value, usually chosen at random. The value MUST be kept secret, as described below. The integrity check value is a 16-octet value used to verify that the protected data has not been altered. The value need not be kept secret. This ciphersuite replaces each BP extension block to be protected with a "replacing" ESB, and each can be individually specified. If a number of related BP extension blocks are to be protected, they can be grouped as a correlated set and protected using a single key. These blocks replace the original blocks on a one-to-one basis, so the number of blocks remains unchanged. All these related blocks MUST have the same correlator value. The term "first ESB" in this section refers to the single ESB if there is only one or, if there are several, then to the one containing the key or key-identifier. This MUST be the first of the set. If the blocks are individually specified, then there is no correlated set and each block is its own "first ESB". First ESB - the first ESB MAY contain a correlator value, and MAY specify security-source and/or security-destination in the EID-list. If not specified, the bundle-source and bundle-destination, respectively, are used for these values, as with other ciphersuites. The block MUST contain security-parameters and security-result fields. Each field MAY contain several items formatted as described in Section 2.6.
Security-parameters
key-information
salt
IV for this specific block
block type of encapsulated block (OPTIONAL)
Security-result
encapsulated block
Subsequent ESBs MUST contain a correlator value to link them to the
first ESB. Security-source and security-destination are implied from
the first ESB; however, see the discussion in Section 2.4 concerning
EID-list entries. Subsequent ESBs MUST contain security-parameters
and security-result fields as follows:
Security-parameters
IV for this specific block
block type of encapsulated block (OPTIONAL)
Security-result
encapsulated block
The security-parameters and security-result fields in the subsequent
ESBs MUST NOT contain any items other than those listed. Items such
as key-information and salt are supplied in the first ESB and MUST
NOT be repeated.
Implementations MUST support the use of "enveloped-data" type as
defined in [RFC5652], Section 6, with RecipientInfo type
KeyTransRecipientInfo containing the issuer and serial number of a
suitable certificate. They MAY support additional RecipientInfo
types. The "encryptedContent" field in EncryptedContentInfo contains
the encrypted BEK used to encrypt the content of the block being
protected.
For each block to be protected, the entire original block is
encapsulated in a "replacing" ESB. This replacing ESB is placed in
the outgoing bundle in the same position as the original block. As
mentioned above, this is one-to-one replacement, and there is no
consolidation of blocks or mixing of data in any way.
The encryption process uses AES-GCM with the salt and key values from the first ESB and an IV unique to this ESB. The process creates ciphertext for the entire original block, and an authentication tag for validation at the security-destination. The authentication tag is appended to the ciphertext for the block and the combination is stored into the encapsulated block item in security-result. The replacing block, of course, also has the same correlator value as the first ESB with which it is associated. It also contains the block-specific IV in security-parameters, and the combination of original-block-ciphertext and authentication tag, stored as an encapsulated block item in security-result.5. Key Management
Key management in delay-tolerant networks is recognized as a difficult topic and is one that this specification does not attempt to solve. However, solely in order to support implementation and testing, implementations SHOULD support: o The use of well-known RSA public keys for all ciphersuites. o Long-term pre-shared-symmetric keys for the BAB-HMAC ciphersuite. Since endpoint IDs are URIs and URIs can be placed in X.509 [RFC5280] public key certificates (in the subjectAltName extension), implementations SHOULD support this way of distributing public keys. RFC 5280 does not insist that implementations include revocation checking. In the context of a DTN, it is reasonably likely that some nodes would not be able to use revocation checking services (either Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP)) and deployments SHOULD take this into account when planning any public key infrastructure to support this specification.6. Default Security Policy
Every node serves as a Policy Enforcement Point insofar as it enforces some policy that controls the forwarding and delivery of bundles via one or more convergence layer protocol implementation. Consequently, every node SHALL have and operate according to its own configurable security policy, whether the policy be explicit or default. The policy SHALL specify: Under what conditions received bundles SHALL be forwarded. Under what conditions received bundles SHALL be required to include valid BABs.
Under what conditions the authentication information provided in a
bundle's BAB SHALL be deemed adequate to authenticate the bundle.
Under what conditions received bundles SHALL be required to have
valid PIBs and/or PCBs.
Under what conditions the authentication information provided in a
bundle's PIB SHALL be deemed adequate to authenticate the bundle.
Under what conditions a BAB SHALL be added to a received bundle
before that bundle is forwarded.
Under what conditions a PIB SHALL be added to a received bundle
before that bundle is forwarded.
Under what conditions a PCB SHALL be added to a received bundle
before that bundle is forwarded.
Under what conditions an ESB SHALL be applied to one or more
blocks in a received bundle before that bundle is forwarded.
The actions that SHALL be taken in the event that a received
bundle does not meet the receiving node's security policy
criteria.
This specification does not address how security policies get
distributed to nodes. It only REQUIRES that nodes have and enforce
security policies.
If no security policy is specified at a given node, or if a security
policy is only partially specified, that node's default policy
regarding unspecified criteria SHALL consist of the following:
Bundles that are not well-formed do not meet the security policy
criteria.
The mandatory ciphersuites MUST be used.
All bundles received MUST have a BAB that MUST be verified to
contain a valid security-result. If the bundle does not have a
BAB, then the bundle MUST be discarded and processed no further; a
bundle status report indicating the authentication failure MAY be
generated.
No received bundles SHALL be required to have a PIB; if a received
bundle does have a PIB, however, the PIB can be ignored unless the
receiving node is the PIB-destination, in which case the PIB MUST
be verified.
No received bundles SHALL be required to have a PCB; if a received
bundle does have a PCB, however, the PCB can be ignored unless the
receiving node is the PCB-destination, in which case the PCB MUST
be processed. If processing a PCB yields a PIB, that PIB SHALL be
processed by the node according to the node's security policy.
A PIB SHALL NOT be added to a bundle before sourcing or forwarding
it.
A PCB SHALL NOT be added to a bundle before sourcing or forwarding
it.
A BAB MUST always be added to a bundle before that bundle is
forwarded.
If a destination node receives a bundle that has a PIB-destination
but the value in that PIB-destination is not the EID of the
destination node, the bundle SHALL be delivered at that
destination node.
If a destination node receives a bundle that has an ESB-
destination but the value in that ESB-destination is not the EID
of the destination node, the bundle SHALL be delivered at that
destination node.
If a received bundle does not satisfy the node's security policy
for any reason, then the bundle MUST be discarded and processed no
further; in this case, a bundle deletion status report (see the
Bundle Protocol Specification [DTNBP]) indicating the failure MAY
be generated.
7. Security Considerations
The Bundle Security Protocol builds upon much work of others, in
particular, "Cryptographic Message Syntax (CMS)" [RFC5652] and
"Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile" [RFC5280]. The security
considerations in these two documents apply here as well.
Several documents specifically consider the use of Galois/Counter
Mode (GCM) and of AES and are important to consider when building
ciphersuites. These are "The Use of Galois/Counter Mode (GCM) in
IPsec Encapsulating Security Payload (ESP)" [RFC4106] and "Using AES-
CCM and AES-GCM Authenticated Encryption in the Cryptographic Message
Syntax (CMS)" [RFC5084]. Although the BSP is not identical, many of
the security issues considered in these documents also apply here.
Certain applications of DTN need to both sign and encrypt a message, and there are security issues to consider with this. If the intent is to provide an assurance that a message did, in fact, come from a specific source and has not been changed, then it should be signed first and then encrypted. A signature on an encrypted message does not establish any relationship between the signer and the original plaintext message. On the other hand, if the intent is to reduce the threat of denial- of-service attacks, then signing the encrypted message is appropriate. A message that fails the signature check will not be processed through the computationally intensive decryption pass. A more extensive discussion of these points is in S/MIME 3.2 Message Specification [RFC5751], especially in Section 3.6. Additional details relating to these combinations can be found in Section 2.8 where it is RECOMMENDED that the encrypt-then-sign combination is usually appropriate for usage in a DTN. In a DTN, encrypt-then-sign potentially allows intermediate nodes to verify a signature (over the ciphertext) and thereby apply policy to manage possibly scarce storage or other resources at intermediate nodes in the path the bundle takes from source to destination EID. An encrypt-then-sign scheme does not further expose identity in most cases since the BP mandates that the source EID (which is commonly expected to be the security-source) is already exposed in the primary block of the bundle. 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. 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. If a bundle's PIB-destination is not the same as its destination, then some node other than the destination (the node identified as the PIB-destination) is expected to validate the PIB security-result while the bundle is en route. However, if for some reason the PIB is not validated, there is no way for the destination to become aware of this. Typically, a PIB-destination will remove the PIB from the bundle after verifying the PIB and before forwarding it. However, if there is a possibility that the PIB will also be verified at a
downstream node, the PIB-destination will leave the PIB in the bundle. Therefore, if a destination receives a bundle with a PIB that has a PIB-destination (which isn't the destination), this might, but does not necessarily, indicate a possible problem. If a bundle is fragmented after being forwarded by its PIB-source but before being received by its PIB-destination, the payload in the bundle MUST be reassembled before validating the PIB security-result in order for the security-result to validate correctly. Therefore, if the PIB-destination is not capable of performing payload reassembly, its utility as a PIB-destination will be limited to validating only those bundles that have not been fragmented since being forwarded from the PIB-source. Similarly, if a bundle is fragmented after being forwarded by its PIB-source but before being received by its PIB-destination, all fragments MUST be received at that PIB-destination in order for the bundle payload to be able to be reassembled. If not all fragments are received at the PIB- destination node, the bundle will not be able to be authenticated, and will therefore never be forwarded by this PIB-destination node. Specification of a security-destination other than the bundle- destination creates a routing requirement that the bundle somehow be directed to the security-destination node on its way to the final destination. This requirement is presently private to the ciphersuite, since routing nodes are not required to implement security processing. If a security target were to generate reports in the event that some security validation step fails, then that might leak information about the internal structure or policies of the DTN containing the security target. This is sometimes considered bad security practice, so it SHOULD only be done with care.8. Conformance
As indicated above, this document describes both BSP and ciphersuites. A conformant implementation MUST implement both BSP support and the four ciphersuites described in Section 4. It MAY also support other ciphersuites. Implementations that support BSP but not all four mandatory ciphersuites MUST claim only "restricted compliance" with this specification, even if they provide other ciphersuites. All implementations are strongly RECOMMENDED to provide at least a BAB ciphersuite. A relay node, for example, might not deal with end- to-end confidentiality and data integrity, but it SHOULD exclude unauthorized traffic and perform hop-by-hop bundle verification.
9. IANA Considerations
This protocol has fields that have been registered by IANA.9.1. Bundle Block Types
This specification allocates four codepoints from the existing "Bundle Block Types" registry defined in [RFC6255]. Additional Entries for the Bundle Block-Type Codes Registry: +-------+--------------------------------------+----------------+ | Value | Description | Reference | +-------+--------------------------------------+----------------+ | 2 | Bundle Authentication Block | This document | | 3 | Payload Integrity Block | This document | | 4 | Payload Confidentiality Block | This document | | 9 | Extension Security Block | This document | +-------+--------------------------------------+----------------+9.2. Ciphersuite Numbers
This protocol has a ciphersuite number field and certain ciphersuites are defined. An IANA registry has been set up as follows. The registration policy for this registry is: Specification Required The Value range is: Variable Length Ciphersuite Numbers Registry: +-------+--------------------------------------+----------------+ | Value | Description | Reference | +-------+--------------------------------------+----------------+ | 0 | unassigned | This document | | 1 | BAB-HMAC | This document | | 2 | PIB-RSA-SHA256 | This document | | 3 | PCB-RSA-AES128-PAYLOAD-PIB-PCB | This document | | 4 | ESB-RSA-AES128-EXT | This document | | >4 | Reserved | This document | +-------+--------------------------------------+----------------+9.3. Ciphersuite Flags
This protocol has a ciphersuite flags field and certain flags are defined. An IANA registry has been set up as follows. The registration policy for this registry is: Specification Required The Value range is: Variable Length
Ciphersuite Flags Registry:
+-----------------+----------------------------+----------------+
| Bit Position | Description | Reference |
| (right to left) | | |
+-----------------+----------------------------+----------------+
| 0 | Block contains result | This document |
| 1 | Block contains correlator | This document |
| 2 | Block contains parameters | This document |
| 3 | Destination EIDref present | This document |
| 4 | Source EIDref present | This document |
| >4 | Reserved | This document |
+-----------------+----------------------------+----------------+
9.4. Parameters and Results
This protocol has fields for ciphersuite-parameters and results. The
field is a type-length-value triple and a registry is required for
the "type" sub-field. The values for "type" apply to both the
ciphersuite-parameters and the ciphersuite results fields. Certain
values are defined. An IANA registry has been set up as follows.
The registration policy for this registry is: Specification Required
The Value range is: 8-bit unsigned integer
Ciphersuite-Parameters and Results Type Registry:
+---------+------------------------------------+----------------+
| Value | Description | Reference |
+---------+------------------------------------+----------------+
| 0 | reserved | This document |
| 1 | initialization vector (IV) | This document |
| 2 | reserved | This document |
| 3 | key-information | This document |
| 4 | fragment-range (pair of SDNVs) | This document |
| 5 | integrity signature | This document |
| 6 | unassigned | This document |
| 7 | salt | This document |
| 8 | PCB integrity check value (ICV) | This document |
| 9 | reserved | This document |
| 10 | encapsulated block | This document |
| 11 | block type of encapsulated block | This document |
| 12-191 | reserved | This document |
| 192-250 | private use | This document |
| 251-255 | reserved | This document |
+-------+--------------------------------------+----------------+
10. References
10.1. Normative References
[DTNBP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. [DTNMD] Symington, S., "Delay-Tolerant Networking Metadata Extension Block", RFC 6258, May 2011. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005. [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009. [RFC6255] Blanchet, M., "Delay-Tolerant Networking (DTN) Bundle Protocol IANA Registries", RFC 6255, May 2011.10.2. Informative References
[DTNarch] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007. [PHIB] Symington, S., "Delay-Tolerant Networking Previous-Hop Insertion Block", RFC 6259, May 2011.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, November 2007. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
Authors' Addresses
Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-7209 EMail: susan@mitre.org URI: http://mitre.org/ Stephen Farrell Trinity College Dublin Distributed Systems Group Department of Computer Science Trinity College Dublin 2 Ireland Phone: +353-1-896-2354 EMail: stephen.farrell@cs.tcd.ie Howard Weiss SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 US Phone: +1-443-430-8089 EMail: howard.weiss@sparta.com Peter Lovell SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 US Phone: +1-443-430-8052 EMail: dtnbsp@gmail.com