Thanks for your review, Francis, and for your responses, Rifaat.

Jari

On 06 Apr 2015, at 23:01, Rifaat Shekh-Yusef <[email protected]> wrote:

> Hi Francis,
> 
> Thanks for your review and comments. I will address the nits in the next 
> version of the draft.
> Please, see my reply to some of your comments inline...
> 
> Regards,
>  Rifaat
> 
> 
> On Mon, Apr 6, 2015 at 1:58 PM, Francis Dupont <[email protected]> 
> wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-httpauth-digest-15.txt
> Reviewer: Francis Dupont
> Review Date: 20150402
> IETF LC End Date: 20150402
> IESG Telechat date: unknown
> 
> Summary: Ready
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
>  I reviewed the 15 version but I can see the 16 one is already available
> so I'll try to update my comments.
> 
>  - first I was a bit surprised nobody just asked to jump to HTTPS (or
>   HSTS) but reading the document it seems there are still good use
>   of the digest authentication scheme...
> 
>  -  3.3 page 5: IMHO the "opaque" field is clearly a nonce
>   (i.e., more a nonce than the "nonce" field) but I understand this
>   was inherited from RFC 2617...
> 
>  - 3.3 page 7 (algorithm, twice) and some other places:
>   e.g. -> e.g.,
> 
>  - 3.3 page 7 (algorithm): I noted the algo protocol is still
>   a keyed one vs. HMAC (cf. AH which switched from keyed to HMAC
>   between RFC 1826 and RFC 2402) but I believed you have a good
>   reason to do this (and the secdir will say if it is OK anyway).
> 
> 
> Good question.
> Using HMAC would impact the H(A1) calculation and the KD function, but it 
> would definitely work.
> If there is interest and support for adding HMAC, I would be happy to do that.
> 
>  
>  - 3.4.2 page 11: e.g. -> e.g., (again but this one is at the end of a line)
> 
>  - 3.4.2 page 11: cnounce -> cnonce
> 
>  - 3.4.2 page 11: the presentation of this definition is very
>  misleading:
> 
>          A1       = H( unq(username) ":" unq(realm)
>                         ":" passwd )
>                         ":" unq(nonce-prime) ":" unq(cnonce-prime)
> 
>   I strongly suggest something like:
> 
>          A1       = H( unq(username) ":" unq(realm) ":" passwd )
>                         ":" unq(nonce-prime) ":" unq(cnonce-prime)
> 
> 
> Sure.
> 
>  
>  - 3.4.2 page 11: the server need only use
>                                  ^ needs
> 
>  - 3.5 page 14: affects -> effects
> 
>  - 5.2 page 21: this information need not be decrypted
>                                      ^ needs
> 
>  - 6.1 page 27: can you instantiate the RFC XXX:
>   MD5: RFC 1321
>   SHA-256: FIPS 180-2
>   SHA-512/256: FIPS 180-4?
> 
> 
> The RFC used in the table should point to the current draft which does not 
> have an RFC # yet.
> Kathleen has already raised an issue about this and she suggested a text that 
> was added to v16.
> 
> Regards,
>  Rifaat
> 
>  
>  - A page 30: negotitation -> negotiation
> 
> Regards
> 
> [email protected]
> 
> _______________________________________________
> Gen-art mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/gen-art

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to