Subject: [Ieprep] Security Requirements for SIPPING SEC-6 to SEC-10

From: "King, Kimberly S." <[email-masked]>
Date: Tue, 15 Oct 2002 08:10:54 -0400

"SEC-6: Replay: The authentication mechanisms must be resistant to
replay attacks.

        SEC-7: Cut-and-paste: The authentication mechanisms must be
             resistant to cut-and-paste attacks.

        SEC-8: Bid-down: The authentication mechanisms must be resistant to
bid down attacks."

I suppose the above could be collapsed into one requirement that the
authentication mechanism is resistant to common attacks (e.g., replay,
cut-and-paste, bid down).

        "SEC-9: Confidentiality: All aspects of ETS are likely to be
             sensitive and must be protected from intercept and
             alteration. In particular, requirements for protecting the
             confidentiality of communications relationships may be
             higher than for normal commercial service. For SIP, the To,
             From, Organization, Subject, Priority and Via header fields  
             are examples of particularly sensitive information."

Aren't some of these fields important for SIP routing?  Do you have an
example solution in mind that would protect these fields?

       " SEC-10: Avoid exposing nature of request: In some circumstances,
             unauthorized users must not be able to discern that a
             particular request is using a resource priority mechanism,
             as that may reveal sensitive information about the nature
             of the request to the attacker."

How does SEC-10 differ from SEC-9?  Maybe you could just add one more
sensitive "field", i.e., the resource priority mechanism itself.
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Ian Brown <[email-masked]>
Date: Tue, 15 Oct 2002 13:23:46 +0100

Kimberly said:
>>...To, From, Organization, Subject, Priority and Via header fields...

Fields that aren't needed for routing can protected end-to-end using S/MIME.
Fields that are can only be protected hop-by-hop using a protocol such as
TLS.

> sensitive "field", i.e., the resource priority mechanism itself.

You also need to consider problems like: what if devices have to contact one
of a small set of authorisation servers to obtain a credential before making
an ETS call? An attacker could correlate a device making such a request with
a call that it made soon after, unless it had used some type of IP
anonymiser to contact the server.

---

From: Ken Carlberg <[email-masked]>
Date: Tue, 15 Oct 2002 13:32:25 +0100

> cut-and-paste, bid down).

i would prefer they not be.  Hennings draft is the one example of a
specific set of requirements targetted at a specific protocol.  If
we are to do generalizations, I'd prefer they be in other document(s),
not one going to SIPPING.

cheers,

-ken

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Oct 2002 09:12:29 -0400

I appreciate all the suggestions, but at some point it's also 
appropriate to ask "does it make a real difference?". This is a 
requirements document for SIPPING, not the US constitution.

---

From: Ken Carlberg <[email-masked]>
Date: Tue, 15 Oct 2002 14:30:51 +0100

> requirements document for SIPPING, not the US constitution.

agreed.  what i what i was trying to say in the last message is that 
I'd prefer to keep those security related requirements that were
cited "as is" -- ie, don't make changes.

as a side observation, I think its nice that folks are involved
and commenting.  so many times, people have to plead for comments.
but I get the feeling that Hennings document has been sufficiently
examined.  we run the risk of going down every conceiveable 
interpretation to the point where the document is never finished.

it would be nice if we could just get a freeze on it and allow henning
to fold in these last comments, and send it over to SIPPING.  

just my opinion.

-ken