Subject: [Sip] Review of draft-audet-sip-sips-guidelines-02

From: Eric Rescorla <[email-masked]>
Date: Fri, 07 Jul 2006 17:49:40 -0700

This draft attempts to clarify the underspecification of SIPS in RFC
3261. This seems like a good idea in principle, but at least from the
security guy perspective, I worry that this draft isn't completely
baked yet. I do hasten to add that this is the security guy
perspective, so there are probably SIP complexities I'm missing.

That said, ISTM that there are a number of problems that need to be
disentangled:

1. What a UA which is trying to contact a given URI 
   can expect in terms of how their messages will be
   handled.
2. What a UA can safely publish as their AOR and how
   to do it.
3. What a UA which receives a message can determine
   about how the message was handled.

This draft handles all of these issues together and I think
it would be best to handle them separately. Taking a step back,
I think we want the following:

1. A UA which tries to dereference a SIPS URI knows that
   as long as its dealing with compliant proxies its messages
   will be transmitted securely all the way to the peer.

2. A UA can make itself available in the following ways:
   - Secure only
   - Secure or insecure but hopefully if you're dealing
     with a secure peer then you both get secure.
   - Insecure only.
   So, AOR advertisement should support this.

3. A UA can determine (again assuming it's dealing with compliant
   proxies) whether the path from the peer was secure.

Do I have these requirements right?

Issue (1) needs to be dealt with by imposing rules about 
what the proxies do. I.e., that when presented with SIPS
they use TLS in the outgoing direction. The edge case--and
the one that's creating most of the heartbreak--appears to
be what happens inside of trust domains. 

Based on the discussion in this draft, Issue (2) breaks down
into two cases:

(a) What you advertise when you register.
(b) What you put in your own headers (i.e., the To).

Case (a) seems like it's relatively straightforward using the rules
described in S 5. It's case (b) that's tricky, due to the asymmetry of
"SIPS means you must use TLS to your first hop proxy" and "SIPS means
you may or may not use TLS between the last hop proxy and the final
destination".  Since that last link is about to become the first
hop, this seems highly problematic.

ISTM that there are two natural fixes for this:

(a) Decree that SIPS means TLS all the way (this is a lot less
    problematic in the face of outbound than it otherwise
    would be.)
(b) Decree that it's none of our business what happens inside
    people's trust boundaries and so SIPS only means secure
    in between them.

This draft, however, takes neither approach and instead attempts
to thread the needle between these. I'm not sure that this is
practical--and it's certainly creating a lot of complexity.

Issue (3) seems like it ought to be solved the same way that it's
ntended to be solved in RFC 3207 (STARTTLS): examine the Via lines
or something like them. I would ignore the URI entirely here, especially
in view of the confusion noted above.

DETAILED COMMENTS:
S 5.1:
I'm not sure why you need TLS transport to do a registration
of a SIPS contact.

S 6.

   If a UAS does not support SIPS, it MUST reject a request over TLS
   with response code 416. 

I don't understand how this can happen. Can you explain?
  
   Upon receiveing a 416 a UAC SHOULD not re-
   attempt the request with a SIP URI by automatically replacing the
   SIPS scheme with a SIP scheme.  If the UAC does re-attempt the call
   with a SIP URI, it SHOULD inform to the user that the security level
   is downgraded.

Shouldn't this last SHOULD be a MUST? It seems like a security condition.

   The presence of a SIPS Request-URI does not necessarily indicate that
   the request was sent end-to-end securely. 

The presence by the time you receive it, right? CAuse it should mean
that at the sender....

   26.4.4/RFC 3261 also explains that S/MIME may also be used by the
   originating UAC to ensure that the original form of the To header
   field is carried end-to-end.  While not specifically mentioned in
   26.4.4/RFC 3261, this is meant to imply that [RFC3893] would be used
   to "tunnel" important headers (such as To and From) in an encrypted
   S/MIME body, replicating the information in the SIP message, and
   allowing the UAS to validate the content of those important headers.
   While this approach is certainly legal, another approach is to use
   the SIP Identity mechanism defined in [I-D.ietf-sip-identity].  SIP
   Identity creates a signed identity digest which includes, amongst
   other things, the AOR of the sender (from the From header) and the
   AOR of the original destination (from the To header).  It is
   RECOMMENDED that a UAC use the mechanism in [I-D.ietf-sip-identity]
   instead of the one defined in RFC 3893.

