RE: digest-auth, nonce replay issue

["Nelson, David" <dnelson@enterasys.com>]

Wolfgang Beck writes...

> The application can not detect if the password was posted on a
> mailing list either.

I'm not sure it helps to resort to sarcasm.

> A pragmatic approach would be to spell out a warning in the
> manual or in the syslog 'If you plan to use such and that
> option, make sure your RADIUS traffic is protected or you'll
> be doomed'

I bet the marketing department will have something to say about your
choice of phrasing.  :-)

In point of fact, I understand that there is not a standard API that an
application can use to detect the current IPsec SAs in use for its
network connections.  IMHO, that is a severe failing of IPsec, but
that's a whole different discussion.

The question in this case, I think, is what assurances can the protocol
implementation make, and what assurances depend upon correct
configuration by human operators?  It is important that the Security
Considerations spell all this out in a clear fashion.  If the potential
attacks exceed the expectations of the threat model, then there are
substantial security flaws in the design.

> > That's why you have to specify the required level of clock
> synchronization...
>
> I feel a bit uneasy about this. When some technician plays with the
time
> zone, a whole SIP server won't be able to handle calls any longer.

That would be part of the "assurances that depend upon correct
configuration by human operators", right?


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