Re: Draft -16 out now

Lisa Dusseault schrieb:
> 
> Draft -15 of RFC2518bis expired, and I knew we needed a live draft for 
> any further action, so I spun up draft -16.  The major bugs to be fixed 
> in this version were:
>     - inconsistent use of "Lock-Token" header in an example, when the 
> text requires "if" (the thread below)
>     - bug in example of extending "all-prop" with "include" directive 
> (bug 188 I think)
> 
> Also I went through the bugzilla issues raised since -15 (all 
> post-WG-last-call).  I tried to make very conservative judgements about 
> what textual/editorial improvements were clearly useful improvements and 
> yet not destabilizing to the draft overall at this stage.

I don't think that any of the suggested changes would indeed 
"destabilize" the draft -- sorry, but this is just FUD.

> XML and text versions at 
> http://ietf.osafoundation.org/xythoswfs/webui/webdav/rfc2518bis until 
> the version submitted to the Internet-Drafts repository goes up.

Turns out that there's a normative change in there in the Security 
Requirements:

Section 20.1., para. 2:
OLD:

     A password sent in the clear over an insecure channel is an
     inadequate means for protecting the accessibility and integrity of a
     resource as the password may be intercepted.  Since Basic
     authentication for HTTP/1.1 performs essentially clear text
     transmission of a password, Basic authentication MUST NOT be used to
     authenticate a WebDAV client to a server unless the connection is
     secure.  Furthermore, a WebDAV server MUST NOT send Basic
     authentication credentials in a WWW-Authenticate header unless the
     connection is secure.  Examples of secure connections include a
     Transport Layer Security (TLS) connection employing a strong cipher
     suite with mutual authentication of client and server, or a
     connection over a network which is physically secure, for example, an
     isolated network in a building with restricted access.

NEW:

     A password sent in the clear over an insecure channel is an
     inadequate means for protecting the accessibility and integrity of a
     resource as the password may be intercepted.  Since Basic
     authentication for HTTP/1.1 performs essentially clear text
     transmission of a password, Basic authentication MUST NOT be used to
     authenticate a WebDAV client to a server unless the connection is
     secured by TLS.  Furthermore, a WebDAV server MUST NOT send a Basic
     authentication challenge in a WWW-Authenticate header unless the
     connection is secured by TLS.


Funny enough, the changes section claims...:


     Fixed factual errors in Security Considerations authentication
     section.

     ...

     Tighten requirements in Security Considerations section for
     authentication over secure channels.

So,

(1) please explain the nature of the factual error that was fixed 
(bugzilla issue?), and

(2) please clarify where there was a prior discussion about changing the 
security requirements (at this stage, if I may add...). Please also note 
that this would introduce a normative dependency on TLS, for which we'd 
need a reference.

Best regards, Julian

Received on Sunday, 26 November 2006 20:39:31 UTC