draft-ietf-radext-digest-auth, Securit Considerations section

[Pete McCann <mccap@lucent.com>]

This looks good, and resolves my issue.

-Pete

Beck01, Wolfgang writes:
 > Here's a proposal for the text regarding the encryption of RADIUS
 > which is required when accepting sips/https:
 > 
 >    HTTP-style clients can use TLS with server side certificates together
 >    with HTTP-Digest authentication.  Instead of TLS, IPSec can be used,
 >    too.  TLS or IPSec secure the connection while Digest Authentication
 >    authenticates the user.  The RADIUS connection can be regarded as one
 >    leg on the path between the HTTP-style client and the HTTP-style
 >    server.  To prevent the RADIUS link from being the weakest hop on the
 >    path, a RADIUS client receiving an HTTP-style request via TLS or
 >    IPSec MUST use an equally secure connection to the RADIUS server.
 >    There are two ways to achieve this:
 >    o  the RADIUS client rejects HTTP-style requests received over TLS or
 >       IPSec
 >    o  the operator of the RADIUS client takes actions to ensure that
 >       RADIUS traffic is exclusively sent and received using IPSec.
 >    When using IPSec, it MUST be set up as described [RFC3579] section
 >    4.2.
 > 
 > 
 > Wolfgang
 > 
 > --
 > T-Systems
 > Internet Platforms
 > +49 6151 937 2863
 > Am Kavalleriesand 3
 > 64295 Darmstadt
 > Germany 
 > 
 > --
 > 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/>


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