: Re: why is Digest-Nextnonce mandatory ?

Hi Jo:

Well, first of all, I wouldn't like to start a discussion on brand 
names, so please, keep the brands out of the IETF discussion.

I am also surprised if there are terminals, I mean, endpoints, 
implementing Diameter, since it is clearly a network protocol. Perhaps 
you are referring to the fact that endpoints expect the nextnonce in the 
Authentication-Info header of a 200 OK response in SIP. So, presumably, 
those implementations follow RFC 2617. If this is the case, no matter 
whether we change the Diameter SIP application or not we will change the 
behavior of RFC 2617.

But having said that, I see the contradiction in RFC 2617: on one side, 
the nextnonce is mandatory, on the other, the text suggest that it is 
optional "If the nextnonce field is present ...". In the Diameter SIP 
application we just transposed the ABNF in RFC 2617 to Diameter AVPs.

So, I would like to gather a better understanding of people who might 
know better RFC 2617: is there an error in the ABNF definition in the 
Authentication-Info header? Should the nextnonce be optional?

If we determine that this is the case, we can always make the 
Digest-Nextnonce AVP optional during AUTH48 (providing that our ADs 
accept the change). In case of doubt, to be on the safe side, we should 
probably do the change.

Please comment.

/Miguel

Jo Hermans wrote:
> I have a problem with the Digest-Nextnonce parameter in the
> Sip-Authentication-Info attribute in the MAA, which becomes the
> AuthenticationInfo header in the 200 OK of SIP. We've recently seen an
> issue with Nokia terminals that are insisting that this is a mandatory
> parameter (according to draft-ietf-aaa-diameter-sip-app-12.txt, but
> originating from RFC2617 section 3.2.3). Our code is more based on
> draft-ietf-radext-digest-auth-09.txt, where it is optional.
> 
> I agree that those Nokia terminals are according to the spec, but I
> have to deal with our HSS that does not want to send back a nextnonce,
> mostly out of fear of the remark in RFC2617 section 3.2.2 (about
> problems in pipelining requests). At the same time, those people
> insist on having mutual authentication between client and server, so
> we need to Authentication-Info header in the 200 OK. Because the
> nextnonce is mandatory, we can't send that header at all. I'm stuck
> between a rock and a hard place at the moment. I now have to make the
> decision to either remove the entire header (removing mutual
> authentication), or adding a dummy nextnonce (which will cause a 401
> later on).
> 
> I want to know if there's a reason why the nextnonce is mandatory in
> the spec. Is it only RFC2617 ? As far as I can see (changes from
> RFC2069), it looks like a typo to me, and it should be optional. If it
> was really mandatory, the next paragraph would have been changed too
> ("if the nextnonce field is present ..."). And you still have the
> problem with the pipelining (we've already encountered them, for
> instance in a phone that send 2 INVITE's in parallel, in order to set
> up a conference).
> 
> I know it's very late, and Last-Call of
> draft-ietf-aaa-diameter-sip-app is already past. But INHO,
> Digest-Nextnonce should be an optional parameter, so that
> Authentication-Info can be used for mutual authentication, without a
> Next-Nonce. RFC2617 is probably incorrect, and conflicts with RFC3261
> anyway. What's your opinion ?
> 
> The issue has been mentioned in :
> - http://www1.ietf.org/mail-archive/web/sipping/current/msg08387.html
> (no response)
> - http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue45
> (rejected by Miguel, but he answered me that it's possibly wrong)
> 

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