[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 138
I think your proposed solution does not move in the direction where
Bernard and me have been indicating: "the security of the RADIUS
exchange is a somewhat orthogonal issue from the security of the
HTTP/SIP Digest exchange."
There are connections betweeen the secure URI (https or sips) and the
presence/lack of security in the RADIUS interface. We indicated that
ther is no such link.
So, in my opinion, the issue is still open.
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
"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
o the RADIUS client require that traffic be sent and received over
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
Miguel A. Garcia tel:+358-50-4804586
Nokia Research Center Helsinki, Finland
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.