[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issues List Revision
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
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
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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.