Proposed text in section "RADIUS Client Behavior":
"If all of the following conditions are true, the RADIUS client MUST
act as if it had sent an Access-Request and the RADIUS server had
rejected the credentials with an Access-Reject packet:
o the scheme in the digest-uri directive indicates a secure HTTP-
style connection (e.g. sip or https).
o the packets between RADIUS client and RADIUS server are not
protected with IPsec.
Under those conditions, a typical implementation would reject the
HTTP-style request."
replaces:
"If the packets between RADIUS client and RADIUS server are not
protected with IPsec, the RADIUS client MUST NOT accept secured
connections (like https or sips) from its HTTP-style clients, so that
HTTP-style clients are not provided with a false sense of security."
The Security Consideration section gives some additional explanations.
The section contains a part:
"There are two ways to achieve this:
o the RADIUS client may reject HTTP-style requests received over TLS
or IPsec
o the RADIUS client require that traffic be sent and received over
IPsec.
RADIUS over IPsec, if used, MUST conform to the requirements
described in [RFC3579] section 4.2.
I think it's weak enough with respect to the "don't mandate SIP / HTTP
behaviour" requirement.
Wolfgang