I've been trying to ignore this, but guess I will jump in.
In what I would consider a "normal" case, a server that wants to
authenticate a request will either have exactly one realm that it uses,
or else will at least be able to select a realm based on information
(not authentication information) in the request.
For example, normally I think authentication will be done on outgoing
requests. Something in the request (e.g. From or P-Preferred-Identity)
will indicate the identity the sender wants to assert. Then the realm
would be chosen to be consistent with that.
It is *possible* (though IMO not likely) that authentication would be
required on the terminating side. (You must know the magic password to
call this person.) In that case, the realm might be chosen based on the
target address.
And I suppose that some server in the middle (perhaps involved based on
an explicit Route header) might provide some service and want to
authenticate before providing the service. It could make a decision of
realm as if it was part of either the originating or terminating side,
as above, or neither in which case I guess it will just have to decide
in its own way.
I don't think the concept of challenging based on all the realms the
server supports, and expecting the caller to pick one, works. If the
caller receives a 407 Proxy Authenticate with multiple challenges, I
believe it will think it must provide credentials for *each* challenge,
rather than just picking one. (Normally this case would arise because of
challenges from multiple independent proxies.) Perhaps the situation is
different for a 401 response, but I doubt it.
So I think, one way or another, that the challenging server must make
its own decision about what realm to challenge for.
Paul
Peili Xu wrote:
Yes, I totally agree with what you mentiond.
But I think the problem we are discussing is about whether to provide auth
related info in initial request or not. If the server have no idea about the
destination realm the user want to log in ,it have to select a default one
to challenge?
So if applicable, it`s better to provide auth info at lease user and realm
in initial request.
I don`t know if I have missed sth.
Thanks and best reguards!
Peili Xu
_________________________________________________________________
Peili Xu
System Engineer Core Network Research & Standard Department
Huawei Technologies Co., Ltd
Email: [EMAIL PROTECTED]
Phone: +86-755-28780808
Website: www.huawei.com
_________________________________________________________________
-----Original Message-----
From: Amarendra Kumar [mailto:[EMAIL PROTECTED]
Sent: Friday, July 15, 2005 1:30 PM
To: Peili Xu
Cc: Arunachalam Venkatraman (arunvenk); Dale Worley;
[email protected]
Subject: Re: [Sip-implementors] proxy servers multiple realm
Proxy server can configure itself for multiple realms. This can be
based on the resource
usage / groups/ subscriber basis. If for a user there can be more than
one realms
configured. Thus when ever request comes for the server it will
challenge with realms
configured. This is up to the end point how he will behave towards
it, means to say
end point can send authentication credentials to more than one realms
depending upon
the configuration property.
On 7/15/05, Peili Xu <[EMAIL PROTECTED]> wrote:
Carring Authorization even in initial request will ease the processing of
server. To provide "user" and "realm" is the point. Other files like
nouce,
response ... is not applicable for Initial request.
This may help the server to decide which realm the user belong to and
enforce the realm specific authentication policy. Eg. Select algorism.
_________________________________________________________________
Peili Xu
System Engineer Core Network Research & Standard Department
Huawei Technologies Co., Ltd
Email: [EMAIL PROTECTED]
Phone: +86-755-28780808
Website: www.huawei.com
_________________________________________________________________
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Arunachalam
Venkatraman (arunvenk)
Sent: Friday, July 15, 2005 12:23 AM
To: Dale Worley; [email protected]
Subject: RE: [Sip-implementors] proxy servers multiple realm
I believe an initial request may contain credentials using the most
recently offered nonce on a prior call. Nonce is not tied to a single
call or session.
Of course, there is no guarantee that the credentials will be accepted.
The server may accept the credentials if the nonce lifetime has not
expired and local policy allows it. Or, the server may re-challenge with
a new nonce. I would suspect that most servers currently do the latter.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dale
Worley
Sent: Thursday, July 14, 2005 9:16 AM
To: [email protected]
Subject: RE: [Sip-implementors] proxy servers multiple realm
From: Peili Xu [mailto:[EMAIL PROTECTED]
Since the final choice of the realm is decided by user.
Another possible way
is that user can config the associated realm in his terminal.
So that the initial Request can contain the realm information.
In my experience, user agents do not add authorization headers in
initial requests. I believe that this is because the proxy will not
accept an authorization header that does not contain a current nonce,
and the only way for a user agent to get a nonce is from a 407 response.
So there is no benefit in sending an authorization header to a proxy
that one has not recently communicated with, since one cannot include a
current nonce.
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
