Opportunistic encryption: Difference between revisions
imported>Sandy Harris No edit summary |
imported>Sandy Harris No edit summary |
||
Line 9: | Line 9: | ||
Like any encryption scheme, an OE system must rely on some form of [[information security#source authentication|source authentication]]. It does no good at all to encrypt messages so that only the recipient can read them unless the recipient is who you think it is. Different OE designs rely on different authentication mechanisms; see individual articles for details. | Like any encryption scheme, an OE system must rely on some form of [[information security#source authentication|source authentication]]. It does no good at all to encrypt messages so that only the recipient can read them unless the recipient is who you think it is. Different OE designs rely on different authentication mechanisms; see individual articles for details. | ||
== Systems using OE == | == Systems using OE == | ||
The term "opportunistic encryption" comes from the [[FreeSWAN | FreeS/WAN]] project, who built OE into a [[Linux]] implementation of [[IPsec]]. They relied on [[DNS]] to manage authentication data. RFC 4322 "Opportunistic Encryption using the Internet Key Exchange (IKE)" documents that design. Used alone, this would be secure against [[passive attack]]s; add [[DNS security]] to protect the authentication data and it is also secure against [[active attack]]s. | The term "opportunistic encryption" comes from the [[FreeSWAN | FreeS/WAN]] project, who built OE into a [[Linux]] implementation of [[IPsec]]. They relied on [[DNS]] to manage authentication data. RFC 4322 "Opportunistic Encryption using the Internet Key Exchange (IKE)" documents that design. Used alone, this would be secure against [[passive attack]]s; add [[DNS security]] to protect the authentication data and it is also secure against [[active attack]]s. | ||
Another way to avoid some of the administrative overheads of [[IPsec]] is [[better-than-nothing security]], IPsec done without authentication. This is secure against [[passive attack | passive eavesdroppers]] who only try to listen in; encrypting the connection stops them. However, unlike either normal IPsec or OE, it is completely insecure against [[active attack]]ers who may try to trick systems into communicating with them instead of legitimate partners; you need authentication to block that. | |||
The most widely deployed OE system encrypts server-to-server [[SMTP]] mail transfers. The original implementation was [http://portal.acm.org/citation.cfm?id=1039836 ssmail] or Secure Sendmail. The current standard is RFC 3207. This does not provide all of the benefits of end-to-end mail encryption systems such as [[PGP]]; in particular it provides no protection against an enemy with privileged access to one of the mail servers involved, or against someone monitoring the connection between the user and the mail server. However, it does prevent attacks at routers between the mail servers. It provides partial protection against wholesale mail monitoring, forcing a government that wants to do large-scale monitoring either to subvert mail servers or to get the server owners to co-operate. | The most widely deployed OE system encrypts server-to-server [[SMTP]] mail transfers. The original implementation was [http://portal.acm.org/citation.cfm?id=1039836 ssmail] or Secure Sendmail. The current standard is RFC 3207. This does not provide all of the benefits of end-to-end mail encryption systems such as [[PGP]]; in particular it provides no protection against an enemy with privileged access to one of the mail servers involved, or against someone monitoring the connection between the user and the mail server. However, it does prevent attacks at routers between the mail servers. It provides partial protection against wholesale mail monitoring, forcing a government that wants to do large-scale monitoring either to subvert mail servers or to get the server owners to co-operate. | ||
The [http://ralyx.inria.fr/2005/Raweb/planete/uid20.html Planete] project are building OE for [[IPv6]]. They claim "Unlike existing schemes (e.g. FreeS/WAN), our proposal does not rely on any global Third Trusted Party (such as DNSSEC or a PKI). Hence, we claim it is more secure, easier to deploy and more robust." | The [http://ralyx.inria.fr/2005/Raweb/planete/uid20.html Planete] project are building OE for [[IPv6]]. They claim "Unlike existing schemes (e.g. FreeS/WAN), our proposal does not rely on any global Third Trusted Party (such as DNSSEC or a PKI). Hence, we claim it is more secure, easier to deploy and more robust." |
Revision as of 08:02, 3 March 2010
Opportunistic encryption, often abbreviated OE is the attempt to arrange network communication systems so that any two nodes can encrypt their communication, without any connection-specific setup by the system administrators. Once two machines are set up for OE, they can set up secure connections automatically.
One large benefit is a reduction in administrative workload. If the administrators must set up every connection, the effort required for a fully connected network of N machines scales by N2. There are several ways to avoid this disaster on large networks, including using a centralised authentication system such as Kereberos, or putting in hardware to encrypt at link level, or IPsec to encrypt at network level. Any of these can reduce the workload to something manageable. OE, however, cuts the Gordian knot. For OE, the effort scales linearly; the work to set up N machines for OE is just N.
Another benefit is that more connections may be encrypted. Once OE is set up, any two OE-capable machines can secure their connections. If OE is sufficiently widespread, secure connections can be the default.
Like any encryption scheme, an OE system must rely on some form of source authentication. It does no good at all to encrypt messages so that only the recipient can read them unless the recipient is who you think it is. Different OE designs rely on different authentication mechanisms; see individual articles for details.
Systems using OE
The term "opportunistic encryption" comes from the FreeS/WAN project, who built OE into a Linux implementation of IPsec. They relied on DNS to manage authentication data. RFC 4322 "Opportunistic Encryption using the Internet Key Exchange (IKE)" documents that design. Used alone, this would be secure against passive attacks; add DNS security to protect the authentication data and it is also secure against active attacks.
Another way to avoid some of the administrative overheads of IPsec is better-than-nothing security, IPsec done without authentication. This is secure against passive eavesdroppers who only try to listen in; encrypting the connection stops them. However, unlike either normal IPsec or OE, it is completely insecure against active attackers who may try to trick systems into communicating with them instead of legitimate partners; you need authentication to block that.
The most widely deployed OE system encrypts server-to-server SMTP mail transfers. The original implementation was ssmail or Secure Sendmail. The current standard is RFC 3207. This does not provide all of the benefits of end-to-end mail encryption systems such as PGP; in particular it provides no protection against an enemy with privileged access to one of the mail servers involved, or against someone monitoring the connection between the user and the mail server. However, it does prevent attacks at routers between the mail servers. It provides partial protection against wholesale mail monitoring, forcing a government that wants to do large-scale monitoring either to subvert mail servers or to get the server owners to co-operate.
The Planete project are building OE for IPv6. They claim "Unlike existing schemes (e.g. FreeS/WAN), our proposal does not rely on any global Third Trusted Party (such as DNSSEC or a PKI). Hence, we claim it is more secure, easier to deploy and more robust."