I think that we concluded that a request for a basic/digest challenge is
orthogonal to a TLS request. Thus, if we accept this option (and I don't
think we should), we must add a new header and not just a new value to
"upgrade".
Bob Herriot
> -----Original Message-----
> From: Manros, Carl-Uno B [mailto:cmanros at cp10.es.xerox.com]
> Sent: Tuesday, March 23, 1999 6:06 PM
> To: Hastings, Tom N
> Cc: IETF-IPP
> Subject: RE: IPP> MOD - Issue 2: How can client force authentication,
> i.e ., identi fied mode?
>>> Tom,
>> You did not get the last alternative that I suggested quite right.
> It would NOT require a NEW header, we would use the Upgrade header
> in the same way that we use it for TLS in IPP/1.1 already. We
> will need to register a new value for the existing header.
>> Carl-Uno
>> > -----Original Message-----
> > From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> > Sent: Tuesday, March 23, 1999 5:24 PM
> > To: ipp
> > Subject: IPP> MOD - Issue 2: How can client force
> > authentication, i.e.,
> > identi fied mode?
> >
> >
> > Here is the third issue from the Bake Off that has several possible
> > alternatives. This issue has also had a lot of email
> > discussion since the
> > Bake Off. We list some additional alternatives to adding a
> > new operation.
> > What do people think of the alternatives?
> >
> > Tom
> >
> > 2) ISSUE: How can client force identified mode?
> >
> > If an IPP Printer supports both authenticated and unauthenticated
> > access, there is no way for a client to force itself to be
> > authenticated, i.e., be in identified mode, since it is the
> > server that
> > forces authentication by issuing a challenge to the client. It is
> > very useful for a client to be able to get into identified
> > mode as soon
> > as possible. Today you have to wait to be challenged by the server,
> > which may never happen -- or happens at an unpredictable time. The
> > security conformance requires that the authentication for
> > operations be
> > the same for all operations. So for authenticated Cancel-Job, the
> > Print-Job has to be authenticated as well. We would like to
> > add another
> > operation that forces the server to generate a 401 authentication
> > challenge which the client would submit before submitting the
> > print job
> > in the first place. Unless somebody has a different solution
> > (Microsoft)
> >
> >
> > Possible alternatives:
> >
> > 1.Add the operation as an OPTIONAL operation to IPP/1.0 and IPP/1.1
> > that forces the IPP object to issue a challenge to the client.
> >
> > 2.Use two URLs for the same IPP Printer object, one requires
> > authentication and the IPP server always issues a
> challenge and 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?
> >
> > 3.Use two IPP Printer objects that fan-in to the same
> device. One IPP
> > Printer object requires authentication and always issues the
> > challenge and the other never does. ISSUE: How does the client
> > discover which IPP Printer to use for authenticated access?
> >
> > 4.Request that the HTTP WG add some kind of header that allows the
> > client to request that the HTTP server issue a challenge.
> > ISSUE: It
> > is unlikely that the HTTP group would do such a thing, since it is
> > not needed for the usual use of HTTP which is to access
> documents on
> > a server.
> >
> >
>