Re: : ISSUE: SIP application policy considered unmanageable

Glen Zorn (gwz) wrote:

> Description of issue: SIP application policy considered unmanageable
> Submitter name: Glen Zorn
> Submitter email address: [email protected]
> Date first submitted: 17 Oct 05
> Document: sip
> Comment type: T
> Priority: 1
> Section: All
> Rationale/Explanation of issue: Section 5.2 says "Whenever a SIP server
> receives a SIP request, it has to decide whether nonces for HTTP Digest
> authentication will be locally generated in the Diameter client or
> remotely in the Diameter server.  This is a decision derived from a
> policy that is configured in the SIP server/Diameter server."  It
> appears that this policy may vary from client to client and that all of
> these varied policies must be synchronized with the Diameter servers.  I
> see a couple of problems in this scheme: first, it flies in the face of
> the general rule that AAA servers dictate policy & clients follow it;
> secondly, in any but a tiny network these various policies will present
> a major management burden. 
> 
> Requested change: Make general recommendations as to the generation of
> nonces for the various flavors of authentication but remove the
> requirement of individual configuration of every client.
> 

A bit of history. There used to be ONLY one place to generate the 
nonces: the Diameter server.

But recently (March 2005), there were comments indicating that the 
RADIUS HTTP/SIP authentication draft was supporting another mode of 
operation where the nonces are generated in the RADIUS client. And the 
comment said that in order to provide compatibility with RADIUS, the 
Diameter SIP application had to implement that mode.

Honestly speaking, I don't like the generation of nonces in the Diameter 
client, BUT, I had to implemented due to those comments.

Is it crap? Probably, time will say. Will it be used? Probably not, time 
will say. Does it bring a configuration nightmare, due to the required 
synchronization between the server and the client? Yes. Can we improve 
this nightmare? I don't know how, perhaps removing the generation of 
nonces in the client... But if someone has a better proposal, I am able 
to listen to. I think "compatilibity with RADIUS" is the driver here.

Now, I essentially agree with your comments, but don't know how to 
change the draft. So, if you have a clear text to add, I will be happy 
to add it.

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email protected]
Nokia Research Center      Helsinki, Finland