Re: [apps-discuss] Extentions of IMAP4

[Dave Cridland <[e-mail]>]

On Tue Jul 26 09:36:35 2011, [e-mail] wrote:
> > On Fri Jul 22 09:12:35 2011, [e-mail] 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:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade