Re: : SIP: Description of mode selection appears to be self-contradictory

Miguel Garcia <[email protected]> Tue, 18 Oct 2005 10:02:28 +0300
Newsgroups gmane.ietf.aaa
Message-ID <[email protected]>
Glen Zorn (gwz) wrote:

> Description of issue: Description of mode selection appears to be
> self-contradictory
> Submitter name: Glen Zorn
> Submitter email address: [email protected]
> Date first submitted: 17 Oct 05
> Document: sip
> Comment type: T
> Priority: S
> Section: 5.4
> Rationale/Explanation of issue: Paragraph 5 says "The Diameter client in
> SIP server 2 first makes a decision, based on configuration, whether to
> operate in the mode where nonces are generated in the Diameter client or
> in the Diameter server.  Then the Diameter client requests
> authentication parameters by sending a Diameter Multimedia-Auth-Request
> (MAR) message (step 5) to the Diameter server."  However, later in the
> same paragraph it says "The Diameter server responds with a Diameter
> Multimedia-Auth-Answer (MAA) message (step 6), which includes a nonce
> and all the rest of the parameters necessary for the designated
> authentication algorithm associated with the user.  Among others, the
> MAA message includes a Digest-HA1 AVP that contains H(A1) (as defined in
> RFC 2617 [RFC2617]), and that allows the Diameter client to calculate
> the expected response.  Then   the Diameter client can compare this
> expected response to with the response to the challenge sent from the
> SIP UA.  The absence of the Digest-HA1 AVP in [the] MAA indicates that
> authentication and authorization takes place in the Diameter server, as
> per the scenario described in Section 5.3", which implies that the
> Diameter server is, in fact, deciding whether or not the verification of
> the credentials is delegated to the client.  What happens if the client
> has decided to verify credentials itself, but no Digest-HA1 AVP is
> present in the MAA message?  
> 
> Requested change: Clarify the mode selection process.
> 

So, before answering your question, I would like indicate that there are 
two orthogonal issues here:

- One is the mode of operation with respect the generation of nonces. 
Nonces can be generated in the Diameter Client or the Diameter Server. 
This assumes configuration in both the client and the server.

- The other is the final authentication check, a process that can take 
in either the Diameter Client of the Diameter Server. Here the Diameter 
server is configured to do the final authentication itself or to 
delegate it in the Diameter client.

In this last issue, we carefully selected the word "Delegation of 
authentication to the SIP server". I think the word "delegation" is clear:

Delegate: to give or commit (duties, powers, etc.) to another as agent 
or representative; depute.

So, as for your question, the Diameter client can't ever decide to do 
the final authentication check by itself.

In my opinion, there is no action to be taken with this issue.

/Miguel

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