Subject: [lemonade] Security Review of URLAUTH

From: "Eric Burger" <[email-masked]>
Date: Tue, 2 Mar 2004 19:17:26 -0500

The following is a security review that we requested.  It is in a raw format, and may be updated.  Since we didn't have time to ask for permission, we're posting it anonymously.

Ted asked us to post it; he would have done it if his e-mail wasn't broken :-/

We have not reviewed it and has no endorsement or discussion from the Work Group Chairs.

                               Overview
>
>
>                                draft-crispin-imap-urlauth-06.txt
>                                describes extensions to the IMAP URL to
>                                add a capability cookie.  This cookie
>                                is stored in the URLAUTH parameter.
>                                The cookie transforms the URL into a
>                                capability for accessing a message or
>                                part of a message on the IMAP server.
>                                The capability can be restricted to be
>                                valid for a single user, or for any
>                                user that can perform one of a listed
>                                set of roles.  One of the roles is
>                                anonymous; such a URL serves as a
>                                capability for anyone who knows the URL
>                                to access the resource.
>
>This feature is desirable at least in part because of small clients
>trying to send large message attachments.  For example, you receive a
>large powerpoint presentation on your phone and wish to forward it to
>someone else.  You don't want to download the entire presentation only
>to upload it to your message composition server.  So instead, you
>generate one of these URLs and provide that URL to your message server
>.  That grants your composition server the capability of getting the
>presentation from your IMAP server to include in your outgoing mail.
>
>Two mechanisms are provided for generating these URLs.  The first is a
>signurl command.  The client provides a URL without the URLAUTH
>parameter and the server  adds a signature in some
>implementation-specified manner.    The client can distribute the URL
>which can later be used as an argument to the fetchurl command.
>
>Alternatively, there is a mechanism specified so that the client can
>generate URLAUTH parameters on its own without involving the server.
>The client retrieves the mailbox's "signature" key and generates a
>URLAUTh parameter.  Note that the signature is typically a symmetric
>authentication code, not a public-key signature.
>
>A mechanism is provided to generate a new mailbox signature key,
>invalidating all existing URLs.
>
>                    The HMAC-md5 Signature Mechanism
>
>The most significant problem with the document is the HMAC-MD5
>signature mechanism.  This mechanism is defined  in a single paragraph
>and allows clients to sign URLs without involving the server.
>
>I believe there is a high cost to standardizing mechanisms to allow
>clients to sign URLs without involving the server.  If there is an
>error or cryptographic deficiency in such a mechanism then this error
>needs to be corrected by standards action.  We need to wait for all
>the clients to be updated.  Server implementers need to  make choices
>about whether accepting the weak mechanism is an acceptable security
>risk.
>
>However if we require the signurl command be used then the
>cryptography used is entirely an internal matter for the IMAP server.
>If problems are found, they can be fixed between server versions.
>
>The disadvantage of not having a client-side signature solution is
>that clients will need another round trip to sign a part of a message.
>I'd recommend that we try to see how bad this is in practice and only
>standardize a client-side signature mechanism if a clear need exists
>for it.
>
>If we do standardize a client-side signature mechanism it should not
>be based on MD5.  Instead a more modern hash (SHA-1 or SHA-2) should
>be used.  In addition, test vectors should be included and the
>specification should be more clear on what data is included in the
>checksum.   If the working group does decide to get into the business
>of designing cryptographic protocols for client-side signature
>mechanisms, these protocols should be carefully reviewed.
>
>
>                      Internal Signature Mechanism
>
>The document defines the internal mechanism which can be used with the
>signurl command.  Especially if the HMAC-MD5 mechanism is removed, an
>example of how an internal mechanism could be implemented should be
>provided.  Also, security discussion describing problems to avoid
>would be very useful.
>
>                        Basic security Concerns
>
>The mechanism seems reasonably sound.  However, the definition of the
>URLAUTH attribute  requires that the signature is at most 128 bits:
>
>     When ";URLAUTH=<authsig>" is used, this indicates a authentication
>     signature mechanism name and a 128-bit authentication signature,
>     represented as an ASCII-encoded hexadecimal string, which is used to
>     authorize the URL.  The calculation of the authentication signature
>     depends upon the mechanism used.
>
>I believe that larger signatures should be used.  I would expect You'd
>want to at least allow for SHA-1 or SHA-2 checksums to be used as part
>of signatures.
>
>The document does not address URL canonicalization issues.  The
>suggested signature mechanisms all depend on bit level equivalence of
>URLs.  We should confirm with the URI community that depending on
>clients not to modify URIs is reasonable and make sure they have
>reviewed this draft.
>
>The document introduces a new architectural complexity in the message
>storage/delivery.  The composition server is expected to contact the
>user's IMAP server.  The composition server needs authenticate to the
>user's IMAP server as some composition role account.  These
>architectural issues should be considered.  They clearly have security
>implications.  For example, the composition and IMAP server's firewall
>configuration must permit the connection.  The servers must share a
>SASL mechanism and some authentication crdentials.  These issues
>should be considered.  I think the proposed extension is still
>justified, but these architectural issues should be discussed both
>within the working group and within the resulting document.
>
>The procedure for generating signatures and discussing signature
>validation assumes that signatures are deterministic.  This may be a
>reasonable assumption to make but it should be made explicitly.
>
>                             Technical Nits
>
>Reviewing this draft was difficult because it includes no section
>numbers, no page breaks and no page numbers.  Referring to specific
>parts of the draft is thus impossible.
>
>
>The draft claims that anonymous role URLs MUST NOT be sent over
>unencrypted connections.  Why not?  This mechanism seems reasonable to
>publish parts of a message archive on the web even if the archive as a
>whole is restricted.

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Mar 2004 17:08:58 +0900

Eric,

EB>   Since we didn't have time to ask for permission, we're posting it anonymously.

without violating the anonymity, can you describe the qualifications
of the review's author?  not lots of detail, just basic stuff.

thanks.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>