AS1, AS2, AS3 - The AS1 Protocol (Enterprise only)

The AS1 protocol relies wholly on email. It was the first ASx protocol developed and established the signing, encryption and MDN conventions used in later AS2 and AS3 protocols. It is probably the easiest ASx protocol to set up and work with, but it is rarely used.

How an AS1 File Transfer Works

Like any other ASx file transfer, AS1 file transfers typically require both sides of the exchange to trade SSL certificates and specific "trading partner" names before any transfers can take place. AS1 trading partner names must really be email addresses. (AS1 is the only ASx protocol that contains this requirement.)

1. You encrypt a data file with the public key on your partner's SSL certificate and sign it with the private key of your organization's SSL certificate as you bundle everything into an AS1 message. (Both the encryption and signing steps are optional, but should be used when possible.)
2. You send the AS1 message to an email server via SMTP. Often, this will be your local email server. (Credentials and cleartext message headers may be protected with SSL transport in this step.)
3. If the AS1 message was sent to your local email server, it will now deliver it to your partner's email server using the SMTP protocol. Along the way your AS1 message may traverse several intermediate email servers as it is relayed across the Internet or corporate email infrastructure. (Cleartext message headers are rarely protected with SSL transport if relay servers are involved.) This step will be skipped if the AS1 message was delivered directly to your partner's email server in step #2.
4. Your partner will retrieve your AS1 message off your partner's local email server using the POP3 protocol. (Credentials and cleartext message headers may be protected with SSL transport in this step.)
5. If the message is encrypted, your partner will decrypt it using the private key on his/her SSL certificate. If the message is signed, your partner will validate your signature using the public key on your SSL certificate. Your partner will also use the contents of the AS1 message to verify that the data file they now have is identical to the data file you sent them.
6. If you requested an MDN delivery receipt for your data file, your partner will calculate a cryptographic hash from the data file they received, sign the hash (and some other information) with the private key on their SSL certificate and create an MDN delivery receipt message. (The signing step is optional and controlled by the original message sender.)
7. Your partner will send his/her MDN delivery receipt message to an email server via SMTP. Often, this will be your partner's local email server. (Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
8. If the MDN delivery receipt message were sent to your partner's local email server, it will now deliver it to your email server using the SMTP protocol. Along the way your partner's MDN delivery receipt message may traverse several intermediate email servers as it is relayed across the Internet or corporate email infrastructure. (The cleartext MDN delivery receipt message is rarely protected with SSL transport if relay servers are involved.) This step will be skipped if the MDN delivery receipt message was delivered directly to your email server in step #7.
9. You will retrieve your partner's MDN delivery receipt message off your local email server using the POP3 protocol. (Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
10. You will inspect your partner's MDN delivery receipt message, making sure that you can verify his/her signature using the public key on your partner's SSL certificate and that the cryptographic hash calculated from your partner's copy of your data file matches the same hash calculation from your original data file.

Variations

Direct connections to each mail server - AS1 clients can usually be configured to connect directly to your partner's email server rather than your local email server. Doing so avoids multiple "relay hops" but usually involves some additional firewall configuration.

Shared mail server - Your organization and your partner could agree to use different email accounts on the same physical email server, hosted at your data center, your partner's data center, or any other email server in the world. Doing so avoids multiple "relay hops" but usually involves some additional firewall configuration.

MOVEit Implementation of AS1

MOVEit Central is the only MOVEit product required to send or receive files using AS1. In either case files and MDNs are sent through email servers. Because virtually all organizations already have access to an email server, there are no email servers bundled with MOVEit products.

See also:

• AS1, AS2 and AS3 - Hosts - AS1
• AS1, AS2 and AS3 - Tasks - AS1 - Source
• AS1, AS2 and AS3 - Tasks - AS1 - Destination

Advantages/Disadvantages of AS1 (Compared to AS2 and AS3)

AS1 is the original ASx protocol. All of the file encryption and signing elements of ASx are present in this protocol, so the following discussion really concentrates on the SMTP/POP3 email protocol used to transport AS1 messages and MDNs receipts.

Advantage: If you have an AS1 client and access to a email server, you can send and receive AS1 transmissions. Nearly everyone connected to the Internet these days has access to an email server (you don't need to control or host the email server participating in an AS1 transmission), so AS1 is arguably the easiest of the ASx protocols to install and configure.

Advantage: Conceptually, "SMIME messages" and "MDN receipts" fit well with AS1's email-based model. If you have previously sent encrypted messages (with SMIME or PGP) and/or used delivery receipts, you already have a pretty good feel for the way AS1 works.

Advantage: AS1 is firewall-friendly. If you can send and receive email messages to and from the Internet , you can perform AS1 transfers (even if your only access is to a local email server). However, firewall issues will likely appear if you decide to perform "direct-to-remote-server" AS1 transmissions because most modern firewall rule sets only permit designated email servers to send messages to and from the internal network.

Disadvantage: Very few people use AS1. The ASx protocols really did not gain wide acceptance until AS2 was introduced; most people today use AS2 or AS3 instead of AS1.

Disadvantage: Loss of control over email relay hops. Typically, to send email, you send a message to a local email server. This server turns around and sends your message to another email server. Eventually, your message arrives at the receiver's email server, from which the message receiver can pull your message down and read it. Three common problems with this system of multiple email hops are 1) that transmission time is increased, 2) SSL enforcement is only possible on the first (usually internal) hop and 3) your AS1 encrypted messages and signed MDNs can be copied and retained by any intermediate server. To avoid these problems some people have implemented direct-to-remote-server AS1 transmissions, but these configurations usually require firewall setups that lead them to consider other ASx protocols.

Disadvantage: AS1 messages are lumped in with regular email. In most situations AS1 messages are passed through traditional email servers, which means they are subject to attachment filters, size limits, spam filters, anti-virus filters, server downtime, message queues, spam surges and other email issues that people often do not want to involve in file transfers with their partners. ("Getting our file transmissions off the mail server" is why many companies set up a dedicated secure file transfer infrastructure in the first place.)

See also: Comparison of AS1, AS2 and AS3 on the "AS1, AS2 and AS3 - Overview" page.