Subject: RE: [Sip] Very minor nits on section 22 Security Considerations i n bis-07

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 18 Feb 2002 04:22:18 -0600

Thanks for your comments, Hisham, for this and the other comments on
sections 21 and 20. These are really quite helpful.

Some notes resulting from all three of your mails on the security sections
below.

Jon Peterson
NeuStar, Inc.

--- On 22:

> -----Original Message-----
> From: Hisham Khartabil [mailto:[email-masked]]
> Sent: Friday, February 15, 2002 9:37 AM
> To: [email-masked]; [email-masked]
> Subject: [Sip] Very minor nits on section 22 Security 
> Considerations in
> bis-07
> 
> 
> These are very minor nits, but I'm sending them anyway to complete my
> review.
> 
> Line numbers refer to the pdf version.
> 
> Section 22
> - line 4203: "is" should be "are".
Actually, "is" refers back to the "the set", not to "of security services",
so I think it should stay singular.

> 
> Section 22.3.2.3
> - I thought we were still talking about Alice until Carol's name was
> mentioned. Perhaps Carol should be introduced :)
I would hope that by this point in the spec Carol would be an old friend. :)
I think it's clear that a new agent is introduced in the start of 22.3.2.3.

--- On 21:

> Section 21.1
> - All SHOULDs and MAYs in the last 2 paragraphs of this section should be
> lower case. They are not protocol related.
Well, agreed that they are not protocol related, they are normative
guidelines for the implementation of user agents. I do believe that we want
to encourage particular ways of acquiring certificates because they are
conducive to protocol security.

> 
> Section 21.3
> - line 4036: the sentence is incomplete in the .txt version.
Fixed. Damn those single ticks (`).

> 
> Section 21.4.1.1
> - Its true that Via can be modified by a proxy, but at least 
> the sent-by field can be checked.
Agreed, but we're discussing the end-to-end rather than hop-by-hop
procedures for the interpretation of these headers. None of these procedures
override the typical UA behavior for evaluating Via headers.

> 
> Section 21.4.1.2
> - lines 4064 to 4067: So, are the outer headers used to identify a dialog
> (session)? Are the outer ones used to compute the Branch-id? this needs to
> be mentioned at the end of that paragraph. BTW, it should mention
somewhere
> that the TU is the one who decrypts (if I haven't missed it).
I believe it's clear that the outer headers are used to identify a dialog,
and that they are used to compute the branch-id, from 4065 specifically
(which says that the inner headers are not used to identify dialogs or
transactions). I don't think we really have any vision for where S/MIME fits
into the SIP component model - you're probably right that it is the
transaction user (it certainly isn't in the transport layer ;), but I don't
think we especially need to detail that.

> 
> Section 21.4.2
> - line 4098: "In order to eliminate possible confusions about the addition
> or subtraction of entire headers, senders SHOULD replicate all headers
from
> the request within the signed body". "replicate" gives the false
impression
> that the outer header values shouldn't be changed. It should read "In
order
> to eliminate possible confusions about the addition or subtraction of
entire
> headers, all outer headers SHOULD reappear in the inner message, some
header
> values MAY differ".
This section (as the title suggests) is intended to be specifically about
integrity and authentication, rather than confidentiality. When the message
is created, if it is only to be signed, all header field values from the
"outer" message SHOULD be equivalent to the header field values in the
"inner" message, I believe. So I think the text should stand.

> 
> - line 4102: "or" should be "and".
Actually, I think these two options do point to two different circumstances,
although I am a little concerned if this is unclear. Sometimes the integrity
violation will be associated with a response rather than a request, in which
case it will not be possible to 'respond' to the response with an error. All
the UAC can do when it receives a response with an integrity failure is send
a BYE, when appropriate, to terminate any existing dialog that might happen
to be in place - if there is no dialog, it can report the error condition
and presumably have no further congress with the remote endpoint. So I think
this is properly a disjunction rather than a conjunction.

> 
> Section 21.4.3
> - This section talks about tunnelling encrypted SIP messages with
> content-type of message/sip. It also talks about how a From header can
have
> anonymous. Yet, the example does not reflect that at all, it only has a
> normal encryption of SDP. This example should perhaps be moved to section
> 21.3 and a new example
Good point. We have already restructured the examples a bit, actually, in
preparation to bis08, and I think they are better now. The new example in
this section actually shows a (properly) encrypted and signed
application/sip (yes, it is application/sip rather than message/sip in bis
08) body, which 21.4.3 currently does not. 21.3 has an example now as well,
of an encrypted application/sdp body. And fortunately, the example in 21.4.3
now does show the Anonymous usage.

--- On 20:

> Section 20.1
> -lines 3746 to 3751: I believe this paragraph should mention something
about
> the handling of ACK for a 401/407 response to an INVITE. It is recommended
> that no state should be kept for unauthenticated requests (transactions).
I'm not sure I follow. One always needs to send an ACK to a final response
regardless of whether or not the respondent is actually keeping any state.
This paragraph is about whether or not someone can challenge an ACK (we say
it shouldn't be allowed). Agreed, though, that one should not keep state for
unauthenticated requests (we discuss this in the DoS Solutions section of
22).

> 
> Section 20.2
> - lines 3774 and 3784: the first line talks about parameters applicable to
> the Request-URI and the second talks about credentials for the To field.
So,
> which one is it for? or are they 2 different things and I am just lost
here?
Well, 3774 is talking about how the WWW-Authenticate gets generated by a
server sending a challenge. 3784 is talking about how credentials are cached
in the user agent after a request is retried once a 401/407 is received.
Clearly between the time that the UAC sends the request (when the
Request-URI and the To field SHOULD be equal) and the time that the
challenging server receives the request, the Request-URI may have been
retargeted by one or more intermediaries. To make a long story short, I do
think the two are separable issues.

> 
> Section 20.3
> - line 3856: "When a proxy server issues a challenge in response to a
> request, it will not proxy the request until the UAC has provided valid
> credentials". Better to read "When a proxy server issues a challenge in
> response to a request, it will not proxy any new request from that UAC
until
> it has been provided valid credentials".
Agreed that my version isn't that great. How about "... until the UAC has
retried the request with valid credentials"? We talk about retrying requests
a bit back in the General UA Behavior section; I think this is the right
language to use here.

> 
> - lines 3869 to 3872: So what happens? Does the UAC include multiple
> Authorization / Proxy-Authorization headers in the new request for the
same
> realm? I say yes. This needs to be mentioned.
This may follow from 3843-3845, where it talks about credentials being
'consumed' by proxies. That would suggest to me that you need on
Authorization/Proxy-Authorization header per challenge (which we say
explicitly in 3866-3867). It's a corner case; I'm not sure whether we really
need to say "yes" or if it will be obvious. The fact that you weren't sure
which way to take it does suggest that it's not obvious. We'll spell it out.

_______________________________________________
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