What is an AS2 MDN?

Overview

An MDN is an electronic return receipt that a trading partner can optionally request during an AS2 interchange. The use of MDNs helps enforce data integrity and non-repudiation in AS2. In this post, we'll discuss the value of issuing an AS2 MDN, your options when using it, and an overview of the usual configurable MDN settings in a managed file transfer server.

Why use an MDN

After transmitting an EDI message to a trading partner, we usually want to confirm whether the message - in its entirety - actually went through. More so, if our EDI (Electronic Data Interchange) is carried out over the Internet, where message packets may have to go through several hoops. This concern can be quickly addressed if you do your EDI over AS2. That's because AS2 provides an electronic return receipt known as an MDN (Message Disposition Notification).

The EDI message sender initiates the Message Disposition Notification process and is usually concluded once the sender receives the requested MDN. Let me show you a typical AS2 transmission that utilizes this process:

Figure 1

Let's go through those steps briefly:

1. The sender encrypts the EDI message, affixes its digital signature, and specifies an MDN option. We'll talk more about MDN options in a short while. But in the meantime, let's assume the option amounts to a request for the return receipt;

2. The EDI message is transmitted over the Internet via AS2;

3. The receiver decrypts the message and validates the sender's digital signature;

4. The receiver recognizes the request for an MDN, prepares it, affixes its digital signature, and then sends it back to the original sender.

5. Finally, the sender receives the MDN, validates the receiver's digital signature, and closes the connection.

So, basically, the MDN serves to inform the sender about two things: 1) That the AS2 transmission was completed successfully and 2) That the EDI message was received by the intended recipient devoid of any unauthorized modifications (i.e., data integrity was preserved).

This can be confirmed through the digital signature affixed to the MDN and used for non-repudiation. Hence, MDNs can be vital in establishing that specific SLA requirements have been met and settling disputes concerning AS2 EDI transmissions.

But how does each trading partner validate the digital signature it receives?

AS2 MDN Digital Signatures

Before the two parties start sending EDI messages over AS2, they first share public keys. Each public key corresponds to a specific private key, used for generating a digital signature, and is held by the party who owns that particular signature.

The private key is kept secret and, hence, is never shared. The function of the public key is to validate the digital signature. Only the private key corresponding to a particular public key can generate a signature that the public key can validate.

Figure 2

wherein:

1. TP - A generates a digital signature using its private key;

2. TP - A's digital signature is sent along with an AS2 EDI message;

3. TP - B validates TP - A's digital signature using TP - A's public key that's already in its possession.

Once the signature has been validated, TP - B can be sure that the EDI message came from a trusted trading partner and that the data was unaltered along the way.

The same thing happens when TP - B responds with an MDN:

Figure 3

wherein:

1. TP - B generates a digital signature using its private key;

2. TP - B's digital signature is sent along with an AS2 MDN;

3. TP - A validates TP - B's digital signature using TP - B's public key that's already in its possession.

Once the signature has been validated, TP - A can be sure the MDN came from the trading partner it sent the AS2 EDI message and that the AS2 transmission was completed successfully.

For more information on public key cryptography and the use of public and private keys, I suggest you read the following articles:

✔ Roles of Server and Client Keys in Secure File Transfers

✔ What is an SSL File Transfer?

✔ Securing Data at Rest with OpenPGP

As mentioned in Step 1, the message sender should specify an MDN option. One of those options is to forgo the MDN. Of course, we don't recommend that. If you want a secure file transfer, you will want to stick with the options that amount to an MDN transmission. Among those options, two are commonly used: AS2 with Sync MDN and AS2 with ASync MDN.

Synchronous vs Asynchronous MDN

Synchronous or Sync MDN is an option wherein the MDN is sent to the sender via the same HTTP/S connection to deliver the original EDI message. On the other hand, Asynchronous or ASync MDN is an option wherein the MDN is sent later via a different HTTP/S connection.

To illustrate the difference between these two options:

Figure 4

Figure 5

Sync MDN is the faster option because it uses the same HTTP connection as the original transmission. However, it is unsuitable for large file transfers because it may be abruptly canceled during a timeout, especially in low-bandwidth conditions. So, if you need to transfer large files but you or your trading partner are subject to poor network conditions, then ASync MDN would be a better choice.

Interested in seeing how AS2 MDN works in a real-world scenario? Schedule a demo with us today and explore the benefits of secure and compliant file transfers with JSCAPE MFT Server.

MDN is only one of a handful of security features in AS2. To learn more about AS2, I recommend you read the blog post entitled AS2 Simplified.

Typical MDN Settings

This section will give you a glimpse of the MDN settings you typically configure on your favorite managed file transfer server. In our case, that managed file transfer server would be JSCAPE MFT Server.

All MDNs will, of course, contain a FROM and TO ID. The FROM ID uniquely identifies where the AS2 message comes from, while the TO ID uniquely identifies where it is being sent.

Figure 6

See that drop-down list box labeled 'Receipt'? (See Figure 6) The items in that box correspond to the MDN options we discussed earlier. 'None' refers to the option where no MDN will be transmitted. If you choose 'synchronous', specify a 'Receipt timeout' (See Figure 7). When that timeout value is reached, the connection will automatically disconnect.

Figure 7

As you can see from the screenshot, you may also take advantage of optional security features like:

✔ Encryption - which you specify using the 'Encryption key' and 'Encryption algorithm' settings, and

✔ Digital signing - you specify using the 'Signing key' and 'Signature algorithm' settings.

Recommended Download

That concludes our discussion on AS2 MDN. If you want to give AS2 a test run, download the FREE, fully functional evaluation edition of JSCAPE MFT Server.