You say "encrypted" here, but you really mean signed, right?

S 13.
I'm not sure I find this that helpful.

S 14.
It seems to me that most of these rules have security implications.

-Ekr

   

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 10 Jul 2006 13:41:27 -0500

FA> -----Original Message-----
FA> From: Eric Rescorla [mailto:[email-masked]] 
FA> Sent: Friday, July 07, 2006 5:50 PM
FA> To: [email-masked]
FA> Subject: [Sip] Review of draft-audet-sip-sips-guidelines-02
FA> 
FA> This draft attempts to clarify the underspecification of 
FA> SIPS in RFC 3261. This seems like a good idea in principle, 
FA> but at least from the security guy perspective, I worry 
FA> that this draft isn't completely baked yet. I do hasten to 
FA> add that this is the security guy perspective, so there are 
FA> probably SIP complexities I'm missing.
FA> 
FA> That said, ISTM that there are a number of problems that need to be
FA> disentangled:
FA> 
FA> 1. What a UA which is trying to contact a given URI 
FA>    can expect in terms of how their messages will be
FA>    handled.
FA> 2. What a UA can safely publish as their AOR and how
FA>    to do it.
FA> 3. What a UA which receives a message can determine
FA>    about how the message was handled.
FA> 
FA> This draft handles all of these issues together and I think 
FA> it would be best to handle them separately. Taking a step 
FA> back, I think we want the following:
FA> 
FA> 1. A UA which tries to dereference a SIPS URI knows that
FA>    as long as its dealing with compliant proxies its messages
FA>    will be transmitted securely all the way to the peer.
FA> 
FA> 2. A UA can make itself available in the following ways:
FA>    - Secure only
FA>    - Secure or insecure but hopefully if you're dealing
FA>      with a secure peer then you both get secure.
FA>    - Insecure only.
FA>    So, AOR advertisement should support this.
FA> 
FA> 3. A UA can determine (again assuming it's dealing with compliant
FA>    proxies) whether the path from the peer was secure.
FA> 
FA> Do I have these requirements right?

Thanks Eric.

You are putting the finger on exactly where the problem is:
Sips was never really well-defined. The requirements where never
explicit.
We are faced with the "fait accomplit" of RFC 3261. 

What I am seeing now is the following:
- There is a group of people now that are trying to implement SIP-TLS
and
  can't make any sense of RFC 3261, and need guidance.
- There is another group of people who see flaws with the basic
requirements.

It's going to be tough to reconcile this...

FA> 
FA> Issue (1) needs to be dealt with by imposing rules about 
FA> what the proxies do. I.e., that when presented with SIPS 
FA> they use TLS in the outgoing direction. The edge case--and 
FA> the one that's creating most of the heartbreak--appears to 
FA> be what happens inside of trust domains. 
FA> 
FA> Based on the discussion in this draft, Issue (2) breaks 
FA> down into two cases:
FA> 
FA> (a) What you advertise when you register.
FA> (b) What you put in your own headers (i.e., the To).
FA> 
FA> Case (a) seems like it's relatively straightforward using 
FA> the rules described in S 5. It's case (b) that's tricky, 
FA> due to the asymmetry of "SIPS means you must use TLS to 
FA> your first hop proxy" and "SIPS means you may or may not 
FA> use TLS between the last hop proxy and the final 
FA> destination".  Since that last link is about to become the 
FA> first hop, this seems highly problematic.
FA> 
FA> ISTM that there are two natural fixes for this:
FA> 
FA> (a) Decree that SIPS means TLS all the way (this is a lot less
FA>     problematic in the face of outbound than it otherwise
FA>     would be.)
FA> (b) Decree that it's none of our business what happens inside
FA>     people's trust boundaries and so SIPS only means secure
FA>     in between them.
FA> 
FA> This draft, however, takes neither approach and instead 
FA> attempts to thread the needle between these. I'm not sure 
FA> that this is practical--and it's certainly creating a lot 
FA> of complexity.

