Subject: [Sip] History-Info status - Security open issue

From: "Mary Barnes" <[email-masked]>
Date: Fri, 16 Apr 2004 11:04:53 -0500

Hi all,

There are still two open issues around History-Info
(http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt )
that require list discussion: privacy and security.  I'll post some details
on the privacy proposal in a separate posting so that I can more easily
track the responses.  

On the security, based upon some of the discussion in the e2m, m2e, policy
adhoc (per my recollection and the notes at:
http://softarmor.com/sipping/meets/ietf59/notes/notes-cyrus-sipping-adhoc-ie
tf59.txt  ) there does not seem to be WG consensus that History-Info really
requires m2e (i.e. TLS may be sufficient).  I do agree that if there was an
m2e (and m2m) security mechanism in place for SIP at this point in time,
that the use of it for History-Info would add value and actually make
History-Info itself more useful to the end applications. 

What I would like to propose is that the draft reference the context of some
of these current works in progress in this area as informational and
possibly applicable to History-Info.  And, of course, define TLS as the
normative and mandatory security solution for History-Info. This results in
the security for History-Info initially being as robust as that of the other
headers added by Intermediaries (Via, etc.), per RFC 3261 and in the future,
could be made more robust.  In the end, it is up to the applications making
use of History-Info to choose the security solution that best meets its
requirements and if there is a m2m and m2e solution developed in the future,
applications can certainly take advantage of those.  

If there's general agreement on this approach, I believe this only requires
some minor rewording in section 3.2. The remaining work to complete the
draft would be updating and cleaning up the examples. 

[I realize that this will likely start a long thread on the more general
topic of m2e, which does need discussion, but if folks could, please,
upfront in their postings say whether they believe History-Info can and
should be progressed without that solution fully specified].

Regards,
Mary
[email-masked]

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 19 Apr 2004 15:38:15 -0400

I think it's fine to allow history-info to progress before we have e2m 
security nailed. Think of how many hacks we can deprecate (which themselves 
present the same security concerns) if we finally get this beastie 
last-called.

so, put me down in the "yes" column.

Dave.

--On Friday, April 16, 2004 11:04 AM -0500 Mary Barnes 
<[email-masked]> wrote:

> that require list discussion: privacy and security.  I'll post some
> details on the privacy proposal in a separate posting so that I can more
> easily track the responses.
>
> On the security, based upon some of the discussion in the e2m, m2e,
> policy adhoc (per my recollection and the notes at:
> http://softarmor.com/sipping/meets/ietf59/notes/notes-cyrus-sipping-adhoc
> -ietf59.txt  ) there does not seem to be WG consensus that History-Info
> really requires m2e (i.e. TLS may be sufficient).  I do agree that if
> there was an m2e (and m2m) security mechanism in place for SIP at this
> point in time, that the use of it for History-Info would add value and
> actually make History-Info itself more useful to the end applications.
>
> What I would like to propose is that the draft reference the context of
> some of these current works in progress in this area as informational and
> normative and mandatory security solution for History-Info. This results
> in the security for History-Info initially being as robust as that of the
> other headers added by Intermediaries (Via, etc.), per RFC 3261 and in
> the future, could be made more robust.  In the end, it is up to the
> applications making use of History-Info to choose the security solution
> that best meets its requirements and if there is a m2m and m2e solution
> developed in the future, applications can certainly take advantage of
> those.
>
> If there's general agreement on this approach, I believe this only
> requires some minor rewording in section 3.2. The remaining work to
> complete the draft would be updating and cleaning up the examples.
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 21 Apr 2004 14:59:28 -0700

Yes. Sounds reasonable to me.

On 4/16/04 9:04 AM, "Mary Barnes" <[email-masked]> wrote:

> (http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-02.txt ) that
> require list discussion: privacy and security.  I'll post some details on the
> privacy proposal in a separate posting so that I can more easily track the
> responses.  
> 
> http://softarmor.com/sipping/meets/ietf59/notes/notes-cyrus-sipping-adhoc-ietf
> 59.txt  ) there does not seem to be WG consensus that History-Info really
> m2e (and m2m) security mechanism in place for SIP at this point in time, that
> the use of it for History-Info would add value and actually make History-Info
> itself more useful to the end applications.
> 
> of these current works in progress in this area as informational and possibly
> applicable to History-Info.  And, of course, define TLS as the normative and
> mandatory security solution for History-Info. This results in the security for
> History-Info initially being as robust as that of the other headers added by
> Intermediaries (Via, etc.), per RFC 3261 and in the future, could be made more
> robust.  In the end, it is up to the applications making use of History-Info
> to choose the security solution that best meets its requirements and if there
> is a m2m and m2e solution developed in the future, applications can certainly
> take advantage of those.
> 
> some minor rewording in section 3.2. The remaining work to complete the draft
> would be updating and cleaning up the examples.
> 
> [I realize that this will likely start a long thread on the more general topic
> of m2e, which does need discussion, but if folks could, please, upfront in
> their postings say whether they believe History-Info can and should be
> progressed without that solution fully specified].
> 
> Regards, 
> Mary