Subject: [Extra] Secdir last call review of draft-ietf-extra-imap-unauth-00

From: David Waltermire <[email-masked]>
Date: Tue, 29 May 2018 10:50:12 -0700

Reviewer: David Waltermire
Review result: Has Nits

This standards track draft adds a new state transition to IMAP allowing the
current authentication context to be reset to an non-authenticated state using
the UNAUTHENTICATE command. This allows a client to issue the IMAP AUTHENTICATE
command with administrative credentials to act on behalf of other users,
without having to create a new connection for each user, providing for greater
efficiency.

This draft appears to be ready for publication, with some relatively minor nits
to improve readability.

Section 4.1: The requirements in this list go beyond the stated requirement to
reset connection state. Some text should be added to make it clear that the
list defines additional behavior to be followed.

Something like the following could be used to address this:

s/This lists some IMAP extensions that have connection state that/The
connection state for the following list of IMAP extensions/

Append to the end of the paragraph "Additional requirements apply to specific
extensions as follows:".

---

From: Michael Peddemors <[email-masked]>
Date: Tue, 29 May 2018 11:02:21 -0700

Does anyone have the thread for any previous discussions on this one?

There are concerns I have, eg backwards compatability, and the increased 
risk of this being used as an attack vector (auth attacks, and the need 
for IMAP developers to address those attack vectors before implementing)

On 18-05-29 10:50 AM, David Waltermire wrote:
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
> 

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: "Chris Newman" <[email-masked]>
Date: Wed, 30 May 2018 00:10:36 -0700

> Does anyone have the thread for any previous discussions on this one?

Most discussions have been face-to-face or implementation experience. 
There was some discussion on the imapext list several years ago.

> There are concerns I have, eg backwards compatability,

I'm not aware of any backwards compatibility issues. If it's advertised, 
clients can use it. Otherwise clients can't use it and have to close the 
socket and open a new one to perform this operation.

> and the increased risk of this being used as an attack vector (auth 
> attacks, and the need for IMAP developers to address those attack 
> vectors before implementing)

It's not in-scope for this document to cover attacks on the 
authentication operation itself. SASL covers that reasonably well, by 
indirect reference. If you feel the document is missing an attack vector 
that's in-scope, I'd welcome additional text. The security 
considerations section is the primary reason I consider this worth the 
effort of standardization rather than living with the status quo 
deployed non-standard mechanism.

FYI, this is primarily intended to enable interoperability between 
administrative IMAP clients and IMAP servers when those components come 
from different vendors and also to get those vendors thinking about 
security considerations they might miss when doing an ad-hoc solution 
(as has been necessary so far). The document is not targeted for 
end-user IMAP clients.

		- Chris