www.ietf.org - go to the -rfc- section and search for SASL. I never can remember
the exact RFC
numbers.
Also, www.iana.org. go to the "assignments" section and look for "SASL mechanisms".
In this
file you will find each of the standard SASL mechanisms enumerated, along with
pointers to
RFCs wherein the technical aspects of each mechanism are defined.
If you have any more difficultly let me know and I can get you the exact
drafts/RFCs.
Randy
Carl Kugler wrote:
> 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