Download
draft watson sipping nai reqs n.
Skip this Video
Loading SlideShow in 5 Seconds..
draft-watson-sipping-nai-reqs PowerPoint Presentation
Download Presentation
draft-watson-sipping-nai-reqs

draft-watson-sipping-nai-reqs

114 Views Download Presentation
Download Presentation

draft-watson-sipping-nai-reqs

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. draft-watson-sipping-nai-reqs Short term requirements for Network Asserted Identity

  2. Network Asserted Identity Motivation • Two motivations: • Network intermediaries (proxies or ‘CSCFs’ in 3GPP) need a reliable authenticated identity of the caller • Don’t want to or can’t repeat SIP Digest authentication with every intermediary • User Agent will find a more reliable user identification useful, if UA cannot Authenticate other UA directly

  3. Short Term Applicability • Immediate requirement is for a mechanism which works within a ‘Trust Domain’ • Nodes in a Trust Domain are known (by the human network designers) to obey the Network Asserted Identity specifications (‘Spec(T)’ where T is the Trust Domain , AT => A obeys Spec(T)) • A given node in the Trust Domain knows (by configuration) about some other nodes in the domain • Nodes in the domain are securely interconnected

  4. Terminology • Node A is ‘trusted by’ Node B iff: • Node B ‘knows’ (by configuration) that Node A is in the Trust Domain, and • There is a secure connection between Node A and Node B (integrity, confidentiality) • Symmetrical within network - A trusts B iff B trusts A (this is just for simplicity) • A Proxy can be ‘trusted by’ a UA (asymmetrical)

  5. Implications of Trust Domain model • If A trusts B then A can ‘safely’ pass (private) NAI to B, because: • Connection to B is secure • A knows that B will ‘follow the rules in Spec(T)’ i.e. the (private) NAI will not be passed to nodes outside the domain • If B trusts A then B can ‘safely’ use NAI received from B, because • Connection from A is secure • B knows that A has ‘followed the rules in Spec(T)’ i.e. the NAI can be relied on

  6. Out of scope • How to identify privacy requirements • Privacy services required (+ user/subscriber debate etc.) • Contents/meaning of From: field

  7. Requirements • NAI1: generate NAI and pass to ‘trusted’ nodes • NAI2: A sends NAI to B for case A does not trust B, but B does trust A NAI received from a node you do not trust is garbage – DISCARD!

  8. Requirement not addressed • User Agent providing ‘hints’ to network entity to help generate NAI • E.g. User Agent’s ‘preferred’ NAI – where it has several that would be equally valid from the network’s point of view

  9. Additional Issues • How many NAIs ? • Possibility of a user with both a SIP URI and a TEL URI ? • NAI is ‘Network Asserted version of From:’ – what about Network Asserted version of Reply-To, Call-Info etc. etc. • Parties with NAI ? • Sender of message (Request or response) • Privacy of NAI • User must indicate privacy preference for NAI. • Privacy: header ? Timing ?

  10. Items for decision • Requirements to WG item ? • Solution discussion to SIP list ? • Revision of Remote-Party-ID ? OR • New draft (Cullen’s Network-Asserted-ID ?) • To WG item after list discussion ? • Move forward to 3GPP timescale ? • ‘Hints’ requirement