Secure IP Fax – Now Standard

Last fall, I blogged about a pending standard for securing facsimile communications over IP networks here and I spoke about this progress at the SIPNOC conference. Since that time, the standard, known as RFC 7345 has been approved by the Internet Engineering Task Force. The availability of a standard is very good news. There’s a common perception that fax isn’t used anymore, but there are a number of business to business (B2B) and consumer applications where fax still is common, including real estate, insurance, health care and legal applications. There are also a number of companies which provide fax by selling equipment, fax enabling technology, software or a hosted service.

So why should people or companies care about securing IP fax? Increasingly, most of our real time communications, whether by voice, fax, text or video, are transported over IP networks. Very often, they will travel over the Internet for a portion of their journey. The Internet is ubiquitous, but fundamentally unsecure unless the application or the transport layers provide security. Security can mean many different things, but is often referring to solutions for needs which include privacy, authentication and data integrity. The new RFC 7345 is designed to support these types of requirements by applying a standard known as Datagram Transport Layer Security (DTLS). One of the key reasons that the Fax over IP RFC uses DTLS is because the T.38 IP fax protocol most typically formats its signals and data using the User Datagram Protocol Transport Layer (UDPTL), unlike most real time media, which use the Real Time Transport protocol (RTP).  DTLS was designed to provide security services with datagram protocols, so it’s a good fit for T.38 IP fax.  The current version of DTLS is 1.2, which is defined in RFC 6347.

Getting a standard approved is really only the beginning. In order to get traction in the marketplace, there needs to be implementations. For example, T.38 was originally approved in 1998 by the International Telecommunications Union, but implementations did not become common until many years later, starting around 2005. In the time since, T.38 has become the most common way to send fax over IP networks and its been adopted by most of the fax eco-system.  On the plus side, a key advocate for the new standard is the Third Generation Partnership Program (3GPP), which is the standards group that drives standardization of services which will run over mobile networks, such as the emerging Long Term Evolution (LTE) network.  The SIP Forum is also continuing work on its SIP Connect interworking agreements and there is potential for including the new standard in a future version of SIPconnect.

I’ll continue to track what’s happening with respect to implementation of the standard.   As I noted in some of my previous posts, the current work on standardizing WebRTC is helping implementors to gain experience in important new standards for security, codecs and Network Address Translation (NAT) traversal. This WebRTC “toolkit” is also available in open source form.  The inclusion of DTLS in RFC 7345 joins the pending RTCWeb standards in providing new applications and use cases for these emerging standards. This will be good news for the user community, as features which were previously available only in proprietary get implemented in variety of products and services.  If you know of any plans in motion or want to learn more, please feel free to comment or get in touch with me.  You can also learn more by checking out my presentation on Securing IP Fax.

James Rafferty has been active in the worlds of telecommunications, standards and university teaching in a variety of roles. He's been a thought leader in areas such as Voice over IP and Internet fax through his consulting, product management, marketing, writing and standards activities, and he is currently teaching business at Northeastern University. He loves to write and talk about new connections, applications and business models as communications, related technologies and business concepts evolve.

