Subject: RE: [Ieprep] Security Requirements for SIPPING

From: "King, Kimberly S." <[email-masked]>
Date: Thu, 17 Oct 2002 08:52:36 -0400

Which security requirements in the document are already offered by SIP and
which ones represent new functionality?

For example:

SEC-4 says ETS users may use devises that are not their own.  

REQ-3 implies the resource priority mechanism is a valid SIP message (this
follows from the definition of what it means to be able to pass through the
SIP/RTP transparent network model)

May I infer that the features needed to support the signaling for resource
priority will then be a part of the normal feature set for SIP end nodes?  I
think the answer is yes.

Previously, I asked:
>  In other words, must all SIP 
> proxies support
> hop-by-hop protection?  

Henning replied:
> They should as of today: Section 26.3.1 of RFC 3261 reads
> 
>     Proxy servers, redirect servers, and registrars MUST 
> implement TLS,
>     and MUST support both mutual and one-way authentication.  It is
>     strongly RECOMMENDED that UAs be capable initiating TLS; 
> UAs MAY also
>     be capable of acting as a TLS server.
> 

SEC-9 added hop-by-hop encryption was needed to protect fields like 'to' or
'via'.

Assume that features needed to support the signaling for resource priority
will then be a part of the normal feature set for SIP end nodes along with
the security requirements.  Does this imply that the behavior for UAs would
need to be modified to say they MUST be capable of initiating TLS?

My questions center around "what security requirements represents something
SIP, SIP proxies, SIP end nodes, etc. don't already support"?
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 18 Oct 2002 12:11:19 -0400

> SEC-4 says ETS users may use devises that are not their own.  

This can be done with existing SIP implementations, but it probably 
won't work with existing devices, as they don't "export" their 
challenges. While I'm not aware of any implementations, it is quite easy 
to layer a one-time password (OTP) scheme on top of SIP Digest. The 
untrusted device would only be given a secret that's valid once and 
can't be used for anything else. This requires no extensions to SIP, but 
a draft describing the mechanism wouldn't hurt. This would be 
independent of ETS.

> priority will then be a part of the normal feature set for SIP end nodes?  I

Indeed. Currently, I see no special protocol enhancements that are 
required to support the security needs of ETS. Operationally, systems 
may require stronger measures than they might for ordinary calls. As 
noted, making any detailed recommendations is beyond the scope of a 
protocol requirements draft, although pointing out the particular 
vulnerabilities seems harmless.

> need to be modified to say they MUST be capable of initiating TLS?

No, this is not necessary. A user can already insist on an encrypted 
signaling session by using the RFC 3261 sips:  URI scheme. If the 
terminal (UA) does not support this, the caller trying to place an ETS 
call then has to make a judgement call and accept reduced signaling 
confidentiality or forego making the call.

> SIP, SIP proxies, SIP end nodes, etc. don't already support"?

I hope the above clarifies this issue. As with other protocols, SIP 
security is a continuum, not a "is insecure/is secure" binary choice. I 
suspect the largest security threat in practice may well be people 
losing their GETS cards while going through airport screening...