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

Paul Moore paulmo at microsoft.com
Tue Mar 30 11:52:51 EST 1999


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