Subject: [lemonade] Draft Day 1 Minutes

From: Eric Burger <[email-masked]>
Date: Thu, 10 Mar 2005 16:34:43 -0500

Minutes by Eric Burger Compiled from Jabber Log taken by Pete and others

Goals in RFC Editor Queue
Server-to-Server Notifications Needs WG Chair Write-Up for IESG
MMS Mapping Needs WG Chair Write-Up for IESG
Future Delivery and BURL needs nits review
Tool to help nits review: http://ietf.levkowetz.com/tools/idnits/idnits.pyht

URLAUTH
-------
- url interpretation: basic concern is "what is the base url for relatively
interpretation? does it change in selected state as opposed to authenticated
state?"
- if you are going to use an absolute url we have an issue of a server
needing to know its own domain name and do you always want to include the
username
- an absolute url without a user seems to indicate an anonymous user
- Philip Gunther: favor of changing base url in selected state
- Chris Newman: the complexity is how to deal with ".." in a relative url?
seems to be consensus for selected state changing base URL for relative
urls, specifically, to "this mailbox"

Are absolute URLs allowed? is the client required to use relative URLs where
possible?
- general agreement that we should force clients to use relative URLs and
have a different extension for absolute URLs.
- John Klensin that disallowing absolute URLs is weird. Why have URLs at all
if we can only use relative URLs?
- Chris Newman: we should require relative URLs but need to make clear that
"/random/mailbox" refers to "random/mailbox"
Consensus that absolute URLs are out for this extension
";AUTH=" is also not allowed
Absolute URLs are syntactically allowed, but not supported by the CATENATE
extension.
Absolute URLs get a "NO" from the server.
Same for AUTH.
Needs new draft, new Chairs say enough has changed for new WGLC

Alexey notes there are some ABNF issues with IMAP URL RFC, which he sent to
Chris.,

Profile
-------
Greg V: are requirements on server only or client, too?  Consensus is
requirements are on server, but document needs to give hints to client for
how to use server extension.
Needs lots of work. Right now document is a tutorial. Needs to be a
standards document.

Security Issues
---------------
EKR: Comfortable if we use same authentication method for reconnect as for
initial IMAP connect. Using *only* a cookie opens up passive attack. Using
cookie after authentication is OK.
Alexey & Corby: This is how Quick Reconnect works today (using cookie after
full authentication).
Cyrus Daboo points out that this is needed for desktop clients, as well as
mobile clients.
Edwin Aoki asks about single use schemes (e.g., SecurId). EKR says that if
that is the authentication method, that is the authentication method.

Transcoding & Security
---------------------
Drawing on fact that there is a possibility for the server to hand the
encrypted session key to the client, the client can decrypt the session key,
and hand back the key to the server, we can (1) ANNOTATE clear key to
message, (2) decrypt message using session key and CATENATE message to
temporary/permanent storage, (3) hand session key over for each IMAP
operation.
One problem is key is part of encrypted blob. [BTW: Ned pointed out need for
separate carriage of key back in early 90's.] EKR points out that key almost
always lives in first 4KB of blob, so can hack extraction.
Jim Shod states that API's exist for S/MIME to do separate session key
extraction, session key decryption, and decryption of the message using the
decrypted session key.
Will form design team to address this issue.

On the streaming issue, URLAUTH addresses the Streaming Server-IMAP Server
association, so long as the Streaming Server is authenticated to the IMAP
Server; can use the same mechanism a SUBMIT server authenticates with the
IMAP server for forward-without-download. Normal IMAP authentication
addresses the IMAP Server-IMAP Client association. Using a secure channel
between the IMAP Client and Streaming Server should be OK (EKR), but Sam
Hartman separately expressed concern that the association between the IMAP
Client and the Streaming Server has to use the same method as the IMAP
Client and IMAP Server. For example, if the IMAP login does not use
certificates, then we should not require the use of certificates for the
IMAP Client-Streaming Server link.

Stan Turner volunteered to participate on e2e design team.

EKR volunteered to help review specific documents.

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

---

From: Mark Crispin <[email-masked]>
Date: Thu, 10 Mar 2005 14:03:06 -0800 (Pacific Standard Time)

Could someone send me a list of what, precisely, needs to be done to the 
URLAUTH document to comply with the WG's decisions?

I also have a question: are these really changes to URLAUTH, or are they 
rather changes to URLAUTH *as used by LEMONADE* (e.g. CATENATE, etc.).

Do we need to spawn an additional document dictating usage of URLAUTH type 
URLs in the LEMONADE context, and cause the URLAUTH document itself to 
focus on the actual URLAUTH mechanism?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Pete Resnick <[email-masked]>
Date: Fri, 11 Mar 2005 00:28:38 -0600

On 3/10/05 at 2:03 PM -0800, Mark Crispin wrote:

>Could someone send me a list of what, precisely, needs to be done to 
>the URLAUTH document to comply with the WG's decisions?
>
>I also have a question: are these really changes to URLAUTH, or are 
>they rather changes to URLAUTH *as used by LEMONADE* (e.g. CATENATE, 
>etc.).

This was simply completely mislabeled in the draft minutes. The stuff 
under the title "URLAUTH" has nothing to do with URLAUTH. It's about 
the paragraph I posted earlier today with regard to the use of URLs 
in CATENATE. There is nothing that needs to be changed in URLAUTH at 
all.
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Mark Crispin <[email-masked]>
Date: Thu, 10 Mar 2005 23:13:42 -0800

On Fri, 11 Mar 2005, Pete Resnick wrote:
> This was simply completely mislabeled in the draft minutes. The stuff under 
> the title "URLAUTH" has nothing to do with URLAUTH. It's about the paragraph 
> I posted earlier today with regard to the use of URLs in CATENATE. There is 
> nothing that needs to be changed in URLAUTH at all.

OK, thanks.

-- Mark --

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Mar 2005 10:54:58 +0000

Pete Resnick wrote:

> There is nothing that needs to be changed in URLAUTH at all.

Except for addressing few issues I've posted earlier ;-).

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 11 Mar 2005 09:59:41 -0500

Hi Alexey,

> Except for addressing few issues I've posted earlier ;-).

Also please add a 'capability' formal syntax element to both URLAUTH and 
CATENATE as per discussion in IMAPext:

For URLAUTH add:

        capability      =/  "URLAUTH"

For CATENATE add:

        capability      =/  "CATENATE"

-- 
Cyrus Daboo