Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-rtpsec-06

[Ben Campbell <[e-mail]>]

Hi, any further thoughts?

Thanks!

Ben.

> On Jan 2, 2019, at 4:49 PM, Ben Campbell <[e-mail]> wrote:
> 
> Thanks for the response. Some additional comments inline:
> 
>> On Dec 30, 2018, at 4:56 PM, Russ Housley <[e-mail]> wrote:
>> 
>> Ben:
>> 
>> Thanks for the thoughtful and careful review.
>> 
>> Responding only to your Substantive Comments for now...
>> 
>>> §4:
>>> - general: The section explains the requirement that the AS and VS to be colocated with the caller and recipient UAs as because putting them in an intermediary could allow that intermediary to act as a MitM. Isn’t this more a question of trust than physical location? Users already need to trust the AS and VS for STIR to work at all. In particular, I don’t think it’s safe to imply that a local AS _can’t_ act as a MiTM unless the code is inspected (and perhaps signed) by a trusted entity.
>>> 
>>> For the record, I do not necessarily object to the colocation requirement; I’m just not entirely buying the explanation for it.
>> 
>> The SIPBRANDY profile is based on an end-to-end trust model.  The verification could take place at an intermediary, but to get the end-to-end assurance, the verification would need to be repeated at the end.
> 
> Does the draft actually say that somewhere I missed? I see text saying that an intermediary could do verification, but must not block or redirect calls due to an untrusted signing credentials. I don’t see anything that states the verification needs to happen again at the endpoint.
> 
> But in general, I think the section would benefit from more focus of what an e2e trust model really means. There’s mention of it in the second paragraph, but not really a definition. I also wonder how such a definition would apply to a decomposed endpoint. (e.g. a media server that separates SIP processing and (S)RTP processing)
> 
>> 
>>> - 2nd paragraph: "While intermediaries MAY provide the verification service function of STIR for SIPBRANDY transactions,”: That seems to contradict the statement in the following paragraph that the user agent implementations MUST implement both the AS and VS.
>> 
>> Again, verification could take place at an intermediary for their own purposes, but the end-to-end assurance is only provided if the check is made at the end as well.
> 
> See previous comments; does the draft actually say that somewhere?
> 
>> 
>>> §4.1:
>>> - General: This section talks about self-signed certs and TOFU. Would you characterize those as comprehensive security? I suspect not, since they offer more exposure to active attacks. But I’m not sure they qualify as “opportunistic”, since they don’t (necessarily) allow a fallback to cleartext. In any case, some text discussing this question might be helpful. (This also includes §4.2)
>> 
>> No, I would not characterize the use of self-signed certificates as comprehensive security.  This section is suggesting them as an alternative when other certificates are not available for the caller identity.  The PKI for telephone numbers is not yet available, but it is coming.  The PKI for a SIP URI without a telephone number (e.g. "sip:[e-mail]") is not being worked yet.  Sp, self-signed certificates give a way to start.  An active attacker could strip the signature altogether.
> 
> Does that mean you would lump it into “opportunistic”? Or do we have a third, in-between category?
> 
>> 
>>> - third paragraph: "This profile of STIR therefore relaxes the authority requirements of [RFC8224]”
>>> Does that require this draft to formally update 8224?
>> 
>> I do not think so.  RFC 8224 says:
>> 
>>  ...  Similar practices could be used to support opportunistic
>>  signing of SIP requests for UA-integrated authentication services
>>  with self-signed certificates, though that is outside the scope of
>>  this specification and is left as a matter for future investigation.
>>  Note, however, that even when using anonymous SIP URIs, an
>>  authentication service must possess a certificate corresponding to
>>  the host portion of the addr-spec of the From header field value of
>>  the request; accordingly, using domains like "anonymous.invalid"
>>  will not be usable by privacy services that simultaneously act as
>>  authentication services.  The assurance offered by the usage of
>>  anonymous URIs with a valid domain portion is "this is a known user
>>  in my domain that I have authenticated, but I am keeping its identity
>>  private.”
> 
> I was wondering if there were some other normative requirement in 8224 that was being relaxed. On a quick scan, I do not find any. Therefore perhaps this should be an “editorial” the language
> 
> 	"This profile of STIR therefore relaxes the authority requirements of [RFC8224] to allow the use of
>         self-signed keys for authentication services that are composed with
>         user agent”
> 
> ... suggests that this draft relaxes some specific requirement for this specific composition; that doesn’t seem to be true.
> 
> 
>> 
>>> §4.3: Does this draft need to formally update 4916? It’s not clear to me if this draft intends to update these, or is stating that these are some updates we should do in the future. The last paragraph suggests the latter, but the rest of the section seems to be more the former.
>> 
>> Yes, it probably should update RFC 4916.
> 
> If that is the case, I think the section needs to split the list of updates to clarify which are actually made by this draft, vs reserved for future work. (For example, I assume this draft is not going to update the examples to match 8224)
> 
>> 
>>> §4.4, last paragraph: Is there an expectation that the UA will alert the user if it allows the dialog to continue without media security?
>> 
>> Since the IETF does not normally get into user interface, the "if policy permits" language would allow the user to be involved in the decision, or it could be set by other means.
> 
> Okay.
> 
> I’m not going to insist, but I think one could offer (perhaps non-normative) guidance that there are security implications if a user thinks a session is secure when it is not.
> 
> Thanks!
> 
> Ben.
>