Subject: Re: [apps-discuss] Extentions of IMAP4

From: [email-masked]
Date: Tue, 9 Aug 2011 16:11:20 +0800

Dave Cridland <[email-masked]> 
2011-07-26 17:44

收件人
"[email-masked]" <[email-masked]>, General discussion of 
application-layer protocols <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>, 
"SHIH, JERRY \(ATTSI\)" <[email-masked]>
抄送

主题
Re: Re: Re: [apps-discuss] Extentions of IMAP4

On Tue Jul 26 09:36:35 2011, [email-masked] wrote:
> > On Fri Jul 22 09:12:35 2011, [email-masked] 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.

[Yan LU]Sorry for the late reply for we just came back from an OMA-EVVM 
interim meeting. During the meeting the two proposed drafts were discussed 
by the EVVM Group. The group considered serveral possible solutions, 
including the ones you mentioned in your emails (by the way, thanks very 
much). However, we still think to extend IMAP4 is probably one of the best 
candidates.

Yes, just as you said, we need to study the influence this extention may 
have on all extensions for IMAP. 

We are waiting for further comments from IETF.

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.