[dispatch] [art] [AS2 Specification Modernization] draft-petta-rfc4130bis-00 - Proposed Updates

[Debra Petta <[e-mail]>]

I have been working with a group of AS2 vendors over the past several months to establish a list of proposed changes to the original AS2 specification, RFC 4130.  As RFC 4130 is used as the authoritative standard for AS2 designers, developers, and quality assurance engineers, we believe that the following proposed updates would make it less ambiguous and would provide better guidance on the use of updated algorithms, security standards and best practices.

Please use this draft  https://datatracker.ietf.org/doc/draft-petta-rfc4130bis/ as a reference.  It is currently an exact copy of the original RFC 4130 draft, but it is where all updates will be made.


  1.  First and foremost: backward compatibility is essential to interoperability.  Note Postel's Law (i.e., the Robustness Principle): "Be conservative in what you send and liberal in what you accept".  We MUST *not* include any breaking changes in the updated AS2 Draft.


  1.  Since support of AS1 is rare and this document is specifically used for AS2, remove the references to AS1 and SMTP that are included throughout this draft.  AS2 is mature enough to stand on its own and doesn't need the references to AS1.



  1.  Although RFCs referenced in the AS2 Draft may have been deprecated, it is important that these specifications continue to be used to maintain backward compatibility.


  1.  Although the general transport of AS2 over HTTP is still acceptable, unless the payload content is encrypted, many AS2 implementations now require transport over HTTPS.  (Include this statement in section 5.1).


  1.  When sending over HTTPS using TLS, TLS 1.2 or greater SHOULD be used for security purposes. Insecure SSL versions and cipher suites SHOULD be prohibited. (Section 5.1)


  1.  The usage of SHA-1 and MD5 (referenced in Section 1.2, 7.3, and 7.4.2) should either be replaced or used in addition to the SHA2 algorithms, minimally SHA-256. Usage of SHA-384 and SHA-512 should be optional. SHA-224 is generally not used.


  1.  Expand on the usage of the "signed-receipt-micalg" header value in section 7.3.  If it contains a list of multiple algorithms, the order of the supported algorithms is from left to right.  Is it necessary to include more than one algorithm in that list?  Wouldn't this require computation and internal storage of the MIC value(s) using the list of multiple algorithms?  Does any AS2 implementation currently do this?  If not, we should change the draft to only include one algorithm instead for simplification of the signing and MIC computations.


  1.  Since the sha1 algorithm is deprecated and is being phased out, it should only be used in real-world scenarios in those situations where a trading partner cannot support SHA2 algorithms. It is up to the sender to determine the value in the "signed-receipt-micalg" header and in real-world scenarios, this value SHOULD be a SHA2 algorithm, unless SHA2 is not supported.


  1.  Security Considerations (Section 9) needs to be modified to remove the references to Triple DES (3DES) in favor of AES algorithms (AES-128 supported at a minimum, with AES-192 and AES-256 optionally supported).


  1.  When encrypting the payload, multiple recipients SHOULD be supported. This is needed for recoverable decryption (where the sender also encrypts using its own certificate). It is also needed to handle the EU rule that may require a back door for the authorities.  (Add to section 7.1).  Refer to RFC 2630 Section 6  (https://datatracker.ietf.org/doc/html/rfc2630#section-6)  for more details.


  1.  In section 4.2, we should also include "application/octet-stream" as an acceptable content-type for transmitting binary content and as a fallback for other content that does not have a supported content-type.  Should we also include support for JSON content, or would this break existing implementations?


  1.  Add a note in section 4.1 that MIME header names are *not* case sensitive.


  1.  Also note that MIME headers SHOULD *not* be folded because they cause interoperability issues in some web servers (e.g., IIS) and in other back-end servers (e.g., Jetty).


  1.  The AS2 System Identifier, i.e., AS2-To and AS2-From values, MUST be quoted if the value contains an embedded space, and MUST *not* be quoted if it does not contain an embedded space. This is already stated in section 6.2, but it needs to be clarified because it is often an interoperability issue in real-world scenarios.


  1.  Although MIME header names, i.e., that portion of the headers to the left of the colon (:) are *not* case sensitive, values for AS2 System Identifiers (that portion to the right of the colon)  *are* case sensitive.  Make sure that this distinction is specifically stated in section 6.2.


  1.  If Message Identifiers are composed using AS2 identifiers or other identifiers that include embedded spaces, those embedded spaces MUST be replaced with other characters (such as an underscore) when creating the Message-ID since some AS2 implementations include conformance checking of the value of this field based on RFC 2822, section 3.6.4  (https://datatracker.ietf.org/doc/html/rfc2822#section-3.6.4).<https://datatracker.ietf.org/doc/html/rfc2822%23section-3.6.4).>  Add this to section 5.3.3.


  1.  Section 7.3 currently states that the "Disposition-Notification-To" value MUST include an email address, but this is no longer true.  This was originally required for AS1 over SMTP,  but in AS2 this value may be a URL, a fully qualified host name, an AS2 identifier or some other implementation-specific value.


  1.  When an asynchronous MDN is requested, the receiver MUST return the "200 OK" response and close the initial connection before returning the MDN over a new/separate HTTP or HTTPS connection.  Add this to section 7.


  1.  The Message-ID in the MDN is *not* a required header however the Original-Message-ID header *is* required.  Include this statement in section 7.


  1.  The Final-Recipient field MUST always be present in the human-readable portion of  the MDN.  Add this statement to section 7.4.3.


  1.  In section 7.4.3 (and/or 7.5.3 and 7.5.4 ), add "unknown-trading-relationship" as an additional, valid MDN AS2-disposition-modifier-extension type.  Also include:
     *   "Duplicate-filename-encountered, unique filename generated"
     *   "Illegal filename, unique filename generated"
     *   "Filename for payload not provided, unique filename generated"
These are used by AS2 implementations that support FN-MDN, i.e., the error/warning checking of the file names and returning of the responses through the MDN disposition.


  1.  It was suggested that the "unsupported content-type" be added as another MDN "Error" or "Failure" disposition modifier, however this is already addressed in section 7.5.3 (as "Failure: unsupported format").  Should we include it or is it redundant?


  1.  In section 7.5.4, also include "Error: decompression-failed" as a valid disposition-modifier.  (The original AS2 Draft was created before compression was fully supported.)

  1.  Currently the AS2-Version header value specified in section 6.1 only includes version 1.0 for initial AS2 implementations, and version 1.1 that includes support for compression. Version 1.2  has since been added for support of the EDIINT-features header (https://datatracker.ietf.org/doc/rfc6017/)  and also needs to be included in this draft for the sake of completeness.


  1.  Also include a reference to the optional "EDIINT-Features" Header  (https://datatracker.ietf.org/doc/rfc6017/) in Section 6  and include an expansion on the other features that have since been added.  Note that CEM, multiple-attachments, and AS2-Reliability were included in the initial list of possible supported features, but we should also include them again to make sure all features are referenced.  Also include AES, SHA2 and BA (Authentication using the Authorization MIME header) to let trading partners know that those features are also supported:
     *   Certificate Exchange Messaging (CEM) - https://datatracker.ietf.org/doc/html/draft-meadors-certificate-exchange-12  (expired)
     *   AS2 Reliability - also includes AS2 Restart - https://datatracker.ietf.org/doc/draft-duker-as2-reliability/ (expired) and http://tools.ietf.org/html/draft-harding-as2-restart-02 (expired)
     *   Multipart-Attachments (MA) -  https://datatracker.ietf.org/doc/rfc6362/
     *   Chunked-Transfer-Encoding (CTE) - https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding
     *   Filename Preservation (FN) - https://datatracker.ietf.org/doc/draft-harding-ediint-filename-preservation/ (expired)
     *   Filename Preservation with Multipart Attachments (FN-MA) - applies both FN and MA specifications
     *   Filename Preservation and Error Checking with MDN error/warning notification (FN-MDN) (https://www.rfc-editor.org/rfc/rfc3798)


  1.  Add a new (optional) "AS2-Product" header to section 6 that includes the product name and version of the sender's AS2 engine.  Some AS2 implementations need this for their back-end systems to activate special settings in support of a given trading partner's product.  Expand on the reasoning for this a little more.  If we include all supported capabilities in the "EDIINT-Features" header, is this header still necessary?


  1.  Include the suggestion that only binary encoding SHOULD be used for simplification (section 5.2.1). Base64 encoding of the entire payload content only adds more processing overhead to the message.  Quoted-printable and 7-bit encoding are carry-overs from AS1/SMTP implementations and is unnecessary for transport over HTTP, however for the sake of backward compatibility, we can't enforce this.


  1.  Since the content sent over HTTP should not change in transit, receiving AS2 servers may compute the MIC value without first canonicalizing the content.  To avoid MIC computation issues and to maintain backward compatibility, 8-bit binary encoding SHOULD be used, or if that is not possible canonicalization MUST still be performed by the sender *before* computing any signature or MIC and the canonical content being sent.  Add this statement to section 7.3.1 where the MIC computation is discussed.


  1.  Certificate serial numbers MUST *not* be negative, per RFC 3280. (https://datatracker.ietf.org/doc/html/rfc3280#section-4.1.2.2)  Add this statement to section 8.


  1.  Certificates used for enveloping the message or for secure transport (over SSL/TLS) SHOULD have a minimum key length of 2048 bits. (Many AS2 implementations now require this for security purposes.)  Add this to section 8.


  1.  Section 9.2 needs to be updated to state that if a self-signed certificate is used for SSL/TLS, it SHOULD contain a Subject Alternative Name (SAN) extension that includes the hostname and/or IP address of the sender.  This is another security requirement in some AS2 implementations. If included, this certificate extension MUST be marked as non-critical.


  1.  Section 8 needs to be reworked to discuss a method for automatically exchanging revoked or expired certificates using Certificate Exchange Messaging  (CEM)  (refer to https://datatracker.ietf.org/doc/html/draft-meadors-certificate-exchange-12) - expired draft.
     *   Background:   Twenty-five years ago, a certificate could have a validity range of up to five years.  More and more, security requirements in big organizations limit the validity period of certificates to one year or less. However, the manual  exchange and installation of updated certificates becomes unsustainable when the number of trading partners is large and the validity period is short.
     *    It has also been suggested that an AS2 GET operation could be used during the initial setup to retrieve the signing, encryption, and SSL/TLS certificates for a new trading relationship, although I'm not sure if this is secure because it may allow "bad actors" to gain access to the trading relationship, unless we specifically state that the pre-exchanged AS2-To/AS2-From identifiers (and/or possibly some other security mechanism) first be used to validate the trading relationship.  If this is a valid option, we would need to expand on this new/optional feature.  Maybe we could also include the EDIINT-Features header in the initial AS2 GET to let the trading partner know about the sender's supported capabilities during the initial setup phase. Then the receiver's capabilities could also be returned as part of the response.


  1.  Retry functionality and behavior needs to be explicitly defined in section 5.5 and/or a reference to that link should be included (https://datatracker.ietf.org/doc/draft-duker-as2-reliability/) - also an expired draft.   We've already had internal discussions that some of the content in that document is out of date and is not relevant anymore, specifically the return of the HTTP 102 (Processing) status code, so we should also include a statement about this in the updated AS2 Draft.


  1.  HTTP Error Recovery through AS2 Restart functionality (also in section 5.5) needs to be explicitly defined and/or include a reference to that link (http://tools.ietf.org/html/draft-harding-as2-restart-02)  -- also an expired draft.


  1.  All examples should be modernized with up-to-date headers, encryption/signature examples and common payload types. (Section 12 / Appendix A)


Please reply with any comments or suggestions about any items in this list or if you have any additions, feel free to add them.  Once we have an agreement on the list of updates, we can start making changes to the original draft.

Thanks,

Debra Petta
Drummond Group
www.drummondgroup.com