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

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=20
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/=20

Best regards,
Pasi

> -----Original Message-----
> From: Miguel Garcia [mailto:[email protected]]=20
> Sent: 07 June, 2006 12:08
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: Jo Hermans; [email protected];=20
> [email protected];=20
> [email protected];=20
> [email protected]; Tammi Kalle=20
> (Nokia-NET/Tampere); [email protected]
> Subject: Re: [AAA-WG]: Re: why is Digest-Nextnonce mandatory ?
>=20
> Pasi:
>=20
> Thanks for the clarification in the 'special' ABNF of RFC 2617. If we=20
> take that into account, then we should make the nextnonce an=20
> optional AVP.
>=20
> What puzzles me is how other headers are defined in RFC 2617. Take a=20
> look at the ABNF of the WWW-Authenticate header in Section 3.2.1:
>=20
>        challenge        =3D  "Digest" digest-challenge
>=20
>        digest-challenge  =3D 1#( realm | [ domain ] | nonce |
>                            [ opaque ] |[ stale ] | [ algorithm ] |
>                            [ qop-options ] | [auth-param] )
>=20
> Doest this mean real and nonce shall always be present or=20
> not? At least=20
> in the Diameter SIP application the Digest-Realm and Digest-Nonce are=20
> mandatory AVPs in the grouped SIP-Authenticate AVP.
>=20
> Similar question pops up with the Authorization header, whose ABNF in=20
> RFC 2617 is:
>=20
>         credentials      =3D "Digest" digest-response
>         digest-response  =3D 1#( username | realm | nonce | digest-uri
>                         | response | [ algorithm ] | [cnonce] |
>                         [opaque] | [message-qop] |
>                             [nonce-count]  | [auth-param] )
>=20
>=20
> does it mean username, real, nonce, digest-uri, and response are=20
> mandatories? Their corresponding AVPs are mandatory too!!!
>=20
> /Miguel
>=20
>=20
>=20
> Eronen Pasi (Nokia-NRC/Helsinki) wrote:
> > Miguel Garcia wrote:
> >=20
> >> 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=20
> definition
> >> in the Authentication-Info header? Should the nextnonce be=20
> optional?
> >=20
> > It looks like RFC2617 uses the ABNF notation (defined in RFC2616) in
> > a way that is not really consistent with the ABNF semantics:
> >=20
> >    auth-info          =3D 1#(nextnonce | [ message-qop ]
> >                           | [ response-auth ] | [ cnonce ]
> >                           | [nonce-count] )
> >=20
> > 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=20
> fact, it looks
> > like the rule is equivalent to both of these:
> >=20
> >    auth-info          =3D 1#(nextnonce | message-qop
> >                           | response-auth | cnonce
> >                           | nonce-count )
> >=20
> >    auth-info          =3D 1#( [ nextnonce ] | [ message-qop ]
> >                           | [ response-auth ] | [ cnonce ]
> >                           | [ nonce-count ] )
> >=20
> > In other words: any string containing at least one of the parts=20
> > (not necessarily nextnonce) matches this ABNF, and more precise
> > specification of when the different parts have to be present is=20
> > in the descriptive text.
> >=20
> > 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=20
> > in RFC2617 have this same problem).
> >=20
> > Best regards,
> > Pasi
>=20
> --=20
> Miguel A. Garcia           tel:+358-50-4804586
> sip:[email protected]
> Nokia Research Center      Helsinki, Finland
>=20
>=20