IPP> MOD - Issue 2: How can client force authentication, i.e ., identified mode? Solution #2 preferred

IPP> MOD - Issue 2: How can client force authentication, i.e ., identified mode? Solution #2 preferred

IPP> MOD - Issue 2: How can client force authentication, i.e ., identified mode? Solution #2 preferred

Herriot, Robert Robert.Herriot at pahv.xerox.com
Thu Mar 25 21:35:40 EST 1999


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
> > 
> 



More information about the Ipp mailing list