Basically, I'm fetching for opinions on this.

Keep in mind that this is an individual draft still. We need people
to express opinions on this. 

As it stands, this draft is basically pointing out problems with
RFC 3261.

FA> 
FA> Issue (3) seems like it ought to be solved the same way 
FA> that it's ntended to be solved in RFC 3207 (STARTTLS): 
FA> examine the Via lines or something like them. I would 
FA> ignore the URI entirely here, especially in view of the 
FA> confusion noted above.
FA> 
FA> 
FA> DETAILED COMMENTS:
FA> S 5.1:
FA> I'm not sure why you need TLS transport to do a 
FA> registration of a SIPS contact.

My thinking is that if the registration itself is not secure, how can
the
Resources that are binding themselves to a sips URI with that
registration be
secure?

FA> S 6.
FA> 
FA>    If a UAS does not support SIPS, it MUST reject a request over TLS
FA>    with response code 416. 
FA> 
FA> I don't understand how this can happen. Can you explain?

Good point. It can't.

FA>    Upon receiveing a 416 a UAC SHOULD not re-
FA>    attempt the request with a SIP URI by automatically replacing the
FA>    SIPS scheme with a SIP scheme.  If the UAC does 
FA> re-attempt the call
FA>    with a SIP URI, it SHOULD inform to the user that the 
FA> security level
FA>    is downgraded.
FA> 
FA> Shouldn't this last SHOULD be a MUST? It seems like a 
FA> security condition.

I think that's from RFC 3261 verbatim.

FA> 
FA>    The presence of a SIPS Request-URI does not necessarily 
FA> indicate that
FA>    the request was sent end-to-end securely. 
FA> 
FA> The presence by the time you receive it, right? CAuse it 
FA> should mean that at the sender....

Correct.

FA> 
FA> 
FA>    26.4.4/RFC 3261 also explains that S/MIME may also be used by the
FA>    originating UAC to ensure that the original form of the To header
FA>    field is carried end-to-end.  While not specifically mentioned in
FA>    26.4.4/RFC 3261, this is meant to imply that [RFC3893] 
FA> would be used
FA>    to "tunnel" important headers (such as To and From) in 
FA> an encrypted
FA>    S/MIME body, replicating the information in the SIP message, and
FA>    allowing the UAS to validate the content of those 
FA> important headers.
FA>    While this approach is certainly legal, another approach 
FA> is to use
FA>    the SIP Identity mechanism defined in 
FA> [I-D.ietf-sip-identity].  SIP
FA>    Identity creates a signed identity digest which includes, amongst
FA>    other things, the AOR of the sender (from the From 
FA> header) and the
FA>    AOR of the original destination (from the To header).  It is
FA>    RECOMMENDED that a UAC use the mechanism in 
FA> [I-D.ietf-sip-identity]
FA>    instead of the one defined in RFC 3893.
FA> 
FA> You say "encrypted" here, but you really mean signed, right?

I believe it's all of them for S/MIME.

No encryption for SIP Identity.

FA> 
FA> S 13.
FA> I'm not sure I find this that helpful.

It's helpful for the author.... The idea would be to remove it later.

FA> S 14.
FA> It seems to me that most of these rules have security implications.

Yes. It should really say TBD....

FA> -Ekr
FA> 
FA> 
FA> 
FA> 
FA> 
FA> 
FA> 
FA> 
FA> 
FA> 
FA> 
FA> 
FA> 
FA>     
FA> 
FA> 
FA> 
FA> 
FA>    
FA> 
FA> _______________________________________________
FA> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
FA> This list is for NEW development of the core SIP Protocol 
FA> Use [email-masked] for questions on 
FA> current sip Use [email-masked] for new developments on 
FA> the application of sip
FA>

---

From: EKR <[email-masked]>
Date: Mon, 10 Jul 2006 11:49:59 -0700

> Resources that are binding themselves to a sips URI with that

Well, what if it happened on some walled garden network?

> It's helpful for the author.... The idea would be to remove it later.

That makes sense...

-Ekr