Message-ID: <15533237421C6E4296CC33A2090B224A54CB69@UTDEVS02.campus.ad.utdallas.edu>
From: pauls at utdallas.edu (Schmehl, Paul L)
Subject: Apparently the practice was prevalent

> -----Original Message-----
> From: full-disclosure-admin@...ts.netsys.com 
> [mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of 
> Shawn K. Hall (RA/Security)
> Sent: Monday, February 09, 2004 5:35 PM
> To: full-disclosure@...ts.netsys.com
> Subject: RE: [Full-Disclosure] Apparently the practice was prevalent
> 
> No, it doesn't. It defines the protocol. It imports necessary 
> values from other specs and recommendations by reference, 
> like those you quoted below - which, had you actually read 
> both RFC's you'd see that authority, as defined in 2396 does 
> include userinfo. Period. As referenced in 2616 3.2.1, it 
> imports "authority" as defined in 2396 which includes 'userinfo.'
> 
2396 also includes this:

   "Some URL schemes use the format "user:password" in the userinfo
   field. This practice is NOT RECOMMENDED, because the passing of
   authentication information in clear text (such as URI) has proven to
   be a security risk in almost every case where it has been used."

And this:

   "It is clearly unwise to use a URL that contains a password which is
   intended to be secret. In particular, the use of a password within
   the 'userinfo' component of a URL is strongly disrecommended except
   in those rare cases where the 'password' parameter is intended to be
   public."

Which seems to say that the use of user:password@....domain.com is NOT
recommended except in rare cases.
> 
> That's not what I said. I said that it was not definitive, 
> but abbreviated - having most of it's value by reference. 'An 
> informed reading' of the RFC's would demonstrate how 
> misguided you are.
> 
This is what 2616 says about http URLS:

  "The "http" scheme is used to locate network resources via the HTTP
   protocol. This section defines the scheme-specific syntax and
   semantics for http URLs.

   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

   If the port is empty or not given, port 80 is assumed. The semantics
   are that the identified resource is located at the server listening
   for TCP connections on that port of that host, and the Request-URI
   for the resource is abs_path (section 5.1.2). The use of IP addresses
   in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If
   the abs_path is not present in the URL, it MUST be given as "/" when
   used as a Request-URI for a resource (section 5.1.2). If a proxy
   receives a host name which is not a fully qualified domain name, it
   MAY add its domain to the host name it received. If a proxy receives
   a fully qualified domain name, the proxy MUST NOT change the host
   name."

What exactly does "defines the *scheme-specific* syntax and semantics"
mean?

ISTM it means you are allowed to use http: + // + host + abs_path and/or
query.  No mention of user:password or "authority" here.

And this part of 2396 seems to contradict you specifically:

   " The URI syntax is dependent upon the scheme.  In general, absolute
   URI are written as follows:

      <scheme>:<scheme-specific-part>

   An absolute URI contains the name of the scheme being used (<scheme>)
   followed by a colon (":") and then a string (the <scheme-specific-
   part>) whose interpretation depends on the scheme.

   The URI syntax does not require that the scheme-specific-part have
   any general structure or set of semantics which is common among all
   URI.  However, a subset of URI do share a common syntax for
   representing hierarchical relationships within the namespace.  This
   "generic URI" syntax consists of a sequence of four main components:

      <scheme>://<authority><path>?<query>"

I read that as saying the scheme-specific part is authoritative for each
scheme and cannot be overridden by the generic syntax specified in 2396.
Which means that user:password (<authority>) is disallowed for HTTP
because it is not specifically allowed within the scheme-specific
definition of HTTP URIs given in 2616.
 
Paul Schmehl (pauls@...allas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/~pauls/ 

Powered by blists - more mailing lists