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

[Bernard Aboba <aboba@internaut.com>]

> [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.

I agree that one of the drafts does need this section.  However, the
RADIUS Digest authentication is on a tight time schedule and I am
concerned about delays that could result from keeping this section in it,
particularly since the Diameter SIP document is likely to be blocked
based on the lack of compatibility with RADIUS Digest.  So my advice is to
move it to the Diameter SIP document.

> 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."

Fine.

> [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.

I found myself trying to get more details early on.  Much of the material
in Section 3 seems to be at the right level so some of it (a few
paragraphs) could be moved up.

> [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.

Can you say this in the document?


> [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.

The issue is that the typing appears to be wrong in several places.

> [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.

What confused me is that you used SHOULD instead of MUST about this.  Is there a
situation where Digest attributes are present where CHAP should be used instead?

> [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.

You might add a few words to this effect.

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

Can you mention this?

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

Can you mention this?

> [Digest-Auth-Param in Access-Reject]
> This was 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.

Thanks.

> [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.

Usually the step-by-step occurs *prior* to the attribute definition, not after.

> [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.

I realize that -- but the result is that Diameter and RADIUS won't
interoperate and this is a major problem.  That's why the Diameter/RADIUS
gateway material needs to move to the Diameter SIP document, to keep the
debate from delaying this document.

> [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".

Nevertheless that is what previous RADIUS RFCs have done using notes.  As
it is, one has to search throughout the document to find this material.

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

Can you clarify?

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

I'd try "transaction".


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