And the way to deal with this is some obscure ietf nanny text in some
document
that may or may not be read by developers? I'm sorry, but I don't find
this a very
compelling way to go about fixing this kind of problem.
But if you're going to do this at all, at least instruct them that they
should only
try the SIP downgrade at first contact, so that you don't have to keep
exposing
yourself on subsequent invitations. Telling them to not do it at all is
about the
worst advise because it will be ignored.
Mike
Rai, Anupam (Anupam) wrote:
An active attacker could very well DoS the SIPS attempt making it look
like "reciever was down". Hence downgrade must never bet attempted under
such condition. There must be some explict indication, like the one
discussed here, to indicate that contact does not accept SIPS.
-Anupam
-----Original Message-----
From: Michael Thomas [mailto:[EMAIL PROTECTED]
Sent: Monday, July 30, 2007 1:55 PM
To: Eric Rescorla
Cc: IETF SIP List; Rohan Mahy; Francois Audet; Paul Kyzivat;
[EMAIL PROTECTED]
Subject: Re: [Sip] draft-ietf-sip-sips-05: 480 vs. 418
Eric Rescorla wrote:
At Mon, 30 Jul 2007 09:19:04 -0700,
Michael Thomas wrote:
Eric Rescorla wrote:
At Fri, 27 Jul 2007 09:39:06 -0700,
Michael Thomas wrote:
Rohan Mahy wrote:
Michael,
At issue here is what the default implementor is likely to do.
With a new 4xx, the misguided but well-meaning implementor is
likely to try to "helpfully" "repair" the error without
thinking
about or understanding the security context.
Using a Warning code raises the bar significantly, but still
allows automata to at least log what happened.
As I said, a receiver is completely at liberty to prevent the
downgrade by not accepting the downgraded request.
Unless, of course, someone is impersonating the receiver.
Given how tangled up SIPS is, I really no idea what you're talking
about, or whether it's even responsive to my suggestion. Last I
heard, the entire raison d'etre of SIPS was that the next hop is
cryptographically identified via TLS. I'm guessing that you're not
suggesting that TLS is useless against impersonation attacks.
Of course not.
The point here is that if a caller automatically downgrades
to SIP, an
active attacker can then intercept the request and accept it,
regardless of the receiver's preferences.
Um, so? That's the risk that the sender takes by sending
stuff in the clear. And where's the problem here anyway? The
steps are: try SIPS, then try SIP.
If the
first succeeds, there's no attack. So it's only in some slim
window of when the receiver was down, or something like that.
Doesn't seem to me to be something to get all exercised
about, especially when you factor in all of the other
insecurities associated with SIPS.
Mike
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
