Subject: CAP: IDENTIFY seems dangerous

From: John Stracke <[email-masked]>
Date: Thu, 16 Aug 2001 14:32:42 -0400

The CAP IDENTIFY command seems like it has some dangerous security 
implications. AUTHENTICATE presents credentials, then IDENTIFY can reuse 
those credentials to become a different user. The problem is that this 
requires the CS to keep the credentials stored in memory for the 
lifetime of the connection, which carries a risk of leakage (a bug which 
lets an attacker read the contents of the server's memory can expose the 
credentials for all active connections). Now, with some types of 
credentials, this may be safe; but, for others, it's not. I believe 
that, at a minimum, the server needs to be able to refuse to store 
credentials which are not safe.

More generally, it's not clear why IDENTIFY is needed at all, as a 
separate comand. Clearly, there is some need to be able to authenticate 
as a user other than the default implied by one's credentials (proxy 
access); but that doesn't have to mean switching identities at arbitrary 
times during the connection; it can be handled with an extra parameter 
to AUTHENTICATE. I believe this would be the better approach (better 
than refusing to store unsafe credentials), because it would mean that 
proxy access can be done with any sort of credentials, not just ones 
which are safe for the server to store.

-- 
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |"Why did you become a spokesmodel?" "Oh, well,|
[email-masked] <mailto:[email-masked]>|I've always liked pointing." -- _LA Story_    |
\===============================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Mon, 20 Aug 2001 16:41:03 -0500

If we drop IDENTIFY and define a syntax for presenting
authorization certificates, we could leave what the certificates
mean completely up to the implementations. Wrapping credentials
into a certificate which will work as a UPN-changing command would
be trivial, for instance, and secure over TLS.

single-use bearer certificates might help with issues of security
in the over-email protocol too.

-- 
                                           David Nicol 816.235.1187
"... raised indoors and tested by certified technicians"