Re: more minor Digest Auth editorial comments

]
] I have changed <message-body> to <entity-body> and added the two sentences:
]
]    The <entity-body> is the "entity body" as
]    prescribed in the Hypertext Transfer Protocol.  It consists of the
]    data transferred after the <CRLF><CRLF> signaling the end of the
]    entity headers.


I think there's a good argument that the <message-digest> should 
include at least the
entity-headers and Date: as well as the <entity-body>, and maybe the 
other headers,
too. This would prevent mucking with the Last-Modified, or 
Content-Type, etc, and
Date: would prevent substituting an old reply for a new one. (This was 
another of
Allan's points, BTW, that seems to have been left off of Larry's list. 
Sorry for not
mentioning it earlier, but I coudn't tell until getting the 
<message-body> thing clarified.
Actually it was two of his points  -- that the total request wan't 
authenticated, and that there was no freshness information.)

If this is a backwards compatibility problem, then a new optional parameter
"header=" could be used. This approach could also permit the separation of the
entity-headers from the rest of the headers -- a cache would need to cough up
entity-related digest that it got from the origin server, but construct 
a digest of the other
headers using its own secret that it shares with the client.

If this isn't too out of line, I'll write up specific proposed text.


] >
] > 2. In the security considerations section, the rationale for including
] > client IP in the recommended nonce needs to be given, over just
] > checking the IP address of a later request containing a nonce against
] > the IP address to which the nonce was originally given. Is it to
] > reduce the amount of state that the server needs to hold?
] >
]
] It is done so the server can be stateless.  As far as I know there
] are no stateful implementations of Digest Authentication.  I have
] added the following sentence to section 3.2
]
]    Digesting the client
]    IP and timestamp in the nonce permits an implementation which does
]    not maintain state between transactions.
]
]
] On a related topic, I don't want to move the recommended nonce
] construction material to an appendix.  This might make sense from
] an editorial point of view, but we were explicitly charged with
] expanding the nonce section and I want it to be very clear we have
] met this charge, not just tacked on an appendix.

Makes sense to me. Then how about putting it into it's own subsection 
of section 2?  It's a bit of a long digression in the middle of the 
parameter descriptions for the WWW-Authenticate header, and if a 
description of how to construct a nonce when trying to avoid replays 
were added, that would only get worse. (Again, I'll write something on 
a replay protection nonce if you agree.)

Paul

Received on Wednesday, 28 February 1996 11:29:06 UTC