Security During Transmission of MeF Returns Using the Internet
Transmitters use the internet to transmit electronic return data to the IRS Modernized e-File (MeF) system. The design of the Internet Filing Application (IFA) and Application to Application (A2A) features Web Services-Interoperability (WS-I) security standards as discussed in more detail below.
The IRS MITS Cyber Security organization ensures all IRS systems used to receive, process and store tax return data are secure. Any and all access to tax return data is protected, fully controlled, monitored, verified, and logged for analysis of potential abusive or malicious purposes.
OMB Circular A-130 and the Federal Information Security Management Act (FISMA) (Title III of the E-Government Act (P.L.107-347)) require major applications such as MeF to undergo a Certification and Accreditation (C&A) Process.
Certification is a formal review and test of the security safeguards implemented to determine whether the system provides adequate security that is commensurate with the risk of operating the system on the IRS information technology infrastructure.
Accreditation is the formal authorization by the Executive Level Business Owner responsible for the operation of the MeF system and the explicit security.
Specific guidance is provided by various National Institute of Standards (NIST) special publications (the “800” series.) The process must include formal review and testing of the design and implementation of the system’s security controls. The IRS MITS Cyber Security organization and the business system owner were jointly responsible and actively involved in completing the IRS C&A Process for MeF.
IFA and A2A are hosted within the IRS Modernized System Infrastructure and are accessed through the Registered User Portal (RUP).
Transmitters using IFA are required to use their e-Services user name and password in order to log into the RUP. They also select their Electronic Transmitter Identification Number (ETIN) prior to transmitting returns. Once the transmitter successfully logs into the RUP, the Secure Socket Layer (SSL) Handshake Protocol allows the RUP and transmitter to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the first byte of return data is transmitted. This connection is private. The transmitter’s Browser and the RUP negotiate a secret encryption key for encrypted communication between the transmitter and the MeF system. This secret key is shared only between the transmitter and the RUP and is not known to any individual. The transmission is part of a secure communications protocol HTTPS/SSL. The strength of the encryption key used determines the degree of difficulty for anyone to decode the key and thereby decode the return data. IRS uses SSL 3.0 128-bit encryption for access to the RUP. The key created for each transmission is almost impossible to break since using 128-bit creates as many combinations as the number of water molecules in 2.7 million Olympic-size swimming pools. The secure SSL tunnel also protects the return data from being intercepted while in transit.
As of January 2009, transmitters using A2A will be required to use Strong Authentication when invoking A2A web services. A system with a Third-Party Transmitter or State application will access the appropriate uniform resource locator (URL) at the Registered User Portal (RUP) with the appropriate simple object access protocol (SOAP) envelope and attachment via HTTPS, supply the required security information for authentication and then invoke the MeF infrastructure and application. MeF will accommodate only one type of user credentials for authentication and validation of A2A transmitters; username and X.509 digital security certificate. Strong Authentication users must have a valid X.509 digital security certificate obtained from an IRS authorized Certificate Authority (CA) (like ORC or IdenTrust) and have their certificates stored in the IRS directory using Automated Enrollment. Only those users who have enrolled with the IRS as Strong Authentication users can use this approach to authenticate their identity when using A2A Web Services. Strong Authentication users are authenticated via their X.509 digital certificate in lieu of a password. They do not specify their Application System ID or password in the wsse:UsernameToken elements of the WS Security header. However, every A2A service request requires the Application System ID of the user. The AppSysId element of the MeF Header (mandatory for all service requests from Strong Authentication users) satisfies this requirement. More information and the specifications for Strong Authentication can be found on the Web in the W3C/IETF specification RFC 3275 - (Extensible Markup Language) XML-Signature Syntax and Processing (IETF Identifier: draft-ietf-xmldsig-core-2-03.txt) and in the OASIS Web Services security specification WSS:SOAP Message Security (WS-Security 2004) (OASIS Identifier. wss-v1.1-spec-os-SOAPMessageSecurity).