Can you give us some pointers on where to get smart about SASL?
-Carl
rturner@sharplabs.com on 11/18/98 06:36:46 PM
Please respond to rturner@sharplabs.com
To: ipp@pwg.org, Carl Kugler/Boulder/IBM@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 an=
d 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-rela=
ted
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 SA=
SL
instrumentation where everything about security is negotiated "in-band"=
, and
either the client or server can request an "upgrade" of security capabi=
lity.
Randy
Carl Kugler wrote:
> Note: this is further discussion of IPP/NV, rather than a problem wi=
th
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 t=
he
client is the one sending the sensitive data over the net. A Printer c=
ould
advertise (through whatever means) an URL for a normal HTTP port (no SS=
L) 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 th=
e
Printer would have two ports, one secure and one unsecure (possibly wit=
h
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 a=
bout a
Printer, and the Printer only has one, SSL, port, then I agree the prob=
lem 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=3D4907
> >
> >
> > 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 t=
he
> > "first" thing that happens on the connection, before the client cou=
ld 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 se=
e 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. T=
he
default
> > > port is TCP 80 [19], but other ports can be used. This does not p=
reclude
HTTP
> > > from being implemented on top of any other protocol on the Intern=
et, or on
> > > other networks. HTTP only presumes a reliable transport; any prot=
ocol 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@sharplabs.com on 11/18/98 04:27:29 PM
> > > Please respond to rturner@sharplabs.com
> > > To: Carl Kugler/Boulder/IBM@ibmus
> > > cc:
> > > Subject: Re: IPP> IPP Meeting Discussion about IPP URL Sch
> > >
> > > The HTTP URL standard says that SSL3 is not utilized for the tran=
sport
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 printer=
s and an
> > > https-URL for secure printers.
> > > >
> > > > I don't understand why. In fact, a counter- example is shown i=
n 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 a=
s
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 valu=
e 'ssl3'
in
> > > "uri-security-supported" indicates that SSL3 is being used to sec=
ure the
> > > channel. The client SHOULD be prepared to use SSL3 framing to ne=
gotiate
an
> > > acceptable ciphersuite to use while communicating with the Printe=
r
object. In
> > > this case, the name implies the use of a secure communications ch=
annel,
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=3D4875
> > > > >
> > > > >
> > > >
> > > > -----
> > > > See the original message at http://www.egroups.com/list/ipp/?st=
art=3D4876
> >
> >
> >
>
> -----
> See the original message at http://www.egroups.com/list/ipp/?start=3D=
4907
=