Subject: [AAA-WG]: why is Digest-Nextnonce mandatory ?

From: "Jo Hermans" <[email-masked]>
Date: Tue, 6 Jun 2006 16:42:27 +0200

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)

-- 
Jo Hermans

"Eagles may soar, but weasels aren't sucked into jet engines"

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 07 Jun 2006 09:07:24 +0300

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

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

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 07 Jun 2006 12:08:18 +0300

Pasi:

Thanks for the clarification in the 'special' ABNF of RFC 2617. If we 
take that into account, then we should make the nextnonce an optional AVP.

What puzzles me is how other headers are defined in RFC 2617. Take a 
look at the ABNF of the WWW-Authenticate header in Section 3.2.1:

       challenge        =  "Digest" digest-challenge

       digest-challenge  = 1#( realm | [ domain ] | nonce |
                           [ opaque ] |[ stale ] | [ algorithm ] |
                           [ qop-options ] | [auth-param] )

Doest this mean real and nonce shall always be present or not? At least 
in the Diameter SIP application the Digest-Realm and Digest-Nonce are 
mandatory AVPs in the grouped SIP-Authenticate AVP.

Similar question pops up with the Authorization header, whose ABNF in 
RFC 2617 is:

        credentials      = "Digest" digest-response
        digest-response  = 1#( username | realm | nonce | digest-uri
                        | response | [ algorithm ] | [cnonce] |
                        [opaque] | [message-qop] |
                            [nonce-count]  | [auth-param] )

does it mean username, real, nonce, digest-uri, and response are 
mandatories? Their corresponding AVPs are mandatory too!!!

/Miguel

Eronen Pasi (Nokia-NRC/Helsinki) wrote:
> Miguel Garcia wrote:
> 
>> 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?
> 
> It looks like RFC2617 uses the ABNF notation (defined in RFC2616) in
> a way that is not really consistent with the ABNF semantics:
> 
>    auth-info          = 1#(nextnonce | [ message-qop ]
>                           | [ response-auth ] | [ cnonce ]
>                           | [nonce-count] )
> 
> clearly suggests to the reader that "nextnonce" has to be present,
> while the other parts are not always included. However, this is not
> what the ABNF actually means according to RFC2616.  In fact, it looks
> like the rule is equivalent to both of these:
> 
>    auth-info          = 1#(nextnonce | message-qop
>                           | response-auth | cnonce
>                           | nonce-count )
> 
>    auth-info          = 1#( [ nextnonce ] | [ message-qop ]
>                           | [ response-auth ] | [ cnonce ]
>                           | [ nonce-count ] )
> 
> In other words: any string containing at least one of the parts 
> (not necessarily nextnonce) matches this ABNF, and more precise
> specification of when the different parts have to be present is 
> in the descriptive text.
> 
> Since the descriptive text says "If the nextnonce field is present
> [..]", it's not actually in conflict with the ABNF. But the ABNF
> is clearly misleading (and it looks like some other ABNF rules 
> in RFC2617 have this same problem).
> 
> Best regards,
> Pasi

---

From: <[email-masked]>
Date: Wed, 7 Jun 2006 11:51:12 +0300

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 7 Jun 2006 13:15:10 +0300

Hi Miguel,

According to the RFC2616 definition of ABNF syntax and semantics,
they're all optional. But I think it's likely that this is 
not what the authors of RFC2617 actually meant!

Perhaps you should try raising this issue on this list to get
a more authorative answer than we can produce at AAA WG:
http://lists.w3.org/Archives/Public/ietf-http-wg/ 

Best regards,
Pasi

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: 07 June, 2006 12:08
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: Jo Hermans; [email-masked]; 
> [email-masked]; 
> [email-masked]; 
> [email-masked]; Tammi Kalle 
> (Nokia-NET/Tampere); [email-masked]
> Subject: Re: [AAA-WG]: Re: why is Digest-Nextnonce mandatory ?
> 
> Pasi:
>

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 13 Jun 2006 16:05:24 +0300

So, it's been a few days since I asked advice in the ietf-http-wg list, 
and I didn't get any.

Still I suspect there is a mistake in RFC 2617, at least there is a 
contradiction between the ABNF and the text, and we should make the 
Digest-Nextnonce optional.

If I don't here anything against, I will note this and request this 
change during AUTH48.

BR,

         Miguel