Subject: [lemonade] Channel gaps?

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Wed, 11 Jun 2003 09:37:23 -0500

Speaking of Channel,
 
I agree that there does seem there is common technology between channel and an external submission service.
 
Unless I mis-understand the current draft (-02 I believe in my disconnected state), there is an incompleteness with respect to security.  The IMAP server is requested to deliver a content via an external transport such as IMAP, HTTP, or RTP.  The specification does not deal with the authentication of the requesting client connection (a submit server?) on that port.  It seems there are two cases, both have some problems.
 
    1) the external mechanism supports authentication using the same credentials as the primary IMAP connection
            - This requires extra overhead and latency to do the authentication, or mechanism to transport credentials
            - It may also introduce complexity when using 3rd party servers such as a transcode server in the data-path
    2) the external mechanism does not inherently support authentication... HTTP, RTP
            - The content is made available on a random port or URL for the taking, and a client with a good guessing 
                algorithm could go looking for unprotected content.  This risk is higher for protocols like RTP 
                than HTTP URLs  (fewer ports to guess than possible URLs).
 
Mark's proposed but unspecified token scheme would seem to be a necessary addition to channel for the second class of access mechanisms to ensure that the channel can be authenticated for that specific message or body part.   It may even be desirable for the set of protocols in the first set in cases where the content needs to flow through a third party for content conversion and the like, and it would be undesirable to send the users credentials through that server.
 
I note that the use of a hash or token is implied by the examples in Eric Burgers channel use case document, but they are not discussed in the standard document.
 
Do we need to write channel-specific documents as companion to the base channel spec?  In places it seems the channel use case document is trying to do just that for some channels such as MailTo.
 
Comments?
 
Greg V.

-----Original Message-----
From: Erev Ari [mailto:[email-masked]]
Sent: Wednesday, June 11, 2003 3:46 AM
To: 'Chris Newman'; IETF LEMONADE (E-mail)
Subject: RE: [lemonade] Strawman for Submit based message composition

Chris, 

Isn't the GENURL/GETURL very similar to the proposed IMAP CHANNEL extension? 
http://www.ietf.org/internet-drafts/draft-nerenberg-imap-channel-03.txt <http://www.ietf.org/internet-drafts/draft-nerenberg-imap-channel-03.txt>  (now expired) 

As far as I remember with CHANNEL you could ask the IMAP server for a "URL" for a specific MIME part of a message (or to the whole message)

Ari 

> -----Original Message----- 
> From: Chris Newman [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: Wednesday, June 11, 2003 3:08 AM 
> To: IETF LEMONADE (E-mail) 
> Subject: [lemonade] Strawman for Submit based message composition 
> 
> 
> I'll start by defining message composition as the process of 
> assembling 
> multiple byte-counted objects from potentially different 
> locations into a 
> single byte stream.  IMAP has no such facility. 
> 
> SMTP/Submit, however, already has 90% of this facility with 
> the CHUNKING 
> extension.  In particular, it assembles a series of 
> byte-counted objects into a 
> single byte stream. 
> 
> Suppose we create a new Submit extension called "BURL" which 
> can be interleaved 
> with "BDAT" commands.  So you can now compose a message as follows: 
> 
> BDAT ....               headers and first part 
> BURL 8bit <imap-url>    forwarded 8bit content from IMAP 
> BDAT ....               MIME delimiters or whatever 
> BURL base64 <http-url>  get http content, base64 encode it 
> and include it 
> BDAT ....               final data 
> 
> This can all be pipelined into one round-trip. 
> 
> The BURL extension should advertise what types of URLs it supports: 
> 
> 250-BURL http imap://trusted-host.example.com/ 
> 
> This extension alone would solve the forward-without-download 
> extension for the 
> subset of the problem space where the submit server has 
> pre-existing trust 
> relationship with the IMAP server. 
> 
> Indeed since 99% of the world uses plain text passwords (with 
> or without TLS) 
> for authentication.  Authenticating to the submit server will 
> grant sufficient 
> rights for the user to access and forward their own mail from 
> IMAP anyway.  So 
> why not use it when appropriate? 
> 
> If we wanted to go for the additional case where there isn't a trust 
> relationship between the submit server and IMAP server, then 
> we simply add two 
> extensions to IMAP: 
> 
> 1. a "GENURL" command which turns a message or body-part 
> reference within the 
> selected mailbox into an extended IMAP URL with an 
> authorization token.  This 
> could either have a time-limit or a number of use limit.  The 
> authorization 
> token would likely be an HMAC-MD5 covering the URL, a nonce, 
> a time-limit and 
> using a per-user random secret known only to the IMAP server. 
> 
> 2. a "GETURL" command which is accessible by any IMAP user (including 
> anonymous) which returns a literal of the the relevant 
> message/body part if the 
> authorization token is valid. 
> 
> This just doesn't seem complicated to me.  Indeed it seems 
> much simpler than 
> any approach to extending IMAP with a redundant submission 
> and composition 
> facility in addition to the one already present in CHUNKING Submit. 
> 
>                 - Chris 
> 
> _______________________________________________ 
> lemonade mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/lemonade <https://www1.ietf.org/mailman/listinfo/lemonade>  
>

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 11 Jun 2003 22:24:45 -0600

On Wednesday, June 11, 2003, at 08:37  AM, Vaudreuil, Greg M (Greg) 
wrote:
>
> Unless I mis-understand the current draft (-02 I believe in my 
> disconnected state), there is an incompleteness with respect 
> to security.  The IMAP server is requested to deliver a content via an 
> external transport such as IMAP, HTTP, or RTP.  The specification does 
> not deal with the authentication of the requesting client connection 
> (a submit server?) on that port.

Correct. A lot of work needs to be done on the security aspects, and 
there are *many* security implications of the extension. To date about 
all that has been discussed is that, if it's at all possible, we want 
to pass authentication tokens within the URLs. The big problem that I 
see with this is that we can't set a single policy for how these 
authentication tokens are to be derived.

Every time this subject comes up, people get very quiet. It's going to 
be a difficult problem to solve, I think. I'm planning to push another 
draft out after Vienna, and some discussion on this now might allow for 
at least one strawman to be included in the document (preferably more).

--lyndon

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade