reported by Dean Willis
Minutes of SIP/SIPPING Interim Meeting May 7, 2002 Afternoon Session
Reported by Dean Willis
Privacy and Network Asserted Identity
Short Term Requirements: Mark Watson
Goal: Define requirements for short-term needs of limited scope as
used in 3G-phone networks. Defines "trust domain". Question: Is
there a requirement that if the next hop is not known to be
trusted, should you delete sensitive info before passing? answer
Yes. Does this imply an inverse requirement to delete info from an
untrusted entity? answer Uncertain.
Suggestion: Limit scope to "NAI-From" identity. Counter that a
version of NAI-Reply-To makes PSTN mapping to ISDN easier. Note:
Proxies cannot modify Reply-To in bis.
Comment: 3GPP needs in June, ITU needs in November for mapping.
Comment: We need higher-level requirements for "what are we using
this info for" to decide if we need more than NAI-From. For example,
it would be good to have detailed uses of NAI-Reply-To.
Comment: The operator seems to have no way to know the equivalent of
Reply-To: or vouce for it. Much discussion followed.
Chairs position: We seem to have consensus to address NAI-From in
short term. We also seem to have consensus to consider whether a
short term requirement for mapping "something" to the ISDN
"Station ID" may be relevant, but this appears to be a seperable
problem.
Long Term Requirements Discussion: Jon Peterson
#1 Key differentiator from short-term is answering the qustion "Who
asserted this identity"
#2 Key differentiator -- Short-term requires reliance on 3rd party
removal. Long-term presents identity in such a way that it may be
encrypted.
Point: It would be very nice to make the short-term solution a
subset of the long-term solution, such that the replacement could
be clean.
Issue: Still have to solve cert/algorithm/PKI problem space.
Point: We have three application mechanisms -- servlet, CGI,CPL
that have made assumptions about what they can access. These
generally have a preference to look at headers. CGI and servlet
could look at bodies if they had to, but CPL would be HARD.
Two credential-adding mechanisms:
1) Proxy with Added Body
2) Reject with request to Add.
Point: It may be better to characterize as "trust-based" vs. "cert
based" instead of "Short term" vs "Long term" models.
Timing: We will not have completed a solution based on the Jennings
draft by June 3. Our goal is now to have something in IETF Last Call
by then. Can we complete a spec that satisfies the Watson requirements
and migrates well to long-term in this time frame?
Point: NAI removal/encryption is somehow different from identity
privacy protection.
Point: anything involving encryption requires a whole different 3GPP
group and will cause further dealys.
Query: Does anybody object to making the long-term solution body
based.
Query do we have a requirement to use both kinds of mechanisms at
the same time. What combinations of this make sense?
Point: We still have a compounding between the identity expressed
and the level of trust given to that expression. We may be losing
a critical element of NAI, which is call trace. Both mechanisms
must support call trace.
Open issue for long-term model is transitivity of identity
accessibility across affiliation boundaries. There may be a need
to multiply encrypt. Some think this may be a common problem.
Point: Policy overrides mechanisms. Must define relationship of
call trace and trust boundary.
Suggestion: we should track "how we envision call trace" as a
seperate informational-track document.
Work plan: Fluffy will provide it in written form. In short,
we will provide a near-term solution with migration toward
a long-term plan.
Following reported by Cullen Jennings:
There was considerable discussion about privacy and identity
stuff at the interim meeting. At the time we were using the
terms short term and long term to describe the proposals. A
better description to separate the two would be cryptographic
and non-cryptographic approach.
The proposal from Jon, Mark, and I is to go forward by looking at
a solution that is something along the lines of:
1) Have a header called something like Asserted-Identity
2) In the non cryptographic solution, this header could appear
in the header portion of the message
3) In the cryptographic solution, this header could be used
in signed and encrypted sipfrags in the body of the message
We need to carefully think about the implications of both the
cryptographic and non-cryptographic solution existing and what
would happen as messages were passed from a network element
using one type to a network element using the other type.
Draft-sip-sec-agree -- Vesa Torvinen
Issue: The syntax for the Security-Mechanism is slighly askew from
the SIP norm and needs some retrofit for "stacking".
Question: What is the semantic of the To:/From:
Resolution: We have lots of issues. Further discussion moved to
list.
Enhanced Digest -- Sanjoy Sen
New: Authentication Info header, added "realm" and made generic.
Added integrity protetction, complete one-hop protection.
We don't seem to have a constituency for the complete one-hop
protection. This meachanism seems more useful from the perspective
of end-to-middle.
Will include recommendation for bid-down and produce seperate
documents on end-to-middle and middle to end.
Following reported by Sanjoy Sen:
The draft-undery-sip-auth-00.txt proposes four new enhancements:
1) Added realm to *-Authentication-Info and made it generic,
2) Allow detection of Bid-down attacks on algorithms and qop-options,
3) More Integrity protection (complete & negotiated headers),
4) Proxy Authentication
The general agreement was: re-write this draft as a RFC 2617-bis
keeping enhancements 1) and 2). This can be done immediately and
shouldn't be delayed (Henning). For 3) and 4) propose new use
cases for the general End-to-Middle and Middle-to-End security
problems ad produce a new draft.
10 May 2002 10:55 -0500