With all the email threads below, did answer a different thread than I
intended?
I was trying to find out if you support solution #2 for a printer that
accepts some users with no challenge and others with a challenge. You have
been supporting a solution which allows a user to request that a
nonchallenging printer issue a challenge. Solution #2 requires 2 URLs for
such a printer, one which issues a challenge and other which does not. The
user picks the appropriate URL.
Bob Herriot
> -----Original Message-----
> From: Paul Moore [mailto:paulmo at microsoft.com]
> Sent: Tuesday, March 30, 1999 8:53 AM
> 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
>>> no , it mixes two, essentially othogonal, things.
>> The 'correct' solution is for HTTp to support this itself
> (but it doesnt)
>> -----Original Message-----
> From: Herriot, Robert [mailto:Robert.Herriot at pahv.xerox.com]
> Sent: Monday, March 29, 1999 6:04 PM
> To: Paul Moore; Herriot, Robert; ipp at pwg.org> Subject: RE: IPP> MOD - Issue 2: How can client force authentication,
> i.e ., identified mode? Solution #2 preferred
>>> Does this solution seem like a better and simpler solution
> than the new
> "force authentication" IPP operator that you originally proposed?
>> Bob Herriot
>> > -----Original Message-----
> > From: Paul Moore [mailto:paulmo at microsoft.com]
> > Sent: Monday, March 29, 1999 11:12 AM
> > 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
> >
> >
> > How does trhis work in combination with various secure
> > transmission RLS
> > (ssl3, TLS, etc).
> >
> > What you would actually need would be a product of all the
> > combinations of
> > identification and auth/secure channel methods.
> >
> > URL1 = none, none
> > URL2 = basic, none
> > URL3 = basic, TLS
> > URL4 = basic, SSL3
> > URL5 = digest, none
> > ...
> > URL9 = digest, SSL3
> >
> > URL27 = foobar, XYZ
> >
> >
> >
> > -----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
> >
>