See my comments below...
Randy
Robert Herriot wrote:
>> The real issue here is that the protocol provides two channels for
> authentication information:
> a) in application/ipp layer as requesting-user-name attribute
> b) in the transport layer via some unspecified authentication mechanism
There is actually a (c) scenario:
c) where the authentication information comes from TLS.
>> I think we agree that if b) above provides no authentication information, then
> the user name comes from a). If neither channel provides a user name, then
> the user is "guest" or something similar.
Yes, I think we agree on this point, except I
would extend it to say that,
if (b) or (c) is not available for
authentication, and no requesting-user-name
is specified, then this is a request for
"anonymous" access to the resource.
if (b) or (c) is not available for authentication,
but a requesting-user-name is specified, then
the server is free to use the requesting-user-name
for authentication.
if (c) is not available, but (b) provides
authentication info, then use the
transport-specific auth info provided by (b).
The tricky part comes when both (b) and (c)
provide authentication information. In this
case, which authentication information takes
precedence?
In order to avoid a potential rathole with
regards to multiple layers of security, I
would like to state in the model document
that if TLS is used for the session, and
the TLS handshake provided auth info, that
the TLS auth info always take precedence.
At least with text like this we can
guarantee (in the model document)
interoperability between two implementations
that wish to use authentication.
Randy
..snip..