InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
Browse Prior Art Database

Using TLS with IMAP, POP3 and ACAP (RFC2595)

IP.com Disclosure Number: IPCOM000003182D
Original Publication Date: 1999-Jun-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 12 page(s) / 30K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C. Newman: AUTHOR


Status of this Memo

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 10% of the total text.

Network Working Group C. Newman

Request for Comments: 2595 Innosoft

Category: Standards Track June 1999

Using TLS with IMAP, POP3 and ACAP

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1999). All Rights Reserved.

1. Motivation

The TLS protocol (formerly known as SSL) provides a way to secure an

application protocol from tampering and eavesdropping. The option of

using such security is desirable for IMAP, POP and ACAP due to common

connection eavesdropping and hijacking attacks [AUTH]. Although

advanced SASL authentication mechanisms can provide a lightweight

version of this service, TLS is complimentary to simple

authentication-only SASL mechanisms or deployed clear-text password

login commands.

Many sites have a high investment in authentication infrastructure

(e.g., a large database of a one-way-function applied to user

passwords), so a privacy layer which is not tightly bound to user

authentication can protect against network eavesdropping attacks

without requiring a new authentication infrastructure and/or forcing

all users to change their password. Recognizing that such sites will

desire simple password authentication in combination with TLS

encryption, this specification defines the PLAIN SASL mechanism for

use with protocols which lack a simple password authentication

command such as ACAP and SMTP. (Note there is a separate RFC for the


There is a strong desire in the IETF to eliminate the transmission of

clear-text passwords over unencrypted channels. While SASL can be

used for this purpose, TLS provides an additional tool with different

deployability characteristics. A server supporting both TLS with

simple passwords and a challenge/response SASL mechanism is likely to

interoperate with a wide variety of clients without resorting to

unencrypted clear-text passwords.

The STARTTLS command rectifies a number of the problems with using a

separate port for a "secure" protocol variant. Some of these are

mentioned in section 7.

1.1. Conventions Used in this Document


"MAY", and "OPTIONAL" in this document are to be interpreted as

described in "Key words for use in RFCs to Indicate Requirement

Levels" [KEYWORDS].

Terms related to authentication are defined in "On Internet

Authentication" [AUTH].

Formal syntax is defined using ABNF [ABNF].

In examples, "C:" and "S:" in...