If the request is made before the expiry of nonce validity period,
then I you can send auth
related info. But this is not the case always. So if server don't have
any idea of the
destination realms, only thing it can do is challenge with the realms
configured at the
server.
Sending of authentication credential will always
depend on previously
established session. and validity of the nonce. If I had one session
long time back then
my initial request should not contain the Auth info, lets the server
assign a new nonce
for this, as I can't rely on the authenticity of the Auth info sent in
the request. If at all we
sending auth info, it will create extra processing on the server side.
When authentication is enabled, and any request coming to the
server will be challenged with the realms configured at the server-end
(if it has no idea about the
destinations realms). But when multiple servers are involved (says S1
and S2), then request will be challenged by both of them.
Case1: (very first session to be established)
A -----INV--------->S1-----INV----->S2----->B
In this case the intial Request should not contain the Auth info, as
end point is not sure of
the authenticity of the Auth info sent.
A will be challenged when request has reached S1 with realms
configured at S1. once A
has sent the INVITE again with authentication credentials it will be
forwarded to S2. Now
S2 will challenge with realms configured. the final INVITE will
contain authentication
credentials of both of the servers.
Case2:
S2--------------------B
/
/
A-----------S1/----------S3------------ C
In this case if A previously had a session established with B, The
path followed is
A--------S1---------S2----------B. Thus A will have the nonce for S1.
Lets say A is going
to send INVITE to C (path followed: A---S1----S3-----C). Then in this
case the initial INVITE
should contain the Authentication credentials, which will be validated
at server S1. And S1
will not challenge (only if nonce value has not expired), and request
will be forwarded to S3.
In this case when second session is being established, that initial
request should contain
the Auth info (if the time difference is not much between previously
established dialog &
current one)
On 7/15/05, Peili Xu <[EMAIL PROTECTED]> 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
> >
>
>
> --
> Rgds,
> Amar
> Mobile: +919886395894
>
>
--
Rgds,
Amar
Mobile: +919886395894
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
