Re: : Re: why is Digest-Nextnonce mandatory ?

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

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