8 Comments

  1. Very interesting, I was not aware of RFC7345.
    Two questions:
    – currently there already exists the RTP/SAVP mechanism that has similar capabilities. Why define a new mechanism UDP/TLS/UDPTL? How do you expect “market” will switch to UDPTL over DTLS if it did not do so for RTP/SAVP?
    – more fundamental: what is the threat model, what are you trying to protect? From the end-user point of view, protecting the T.38 stream (IFP packets) is not enough, you want to protect the fax communication between fax machines, including the part of the data path that does not use IP, e.g. PSTN path between a T.38 Gateway and analog/ISDN fax machine.

    Therefore the protection effort should be done at the T.30 level, between T.30 endpoints. Not at transport level. (and obviously this will not require any change in SDP)

    Annex G and Annex H of T.30 may need updates/improvements. But T.30 is the standard that has to be worked on if you want secure end-to-end fax communication.

    • Hi Bruno. Thanks for your comment.

      On the first point, it would have been better if RTP had been used in the beginning for T.38 instead of UDPTL, but by the time RTP for fax was added to T.38, the early implementations were all in UDPTL. There’s been no sign that will change. In light of that, the authors of the draft RFC decided to add security to UDPTL and those of us who reviewed the draft agreed with that approach. DTLS is in the process of being implemented for WebRTC, so there is already code available so that it can also be used for other purposes.

      On the second point, some of my comments on the draft were indeed to clarify the threat model and additional work was done on that prior to standardization. In my presentation at SIPNOC, I focused on privacy, authentication and data integrity as the threats to be addressed. I helped contribute to the original sections of T.30 on security, but there was minimal implementation activity despite the inclusion of a fairly robust threat model. The new RFC should work fine for IP to IP links, and thus fits a lot of the current models where the concern is regarding, for example, SIP trunks that need to travel over public IP networks.

      But your points are valid. A more comprehensive security approach would also encompass the PSTN portion.

      • [1] Well, it looks like the overall track for development of RFC7345 has been “now that we have DTLS, how are we going to use it?”, and T.38 has been found a good candidate. Why not.

        I also find it misleading to claim that fax over T.38 is now secure. It’s only true on the T.38 path.
        At least a reminder in the RFC (maybe in “Security considerations”) could have been inserted, warning for example on the remaining weakness on the T.30 Gatewayfax machine link.
        Also, in this RFC, the first figure showing the protocol stack could have been made more transparent. It should have shown T.30. Above the “Internet facsimile protocol” (IFP) box there should also be a “T.30” box. After all, it’s the existence of T.30 that mandates the existence of the IFP box. Hiding this is suspicious.

        If there are T.38 gateways in the fax communication path, end-user is still at risk.
        If there is no T.38 Gateway in the path, this means that you have two IAFs. In this case both IAFs are better off negotiating TCP for T.38 transfer (fax can then go through at much higher speed and are guaranteed error-free). Equivalent security must then be implemented with TLS.

        [2] Now, I have another issue. Unfortunately, I am not an expert in security, I just know a little. My understanding however is that if the clear contents of a ciphered datagram is known, it makes it much easier to “break the code”.

        At the beginning of a T.38 communication, the T.38 transmitter invariably sends:
        (optional)
        (optional)
        (after some time, in order to initiate TSI/DCS transmission).
        [If T.38 start in V.34 mode, you get the // dialog.]

        This means that an intruder gaining access to the stream of UDP packets should be able to easily guess where the DTLSed- packet is (vey easy), its IFP sequence number, the possible repetition of previous datagrams.
        I think that with this information the time needed to break ciphering could be extremely reduced.

        What do you think?

        Best regards,
        Bruno Bonnefont

  2. Good discussion. There is a tendency to see security as a series of solution, but in reality, each use case has its nuances. A security tool is not a hammer that automatically solves all potential attacks.

    I’ll reply a bit to your points.

    1) Without DTLS, adding security to UDPTL would have been a one-off solution versus being able to take advantage of a standard (DTLS) which has been vetted by the security and applications community and is already up to revision 2.1. So yes, having DTLS provided a path forward, which the new RFC took advantage of.

    In principle, the T.38 standard was incorporated by normative reference, as was T.30, so the IFP is defined in T.38. Depending upon where you are in T.38, it could actually be T.38 signaling or T.4 / T.6 image content. When I taught a T.38 IP fax course, I did drill down to explain what actually was in the IFP packets.

    Security solutions really do need to be fined tuned to the use case. RFC 7345 is another item in the security toolkit, but only addresses security aspects for UDPTL use cases. If IAFs were used on both sides, with TCP instead of UDP (hence, no UDPTL), I don’t see any reason why TLS could not be applied, since it is designed for TCP use cases.

    For a hybrid path where portions are UDPTL and parts are T.30, the implementor would need to decide how important it is to secure the various portions of that path. Unfortunately, most if not all fax enabling technology has not included support for the T.30 security annexes.

    2) I’m also not an expert in breaking ciphers. The T.30 signal portions are rather predictable, but the ciphers used for authentication and encrypting the data path are designed to be hard to break. It’s possible with enough computing power (ala some NSA style deciphering approaches), but public key encryption raises the bar a lot and makes it safe from most brute force attacks. An example of how this plays out is the concerns security agencies are raising over encryption built into the recent iPhones, where they’re upset about the lack of “backdoor” access to the keys.

  3. This is an excellent write up, a ton of good points and information. James you may want to check out etherFAX SEN. There is a pretty good write up on how we provide end-to-end encryption. Although we are bypassing T.38 and the telco completely. We have been preaching the lack of security in T.38 since the inception of etherFAX.

    • Hi Paul. Thanks for your feedback and the pointer to your company’s solution. The end users and vendors didn’t worry too much about fax security over the PSTN, but the need for security became much more obvious over IP networks. With all of the various hacking incidents in recent years, the need for protecting communications has become more clear. In advance of standards, it’s useful for vendors to offer choices such as your company has with etherFax SEN. If customers see the need, it drives more action by the suppliers.

  4. James in response to your comment “The end users and vendors didn’t worry too much about fax security over the PSTN” I could not agree more. I think it is tough for phone companies to preach the “conduit clause” and expect their customers to look the other way and or be satisfied.

Leave Comment

Your email address will not be published. Required fields are marked *