Subject: Re: [sipcore] rfc4244bis #44 (new): 4244bis-02: security section misleading

From: Mary Barnes <[email-masked]>
Date: Mon, 25 Jul 2011 14:55:12 -0500

So, this is the issue that we were just discussing with regards to
SEC-req-1. Note that the text and references are from RFC 4244).  We did
remove this text from the Security section and we should really just remove
SEC-req-1.

Regards,
Mary.

On Mon, Nov 8, 2010 at 12:14 AM, Mary Barnes <[email-masked]>wrote:

> I agree.  Removing this is consistent with some of the earlier text we
> removed in terms handling and implications of missing information.
>
> Mary.
>
> On Sat, Nov 6, 2010 at 9:41 PM, sipcore issue tracker
> <[email-masked]> wrote:
> > #44: 4244bis-02: security section misleading
> >
> >  Section 9 says:
> >    With the level of security provided by TLS (SEC-req-3), the
> >    information in the History-Info header can thus be evaluated to
> >    determine if information has been removed by evaluating the indices
> >    for gaps (SEC-req-1, SEC-req-2).  It would be up to the application
> >    to define whether it can make use of the information in the case of
> >    missing entries.
> >
> >  No, TLS doesn't do that.  TLS only guarantees you that the next-hop or
> >  previous-hop is who its cert claims it to be (assuming you trust its
> >  anchor), and prevents tampering by something in-between you and that
> >  previous-hop or next-hop.  That doesn't mean that previous-hop or next-
> >  hop, or some upstream/downstream entity beyond it, did not modify the
> H-I
> >  entries - including in ways which you cannot possibly detect.  For
> example
> >  it could have renumbered them, changed their content, etc.
> >
> >  This section-9 paragraph is wrong, and we won't be able to satisfy the
> >  security requirements in appendix A.1  That's *OK*.  We're not going to
> >  get better than that.  In fact, we basically need that behavior, since
> we
> >  need PSTN Gateways to be able to generate H-I entries based on ISUP info
> >  (even for numbers they don't own); and we need Diversion interworked to
> >  H-I too.
> >
> > --
> >
> ------------------------------------+---------------------------------------
> >  Reporter:  hkaplan@…               |       Owner:
> >     Type:  defect                  |      Status:  new
> >  Priority:  minor                   |   Milestone:  milestone1
> > Component:  rfc4244bis              |     Version:  2.0
> >  Severity:  In WG Last Call         |    Keywords:
> >
> ------------------------------------+---------------------------------------
> >
> > Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/44>
> > sipcore <http://tools.ietf.org/sipcore/>
> >
> > _______________________________________________
> > sipcore mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
>