RE: draft-ietf-radext-digest-auth-06

"Nelson, David" <dnelson@enterasys.com> Tue, 18 October 2005 14:56 UTC

Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 18 Oct 2005 14:58:03 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-ietf-radext-digest-auth-06
Date: Tue, 18 Oct 2005 10:56:34 -0400
Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325F7@MAANDMBX2.ets.enterasys.com>
Thread-Topic: draft-ietf-radext-digest-auth-06
Thread-Index: AcXTAqnEMeAK+ZU7SHu4c48a+JmThwA8VDsg
From: "Nelson, David" <dnelson@enterasys.com>
To: radiusext@ops.ietf.org
Cc: miguel.an.garcia@nokia.com

Does this resolve RADEXT Issue 138?

> The latest version of the draft does no longer contain a link between
> sips/https and
> RADIUS. However, the Security Considerations section names refusing
> sips/https request as one non-normative option to avoid the security
> level mismatch of sips/https and unencrypted RADIUS:
> 
> "To prevent RADIUS from representing the weak link, a RADIUS
> client receiving an HTTP-style request via TLS or IPsec could use an
> equally secure connection to the RADIUS server.  There are several
> ways to achieve this, for example:
>    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."

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