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

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

Eronen Pasi (Nokia-NRC/Helsinki) wrote:
> 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 protected]] 
>> Sent: 07 June, 2006 12:08
>> To: Eronen Pasi (Nokia-NRC/Helsinki)
>> Cc: Jo Hermans; [email protected]; 
>> [email protected]; 
>> [email protected]; 
>> [email protected]; Tammi Kalle 
>> (Nokia-NET/Tampere); [email protected]
>> Subject: Re: [AAA-WG]: 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
>>
>>
> 

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