Randy-
Can you give us some pointers on where to get smart about SASL?
-Carl
rturner at sharplabs.com on 11/18/98 06:36:46 PM
Please respond to rturner at sharplabs.com
To: ipp at pwg.org, Carl Kugler/Boulder/IBM at ibmus
cc:
Subject: Re: Fwd: Re: IPP> IPP Meeting Discussion about IPP URL Sch
Any kind of directory support (SLP or LDAP) has always been optional and we
don't mandate how the user obtains the URL, so I would rather say that he
obtains it "somehow" that is separate from all of the other schema-related
metadata concerning the service. In this case, the user is hung out to dry and
it might seem like its unsolvable. However, I'm trying to work out a SASL
instrumentation where everything about security is negotiated "in-band", and
either the client or server can request an "upgrade" of security capability.
Randy
Carl Kugler wrote:
> Note: this is further discussion of IPP/NV, rather than a problem with
IPP/1.0, which I agree will work as is.
>> Randy-
>> Where does the URL come from without SLP or LDAP? I'm thinking that the need
for privacy (SSL encryption) would originate at the client end, since the
client is the one sending the sensitive data over the net. A Printer could
advertise (through whatever means) an URL for a normal HTTP port (no SSL) which
the client could query with Get-Printer-Attributes to learn the secure URL,
which it would then use for submitting Jobs. I'm assuming here that the
Printer would have two ports, one secure and one unsecure (possibly with
restricted capabilities and/or authentication, if desired), just as SSL web
servers typically do today.
>> If the client can only obtain a naked URL with no other information about a
Printer, and the Printer only has one, SSL, port, then I agree the problem is
not solvable except through guess-and-retry unless the URL has embedded
protocol information like an "https" scheme.
>> -Carl
>> > Message http://www.egroups.com/list/ipp/?start=4907> >
> >
> > Yes the -05 spec defines how the HTTP scheme is interpreted.
> >
> > You could use the "ipp:" scheme using the approach in MOD, but you would be
broken
> > in environments that do not have SLP or LDAP installed. Because the "ipp"
scheme
> > does not dictate that SSL/TLS negotiation is enabled, and this is the
> > "first" thing that happens on the connection, before the client could open a
> > 'non-secure' connection and query the server attributes directly.
> >
> > Randy
> >
> >
> >
> >
> > Carl Kugler wrote:
> >
> > > Which brings us back to why not use an "ipp:" scheme? I don't see why we
can't
> > > do SSL3 with an "ipp:" scheme using the approach given in MOD.
> > >
> > > What is the HTTP URL standard? The only relevant statement I can find in
> > > draft-ietf-http-v11-spec-rev-05 is this:
> > > HTTP communication usually takes place over TCP/IP connections. The
default
> > > port is TCP 80 [19], but other ports can be used. This does not preclude
HTTP
> > > from being implemented on top of any other protocol on the Internet, or on
> > > other networks. HTTP only presumes a reliable transport; any protocol that
> > > provides such guarantees can be used; the mapping of the HTTP/1.1 request
and
> > > response structures onto the transport data units of the protocol in
question
> > > is outside the scope of this specification.
> > >
> > > rturner at sharplabs.com on 11/18/98 04:27:29 PM
> > > Please respond to rturner at sharplabs.com> > > To: Carl Kugler/Boulder/IBM at ibmus> > > cc:
> > > Subject: Re: IPP> IPP Meeting Discussion about IPP URL Sch
> > >
> > > The HTTP URL standard says that SSL3 is not utilized for the transport
implied
> > > by the URL scheme "HTTP".
> > >
> > > I never was quite comfortable with the text in the model document overri
ding a
> > > known "proposed"
> > > standard.
> > >
> > > Randy
> > >
> > > Carl Kugler wrote:
> > >
> > > > Just to follow up on this.
> > > >
> > > > The draft-ietf-ipp-ipp-scheme-01.txt says:
> > > >
> > > > > An IPP/1.0 client MUST use an http-URL for non-secure printers and an
> > > https-URL for secure printers.
> > > >
> > > > I don't understand why. In fact, a counter- example is shown in section
> > > 4.4.2, "uri-security-supported", of draft-ietf-ipp-model-11.txt:
> > > >
> > > > > For a single Printer object, an administrator configures the
> > > "printer-uri-supported" and "uri-security-supported" attributes as
follows:
> > > > "printer-uri-supported": 'http://acme.com/open-use-printer',> > > 'http://acme.com/restricted-use-printer', 'http://
acme.com/private-printer'
> > > > "uri-security-supported": 'none', 'none', 'ssl3'
> > > > ...
> > > > >For the third URI, 'http://acme.com/private-printer', the value 'ssl3'
in
> > > "uri-security-supported" indicates that SSL3 is being used to secure the
> > > channel. The client SHOULD be prepared to use SSL3 framing to negotiate
an
> > > acceptable ciphersuite to use while communicating with the Printer
object. In
> > > this case, the name implies the use of a secure communications channel,
but the
> > > fact is made explicit by the presence of the 'ssl3' value in
> > > "uri-security-supported". The client does not need to resort to
understanding
> > > which security it must use by following naming conventions or by parsing
the
> > > URI to determine which security mechanisms are implied.
> > > >
> > > > There must be some rationale I've missed that explains why the approach
in
> > > MOD is insufficient.
> > > >
> > > > -Carl
> > > >
> > > > > -----
> > > > > See the original message at
http://www.egroups.com/list/ipp/?start=4875
> > > > >
> > > > >
> > > >
> > > > -----
> > > > See the original message at http://www.egroups.com/list/ipp/?start=4876> >
> >
> >
>> -----
> See the original message at http://www.egroups.com/list/ipp/?start=4907