Issue 138

[wolfgang.beck01@t-online.de]

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

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