Notes on HTTP SASL proposal

• http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-12.txt
• Serious layer violations -- mixing connection handling with request/response handling
• Requires support for persistent connections but doesn't say when to use them
  • E.g. it would seem that a persistent connection is required for the server to know who the client is from one request to another -- but doesn't say this
• Unnecessary round-trip for error code 235, still there even after comments

• I need to understand more about why Joe Orton said CONNECT just wouldn't work
• Also OPTIONS

• If the connection itself is used to remember who the client is, can't this be hijacked easily? I would think you'd have to require for the connection to be encrypted to avoid this threat.

• In general I don't think the security considerations section is thorough enough for a document like this.

Surely a better HTTP-like design for incorporating SASL would involve the WWW-Authenticate header sent on every client request with at least a session key. There could be some kind of layering where the "real request" could be encapsulated inside the outer request -- the outer request contains the session key so the server can figure out which shared secret to use to decrypt the inner request.

FYI: here's the ID-tracker page for this draft, where my current comments are linked (use the DETAIL button), along with Roy Fieldings, Ekrs, Joe Ortons.

-- LisaDusseault - 26 Jul 2004