Re: [apps-discuss] Extentions of IMAP4

Dave Cridland <dave@cridland.net> Tue, 26 July 2011 09:44 UTC

Return-Path: <dave@cridland.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2B921F8B6B for <apps-discuss@ietfa.amsl.com>; Tue, 26 Jul 2011 02:44:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.241
X-Spam-Level:
X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, J_CHICKENPOX_72=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-w2VCCgAzfP for <apps-discuss@ietfa.amsl.com>; Tue, 26 Jul 2011 02:44:16 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 812CC21F8B9F for <apps-discuss@ietf.org>; Tue, 26 Jul 2011 02:44:15 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 1E64B1168087; Tue, 26 Jul 2011 10:44:13 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CwQeccOQBUI; Tue, 26 Jul 2011 10:44:09 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id B299B1168067; Tue, 26 Jul 2011 10:44:08 +0100 (BST)
References: <OF39FC2C3F.DFBBB156-ON482578D9.002E6203-482578D9.002F850F@zte.com.cn>
In-Reply-To: <OF39FC2C3F.DFBBB156-ON482578D9.002E6203-482578D9.002F850F@zte.com.cn>
MIME-Version: 1.0
Message-Id: <9031.1311673448.731712@puncture>
Date: Tue, 26 Jul 2011 10:44:08 +0100
From: Dave Cridland <dave@cridland.net>
To: "luyan@zte.com.cn" <luyan@zte.com.cn>, General discussion of application-layer protocols <apps-discuss@ietf.org>, "ding.xin@zte.com.cn" <ding.xin@zte.com.cn>, "jiaxw9@chinaunicom.cn" <jiaxw9@chinaunicom.cn>, "SHIH, JERRY \(ATTSI\)" <JS9053@att.com>
Content-Type: text/plain; delsp="yes"; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8Bit
Subject: Re: [apps-discuss] Extentions of IMAP4
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 09:44:16 -0000

On Tue Jul 26 09:36:35 2011, luyan@zte.com.cn wrote:
> > On Fri Jul 22 09:12:35 2011, luyan@zte.com.cn wrote:
> > > [Yan LU] The intention of this draft is to associate multiple
> > > identities
> > > belonging to one user. Thus, after logging in, the user may  
> choose
> > > one of
> > > these associated identities, under each of which there can be an
> > > INBOX, a
> > > SENTBOX and other folders, as shown in the following figure.
> >
> > OK. In the SASL model, an authentication identifier can have  
> access
> > to many authorization identifiers already; so no change is needed
> > here.
> >
> 
> [Yan LU] As we know, implicit registration has already been  
> supported in
> 3GPP IMS. However,so far, I haven’t found any RFCs where an
> authentication identifier is allowed to be bound with multiple  
> identifiers
> . Could you tell me the specific documents?
> 
> 
All modern SASL mechanisms allow users to supply an optional  
authorization identifier.

> > Mostly because you're not - you're associating authorization
> > identities sequentially, rather than concurrently.
> >
> > You could build on namespaces, incidentally, to achieve much the  
> same
> > goal, by simply defining a standard method for locating other
> > authorization identifiers' INBOXes.
> >
> > But allowing a user to switch authorization identifier mid-flow  
> will
> > almost certainly introduce some complex edge-cases within  
> security -
> > I've a strong feeling that this opens up possibilities for TOCTOU
> > errors.
> >
> 
> [Yan LU] Actually, the idea in the proposed draft is quite similar  
> with
> implicit registration in 3GPP, where it has already been  
> standardized. So,
> we think it is better for the IETF to support the same mechanism.
> 
> 
Just because somebody else has decided to standardize it does not  
mean it's a good idea.

As I say, I think that allowing the authorization identifier bound to  
a session to change will introduce security issues. IMAP, and  
therefore IMAP servers, are built around the notion that the  
authorization identifier is bound at authentication time and  
thereafter invariant.

Breaking that assumption is trivial in theory, but in practise will  
have quite sever impact on server codebases, as well as impact to  
various extensions. For example, it's not at all clear what NOTIFY  
should do when faced with an authorization identifier change.

So at minimum, this draft would need to address every extant  
extensions for IMAP and ensure that it does not introduce security  
issues - but I don't think this is sufficient to eliminate the rather  
more worrying issue that authorization identifiers are considered an  
invariant of a session within the IMAP server codebases.

However, this isn't a problem, as what you can do is standardize the  
NAMESPACE usage and server layout such that it's simple for clients  
to discover the INBOX and personal mailboxes of other authorization  
identifiers.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade