[Council] new JEP -- position paper needed!

David Waite david at aspect.net
Tue Apr 2 09:19:54 CST 2002

I don't quite know what sort of evaluation we are supposed to do for 
this JEP, since it is informational and not on the standards track. I 
assume it is just a review for technical accuracy? Also, should our 
technical review provide notes in the case where the JSF membership 
wants to take an informational draft and form a standard based on it?

(more in-line)

Mike Lin wrote:

>Here is my stream-of-thought for the kind of ideas that would go into a
>position paper, at least from my perspective. Joe and Craig, I would
>really like your input on these points, because I don't doubt that some
>of my concerns might simply be a result of my misunderstanding.
>"In some browser/platform combinations, sending cookies is not possible
>due to design choices (bugs?) in the browser. Therefore, a work-around
>was needed to support these platforms."
>I presume the "work-around" this refers to is the sending of the Session
>ID in the payload of the request instead of in a standard responding
>cookie header. If so, this should be stated more clearly.
>I don't quite understand how the browser is relevant here. Why is the
>web browser's (a UI) ability to send cookies relevant to the design of a
>Jabber client? Recalling that this JEP describes the JabberIM
>implementation, one might conjecture that your implementation uses
>WinInet or some other prepackaged HTTP component which does not like the
>cookie header. Again, since this JEP is informational, I won't argue
>directly against this hack, but if my conjecture is correct (or even if
>it's incorrect) it would be useful to clarify this point in the JEP.
I believe this JEP deals mostly with html browser-based applications; 
AFAIK, this protocol is only currently used by Jabber, Inc.'s Web Client 
product (http://webim.jabber.com). The actual difficulty is that one of 
the browsers strips cookie information on HTTP requests sent from Java 
on either the requests or responses. So the Session ID could not be sent 
within the Cookie field of the header, and had to be sent via the body.

I'm interested in more specifics as well - it seems an extra header 
could have just been added (e.g. "X-Session-ID: foo")

>I would *strongly* recommend, even though this is an informational JEP,
>adding some kind of mediocre session authentication by means of a
>crytpographic hash over the user's password and a request sequence
>number of some sort. I think there are very cheap ways to at least bring
>the security of this protocol basically on par with what we have now.
*nod*; a shared secret could be used to generate keys (in each 
direction) for sequential packets, formed on one side and verified on 
the other. The password would actually be rather useful for generating 
this; it could be just a matter of SHA1Hash(sessionID + password + 
packet # ). But this is just a note, since this is informational.

-David Waite

More information about the Council mailing list