Re: Issues List Revision

[Pete McCann <mccap@lucent.com>]

Hi,

I went back to review the status of Issue 6.  It looks to me like it
is all ok in draft-ietf-radext-digest-auth-00.txt except for the
security related issue.  The proposed resolution from Wolfgang is ok
with me but I don't see the promised reference to the security
considerations.

One additional comment inserted into Wolfgang's text below...

Wolfgang Beck wrote:

> > The following is confusing:
> >
> > 3.1  RADIUS Client Behaviour
> >
> >    A RADIUS client without an encrypted or otherwise secured connection
> >    to its RADIUS server only accepts unsecured connections from its
> >    HTTP-style clients (or else the clients would have a false sense of
> >    security).
> >
> > It is not quite clear what is meant by "encrypted or otherwise
> > secured", because there are several different security mechanisms
> > available in RADIUS, including the hop-by-hop message authenticator
> > and the shared-key method of obfuscating individual attributes.  I
>
> "encrypted" ~ eg. IPSEC or proprietary tunnel technology
> "otherwise secured" ~ eg. RADIUS client and server are in a closed MPLS
> VPN.

Can you make it clear in this text that the shared-key method for
encrypting individual attributes is not acceptable in this case?

> > assume this would not be adequate to provide the protection you are
> > looking for.  Also, what counts as an "unsecured connection" from an
> > HTTP-style client?  Do you mean one that doesn't use either TLS or
> > IPSec?
>
> Yes. I'll insert a reference to the security considerations section,
> which has this paragraph:
>   "HTTP-style clients can use TLS with server side certificates together
>    with HTTP-Digest authentication.  IPSec can be used in a similar way.
>    TLS or IPSec secure the connection while Digest Authentication
>    authenticates the user.  If a RADIUS client accepts such connections,
>    it MUST have a secure connection to the RADIUS server."
> 
> > Maybe this paragraph is adequately covered by the security
> > considerations (or should be) and could be deleted.
>
> I disagree. If a SIP client wants the signalling to be secure,
> it uses sips: URLs. All SIP proxies along the way must use TLS
> connections to forward requests with sips: URLs. I don't think
> the SIP proxies (=RADIUS clients) should expose parts of the SIP
> message by using a unencrypted RADIUS messages in this case.
> 
> As this is part of the client behaviour, I put it into that section.




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