Chapter 6

Using an OE security gateway, you can use a single IPsec-capable machine to enable OE communication to all servers on your network. This allows you to protect a whole cluster of Microsoft Windows machines that do not support OE. Only the LAN traffic between the OE security gateway and the Windows machines is unencrypted, but that should be part of your trusted (switched) network to begin with.

DNS Key Records

Back in 1996, there was no DNSSEC, which meant no specific DNS records for public keys were available. So the only record type that could be used to store the public key was the TXT record. When the first part of the DNSSEC specification was finished and implemented, it resulted in a new record, the KEY record. Although this record was originally meant for both DNSSEC and third-party applications that needed to publish public keys, and these KEY records could be subtyped, mixing DNSSEC and third-party key records came to be viewed as bad practice. RFC 3445 specified that the KEY record should only be used by DNSSEC, and other protocols should specify their own new records.

For IPsec, the IPSECKEY record was introduced. During all this time, the only reliable DNS record to use for OE had been the TXT record. Many DNS implementations never implemented the KEY record, and the IPSECKEY record is so new it hasn't yet even been implemented in the reference implementation of the IETF, the ISC Bind name server.

Together with the BGP protocol, the DNS protocol forms the core of the Internet. Without these two protocols, there would be no Internet. That is why the IETF was extremely reluctant to change anything in them, even though both protocols really needed security features. For the DNS protocol, the changes have finally been made, and the RFCs were published in the first few months of 2005. But most name servers on the Internet have not yet been updated to recognize all the new DNS record types. For the moment therefore, we recommend using both the new official IPSECKEY record and the old-style TXT record. In another year or two, the TXT records can probably be retired.

Forward and Reverse Zones

It is important to remember that there are two more or less different types of zones. These are commonly referred to as the forward and the reverse zones. The forward zone contains information indexed by name. For instance it contains an address (A) record showing that www.openswan.org has the IP address 193.110.157.129. The reverse zone does the opposite. It is indexed by IP address, and gives the host name for a certain IP address. To delegate this in a proper hierarchy, the reverse zone used is the IN-ADDR.ARPA. zone. The entry for 193.110.157.129 in the reverse zone is located at 129.157.110.193.IN-ADDR.ARPA., and

contains a pointer (PTR) record to the name www.openswan.org. Both types of zones can contain additional information, such as MX (mail) records, free text (TXT) records, aliases (CNAME), or even SSH hostkey fingerprint (SSHFP) records.

135

Opportunistic Encryption

The OE DNS Records

We will describe the three different records that we will be using. Currently, the TXT record is the most reliable, since all name server software supports this type of record. Support for the KEY record for OE will be discontinued now that the RFCs have reserved these records for DNSSEC keys. Instead, the IPSECKEY record is the new record for use with IPsec OE.

For example, the server at lists.openswan.org supports OE and has a DNS record to indicate this at 77.157.110.193.IN-ADDR.ARPA.:

# host lists.openswan.org

lists.openswan.org has address 193.110.157.77

# host -t txt 77.157.110.193.in-addr.arpa.

77.157.110.193.IN-ADDR.ARPA text "X-IPsec-Server(10)=193.110.157.77" "AQNxf6caK ULJklYZycuo66Ko0U+iHaJUDr0QZHnG4MJ9IRNYi5H6kPxcwKIXkg+OGo+NeUyyWDEc+ox2 7BFYViAHQNEyBRLZu0kyE681h+cHm7lfCSy0AOEBSCyZF3aGcL8GWxVhtimpJQ4tNxXZg7t LX5sfYw8mZnUBjkHvyccIred/q3cNWbDlq2WU4TL+NBb5FnxXi9Hk/SRV7sMe56fvZuXkcJu4e 2C7uocltzzF1b0BZx7yeXwHjzqAWn" "W/UA54fbSTvzgnrpSC+FMuhWTI1EdxcqGaOFIjGWWGV2nxg/QaPU9i8vpwFwrEEdCJTiqlb Y YNudblg4vYthnVNez0/RkfZHfhAaHdbJRSaQzOu88h"

First we need to put a marker in the TXT record to differentiate this from other TXT records that have nothing to do with IPsec, for example the anti-spam SPF records that also use the TXT record to store their data. This is why our TXT record starts with X-IPsec-Server.

The number in brackets shows the preference in a similar way to the mail (MX) record. You can have multiple OE gateways that lead to the host you are trying to reach. The lower the number, the higher the preference, as for MX records.

Next follows the IP address of the host's OE gateway, or its own IP address if it is capable of OE itself. This allows you to have one OE-capable gateway that will run OE for an entire subnet of machines behind it. If the gateway IP address is different from the host's IP address, an IPsec connection is made to the gateway, and it is assumed that the gateway can securely reach the host that is advertising the use of that gateway.

Finally, the raw key material of the public key follows.

Different Types of OE

Servers that are willing to respond to OE from initiating clients advertise this capability in a DNS record tied to their (static) IP address. Clients on a static IP address can do the same. Clients that are on dynamic IP, that is to say, they frequently change their IP address, can still publish their public key, but they will have to do that in a forward zone they control. When the client initiates the IPsec connection, after having read the server's DNS record confirming it can do OE, it will send a special leftid= option giving its own FQDN. So if the client on a dynamic IP is called

laptop.xelerance.com, then its OE connection will use leftid=@laptop.xelerance.com. This

ID is protected by the IKE protocol. When the server running OE sees this special ID, it will not try to look up the OE record based on the client's IP address, but instead will look for a DNS record in the forward zone at laptop.xelerance.com. As long as one of the two sides gets its authority from its IP address, and the corresponding record in the reverse, this process is safe.

136