Microsoft Active Directory (AD) is a type of external authentication that can provide rich details about authenticated users, including email address, group membership and client certificates.
AD is essentially an extended version of LDAP optimized for Windows environments, but AD is only available from Microsoft. As such, AD (LDAP) connections use TCP port 389 but can (and should) be secured with SSL. When AD (LDAP) is secured in this manner, it typically uses TCP port 636 and is often referred to as “LDAPS”.
BEST PRACTICE: Use SSL secured connections to AD whenever possible; the information these data streams contain should be treated like passwords in transit. Store as much information about the user in AD as your file transfer technology will permit; this will improve your ability to retain centralized control of that data and allow you to easily switch to different file transfer technology if your needs change.
AD (pronounced “ay, dee”) is an abbreviation for Microsoft Active Directory, a very common external authentication system used in the file transfer industry to centralize authentication, user account information and access control.
See “Active Directory” for more information.
AES (“Advanced Encryption Standard”) is an open encryption standard that offers fast encryption at 128-bit, 192-bit and 256-bit strengths.
AES is a symmetric encryption algorithm often used today to secure data in motion in both SSH and SSL/TLS. (After asymmetric key exchange is used perform the handshake in a SSH or SSL/TLS sessions, data is actually transmitted using a symmetric algorithm such as AES.)
AES is also often used today to secure data at rest in SMIME, PGP, AS2, strong Zip encryption and many vendor-specific implementations. (After asymmetric key exchange is used to unlock a key on data at rest, data is actually read or written using a symmetric algorithm such as AES.)
Rijndael is what AES was called before 2001. In that year, NIST selected Rijndael as the new AES algorithm and Rinjdahl became known as AES. NIST validates specific implementations of AES under FIPS 140-2, and several hundred unique implementations have now been validated under that program.
See the Wikipedia entry for AES if you are interested in the technical mechanics behind AES.
BEST PRACTICE: All modern file transfer clients and file transfer servers should support FIPS-validated AES, FIPS-validated 3DES or both. (AES is faster, may have more longevity and offers higher bit rates; 3DES offers better backwards compatibility.)
AndFTP is a free, full-featured, interactive FTP client for Android smartphones and devices. It was created by Lysesoft, a company specializing in Android phone file transfer client development.
AndFTP offers support for FTP, FTPS, SFTP and can remember a large number of connection profiles. FireFTP does not yet (as of version 2.4) supports integrity checks using MD5/SHA1 or file compression on the fly (i.e., “MODE Z”), but it does already support multiple languages, ESPV and IPv6.
AndFTP’s official site is http://www.lysesoft.com/products/andftp/.
ANSI X.9 (or “ANSI/X.9”) is a group of standards commonly used with bulk data transmissions in item processing and Fed transfers.
An example of an ANSI X.9 standard is “ANSI X9.100-182-2011” which covers how XML can be used to deliver bulk data and images.
Published ANSI standards may include some technical artifacts such as XML XSD documents, but typically rely on specific maps set up in specific transformation engines to completely integrate with backend systems.
AS1 (“Applicability Statement 1”) is an SMIME-based transfer protocol that uses plain old email protocols (such as SMTP and POP3) to transmit files with end-to-end encryption and guaranteed delivery/non-repudiation (when MDNs are in use).
End-to-end encryption is accomplished through the use of asymmetric encryption keyed with the public and private parts of properly exchanged X.509 certificates. Guaranteed delivery is accomplished through the use of strong authentication and signing, also through the use of the public and private parts of properly exchanged X.509 certificates.
AS1 is an unpopular implementation of the AS2 protocol, at least for new implementations. Many vendors successfully sell software that supports AS2 but not AS1 or AS3. However, AS1’s design as an email-based protocol allows many companies to implement it without investing in extra file transfer technology at their perimeters; they simply need to implement AS1 internally and make sure it can access email.
See also “AS2” for the HTTP-based variant and “AS3” for the FTP/S-based variant.
AS2 (“Applicability Statement 2”) is an SMIME-based transfer protocol that uses HTTP/S to transmit files with end-to-end encryption and guaranteed delivery/non-repudiation (when MDNs are in use).
There are two main reasons that AS2-based transmission systems are unpopular unless specifically requested by particular partners are complexity and cost.
In terms of complexity, AS2 configurations can involve up to four different X.509 certificates on each side of a transfer, plus hostnames, usernames, passwords, URLs, MDN delivery options, timeouts and other variables. Configuration and testing of each new partner can be a full or multi-day affair, where simpler protocols such as FTP may require hours or minutes. To hide as much of the configuration complexity as possible from administrators, some AS2 products (such as Cleo’s Lexicom) come with dozens or hundreds of preconfigured partner profiles, but knowledge of the underlying options is still often necessary to troubleshoot and deal with periodic updates of partner credentials or workflows.
In terms of cost, AS2 products that can connect to multiple trading partners are rarely available for less than ten thousand dollars, and the ones that ship with well-developed list of partner profiles cost much more than that. One factor that drives up this cost is that any marketable AS2 product will be “Drummond Certified“. The cost of high-end AS2 products is driven up by the fact that compiling and keeping up an extensive library of partner profiles in an expensive endeavor in its own right. Implementing AS2 securely across a multiple-zone network also tends to drive up costs because intermediate AS2 gateways are often required to prevent direct Internet- or partner-based access to key internal systems.
Another factor working against voluntary AS2-based implementations is transfer speed. The use of HTTP-based encoding and the requirement that MDNs are only compared after the complete file has been delivered often tips the operational balance in favor of other technology.
AS3 was developed, in part, to cope with AS’s slow HTTP-based encoding, but other modifications (“optional profiles“) to the AS2 protocol have also been introduced to address other limitations. For example, the optional “AS2 Restart” feature was introduced industry-wide to cope with large files whose delivery was heretofore dependent on long-lasting, unbroken HTTP streams.
Nonetheless, AS2 is considered to be the most successful and most widely adopted of any vendor-independent file transfer protocol that builds both transmission security and guaranteed delivery into the core protocol.
See also “AS1” for the email-based variant, “AS3” for the FTP-based variant and “AS2 optional profiles” for additional information about available AS2 features.
AS2 optional profiles (also “optional AS2 profiles”) are features built into the AS2 protocol but not used by every Drummond certified vendor. However, the Drummond Group does validate seven different optional profiles (nine total) and these are briefly covered below.
Certificate Exchange Messaging (CEM) – A standard way of exchanging certificates and information about how to use them.
Multiple Attachments (MA) – Simply the ability to transmit multiple files in a single AS2 transmission.
FileName preservation (FN) – Adds metadata to AS2 transmissions to preserve original filenames. “FN-MA” covers AS2 transmissions without MDNs and “FN-MDN” covers transmissions with MDNs.
Reliability – Provides an application standard around retry, IDs and related matters to prevent double posts.
AS2 Restart – Allows larger files, including those over 500MB, to be sent over AS2.
Chunked Transfer Encoding (CTE) – Permits transmission of data sets that are still being generated when transmission starts.
BEST PRACTICES: The most useful AS2 optional profiles for file transfer are usually MA (multiple attachments) and FN (filename preservation). Your AS2 software should support all of these. If you transmit files larger than a few megabytes with AS2, then AS2 restart is also a must. Other options may be useful on a case-by-case basis.
AS3 (“Applicability Standard 3”) is an SMIME-based transfer protocol that uses FTP/S to transmit files with end-to-end encryption and guaranteed delivery/non-repudiation (when MDNs are in use).
AS3 is an unpopular implementation of the AS2 protocol. Many vendors successfully sell software that supports AS2 but not AS1 or AS3. However, AS3’s design as an FTP-based protocol allows many companies to implement it with minimal file transfer technology investments at their perimeters; they simply need to implement AS3 internally and make sure it can access a plain old FTP/S server exposed to the Internet.
See also “AS1” for the email-based variant and “AS2” for the HTTP/S-based variant.