AW: [Issue] Review of draft-ietf-radext-digest-auth-01.txt

["Beck01, Wolfgang" <BeckW@t-systems.com>]

> Here is my review of the document: 
> http://www.drizzle.com/~aboba/RADEXT/dig-rev-01.txt
> 
Thanks Bernard.

[Abstract]
Your proposal:
"The HTTP Digest authentication mechanism, defined in RFC 2617, has also been
adapted to use with SIP, as defined in RFC 3261."
The draft was motivated by SIP, but SIP is only a minor aspect.

Proposal:
"This document specifies an extension to the Remote Authentication
Dial In User Service (RADIUS) to enable support of Digest Authentication
as defined in RfC 2617."

[Migration Path to Diameter]
We had some discussion about this. If we move it to Diameter, Miguel Garcia
suffers from the dependency. Someone has to bear it. Both documents have
finished WGLC in parallel.

[boilerplate sections in TOC]
I'll try to convince xml2rfc to do that.

[HTTP Digest introduction]
Your proposal is lacking the motivation for the use of RADIUS.
"This document defines an extension to the RADIUS protocol to enable 
support of Digest authentication, for use with both SIP and HTTP."
This seems a bit too narrow, as there are people evaluating to use
HTTP digest for other HTTP-style protocols, like MSRP or RTSP.
Proposal:
"This document defines an extension to the RADIUS protocol to enable 
support of Digest authentication, for use with HTTP-style protocols like 
SIP and HTTP."

[Figure 1]
Somebody found figure 2 too detailed and demanded a simpler picture,
like the current figure 1. Your proposed figure seems to be a good
compromise.

[mapping of HTTP Authentication parameters into RADIUS attributes]
We are still in an Overview Section here, so I think that being vague
doesn't hurt too much.

[mix of nonce generation modes]
It's a matter of RADIUS client configuration. The client has to be configured
anyway, as not all RADIUS servers will support this extension. If a RADIUS
client generates a nonce locally and sends an Access-Request to a server
that wants to generate nonces itself, this will result in an Access-Reject
(the server does not recognize the nonce). If a RADIUS client demands a nonce
from a RADIUS server that is not able to generate nonces, this will result
in an Access-Reject, too.

[format of attribute descriptions]
Somebody on the list complained about that the repeated
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |   Text..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
boxes are redundant as none of the attributes is structured.

[Interpretation of Access-Request messages containing a Digest-Response attribute]
If the RADIUS server discovers a CHAP-Password attribute, it uses CHAP authentication.
If the RADIUS server discovers Digest-Response, it uses Digest authentication.

[Length of Digest-Response]
Miguel Garcia pointed out that different digest algorithms might use
different response lengths.

[SHOULD in Digest-Qop section]
RfC 2617 uses SHOULD, too. If the Digest-Qop is not present, the
HTTP response will not contain a qop= parameter.

[SHOULD in Digest-Algorithm section]
RfC 2617 defines the algorithm parameter as optional. If it
is missing, MD5 is assumed.

[Digest-Entity-Body-Hash with other algorithms]
The attribute can be re-used as the Digest-Algorithm indicates
the digest algorithm to use.

[Digest-Auth-Param in Access-Reject]
This wa meant for extensibility but I don't know of a concrete use case.
I'll restrict it to Access-Request, Access-Challenge, and Access-Accept.

[RADIUS client behaviour, about moving parts of the description to the Overview section]
I am not sure if it is possible to explain the process without describing
each step. As an implementor, I would not like to flip back and forth.

The idea was to give a step-by-step instruction.

[RADIUS client behaviour, acceptance of https/sips]
I'll add a reference to the Security Considerations section.
Explaining it here will add too much detail to a text which
is already quite detailed.

[Limitations of RADIUS/Diameter interopability]
The Diameter draft was a result of 3GPP requirements and did not care
about the early sterman draft. We can't fix this limitation in RADEXT.

[Table of attributes]
When doing the table, I was copying from some other RADIUS draft. I don't
think a table is the best way to show complex relationships, like
"if attribute x is present, attribute y is mandatory".

[Security Considerations, attacker gets access]
-> attacker gains control of the RADIUS client or RADIUS proxy.

[Security Considerations, performance requirements]
This sentence emphasizes the consequences of the previous one.

[Security Considerations, comparison with layer 2 access RADIUS]
The layer 2 access controlled by NASes is a much more constrained
environment than the open Internet which is the 'access network'
of a HTTP- or SIP proxy.

[Security Considerations, Message-Authenticator]
I did not include Message-Authenticator (and User-Name) in the table,
as they are defined elsewhere. I'll fix that.

[Security Considerations, RADIUS connection]
Right, it's not a layer 4 connection. Is 'flow' a better term?


(I did not include comments where I agree with you)


Wolfgang


--
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 




--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>