For SSL3 and TLS, I assume that the printer uses "basic", "digest" or
"certificate-XXX", where "XXX" values need to be defined for each
certificate authority.
Bob Herriot
> -----Original Message-----
> From: Manros, Carl-Uno B
> Sent: Thursday, March 25, 1999 5:48 PM
> To: Herriot, Robert; ipp at pwg.org> Subject: RE: IPP> MOD - Issue 2: How can client force authentication,
> i.e ., identified mode? Solution #2 preferred
>>> Bob,
>> I agree with you proposal so far, but I still have one question.
>> You are only considering HTTP Basic and Digest services for
> client authentication, what about if you use SSL3 or TLS for
> client authentication?
>> Carl-Uno
>> > -----Original Message-----
> > From: Herriot, Robert [mailto:Robert.Herriot at pahv.xerox.com]
> > Sent: Thursday, March 25, 1999 5:35 PM
> > To: ipp at pwg.org> > Subject: RE: IPP> MOD - Issue 2: How can client force
> authentication,
> > i.e ., identified mode? Solution #2 preferred
> >
> >
> > I prefer solution #2 because it avoids adding a new and
> rather strange
> > operation. Instead it adds some new attributes and fits in
> > with the existing
> > infrastructure. Solution #2 is:
> >
> > 2. Use two URLs for the same IPP Printer object, one requires
> > authentication
> > and the IPP server always issues a challenge; the other never
> > does. So the
> > client that wants to be authenticated submits requests to
> the URL that
> > requires authentication. ISSUE: How does the client discover
> > which URL to
> > use, since "uri-security-supported" is about security, not
> > authentication?
> >
> > This solution allows an administrator to control what
> > combinations of basic,
> > digest and no authentication are supported.
> >
> > To resolve the ISSUE in the above solution, I suggest that we
> > add a printer
> > attribute "authentication-supported", which we would also add
> > to the printer
> > template for SLP. This attribute would specify how a printer
> > authenticates a
> > client -- a service that is incomplete in IPP. The values of
> > this attribute
> > would be parallel to "printer-uri-supported" and
> > "uri-security-supported",
> > and would include:
> >
> > "none": The printer issues no HTTP challenge, and treats
> > all users as
> > "anonymous". It ignores the "requesting-user-name" operation
> > attribute.
> >
> > "basic": The printer expects basic authentication or
> > issues a basic
> > challenge. It ignores the "requesting-user-name" operation
> attribute.
> >
> > "digest": The printer issues a digest challenge. It ignores the
> > "requesting-user-name" operation attribute.
> >
> > "requesting-user-name": the printer issues no HTTP
> > challenge, and uses
> > the operation attribute "requesting-user-name" to
> > authenticate a user. If
> > the "requsting-user-name" is absent, the user is "anonymous";
> > alternatively,
> > the job is rejected.
> >
> > "certificate-xxx": according to my understanding, we would need a
> > different "xxx" for each certificate authority in order to
> give useful
> > information.
> >
> > We would also need to add a new job attribute
> > "authentication-used" which
> > identifies the authentication mechanism used for the job.
> >
> > With these new attributes, a Printer implementation could be
> > augmented to
> > receive jobs via one or more URIs with different
> > authentication mechanisms.
> > The Get-Jobs operation, except for security restrictions,
> > would likly show
> > all jobs submitted to the printer, regardless of the URI. A
> Cancel-Job
> > operation would be more limited. A Printer would need to
> > implement a new
> > mechanism that defines equivalence of users authenticated via
> > different
> > mechanisms. This would determine whether a Cancel-Job
> > requester is the job
> > owner.
> >
> > It would simplest to say that a Cancel-Job requestor is
> > identical to a job
> > owner if the user names and authentication mechanisms are the
> > same. A less
> > restrictive mechanism would define a hierarchy of
> > authentication mechanisms:
> > "none", "requesting-user-name", "basic", and "digest", where
> > "digest" is the
> > most secure. An operation, such as Cancel-Job could be
> > performed on a job if
> > the users are the same and if the authentication mechanism
> > for the operation
> > equals or exceeds the authentication mechanism for the job
> > submission.
> >
> > Bob Herriot
> >
>