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
Tue Mar 30 17:54:53 EST 1999


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



More information about the Ipp mailing list