Subject: [Sipping] Network Asserted Identity (was: RE: Summary of RE: [Sip] Comment, SIP Privacy draft)

From: "Mark Watson"<[email-masked]>
Date: Mon, 15 Apr 2002 18:23:26 +0100

OK, so lets see if we can conclude on _short-term_ Network Asserted identity
requirements in a separate thread. Follow-ups to SIPPING ONLY please.

First, assume a trust domain model as per privacy draft applicability
statement. Entities within a domain trust each other, entities in different
domains are mutually untrusted.

I'll try to build up the requirements, least contraversial first:
NAI1) The ability for network entities to insert a network asserted identity
and pass to other network entities within the same trust domain.
NAI2) The ability for a network entity to pass a (non-private) network
asserted identity directly to a UA
NAI3) Secure transport of network asserted identity across 'untrusted'
networks back to the same trust domain (including between trust 'islands' -
disconnected parts of a single trust domain)
NAI4) Transport of network asserted identity between trust domains (i.e.
transport in one domain of a network asserted identity received from another
domain)

For clarity, 
(a) the requirement for a user to choose one of a number of identities,
whilst retaining privacy, is a 3GPP requirement, but is *out of scope* of
this thread.
(b) Call Trace implemented by encrypting the identity and passing this to
the called user, who can then pass the encrypted identity to the generating
service provider/authorities, is considered a sub-case of NAI3 - the
identity is passed to the 'untrusted' user and back to the original Trust
Domain (the Service Provider) before being passed to the authorities.

I expect the From/To debate will continue, probably to the end of time, but
I don't see a strong relationship with this issue.

If people agree with my statement of the potential requirements, perhaps we
could open discussion on which of these should be considered for immediate
standardisation. The others can be put into the pot for discussion of the
generic privacy requirements.

For my part, I am most concerned about NAI1 and NAI2.

Regards...Mark

> -----Original Message-----
> From: David R. Oran [mailto:[email-masked]]
> Sent: 15 April 2002 17:39
> To: 'Rosen, Brian'; [email-masked]; [email-masked]
> Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft
> 
> 
> Brian Rosen wrote:
> >If we could get consensus that trace-with-anonymity is the problem,
> then > we can
> > work on solutions.  Until we get to something as straightforward as 
> > that,
> > we are going to spin a lot of wheels.
> 
> That's always been the prime motivator for me, plus the 
> secondary use of
> NAI for call return to an anonymous caller.
> 
> Dave
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 15 Apr 2002 13:37:37 -0500

Network Asserted Identity (was: RE: Summary of RE: [Sip] Comment, SIP
Privacy draft)
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Mark Watson
  Sent: Monday, April 15, 2002 12:23 PM
  To: 'David R. Oran'; 'Rosen, Brian'; [email-masked]; [email-masked];
[email-masked]'
  Subject: [Sipping] Network Asserted Identity (was: RE: Summary of RE:
[Sip] Comment, SIP Privacy draft)

  OK, so lets see if we can conclude on _short-term_ Network Asserted
identity requirements in a separate thread. Follow-ups to SIPPING ONLY
please.

  I'll try to build up the requirements, least contraversial first:
  NAI1) The ability for network entities to insert a network asserted
identity and pass to other network entities within the same trust domain.

  What do we mean by secure? Does this mean non-disclosure of a _private_
NAI to the untrusted domain? Preventing the untrusted domain from tampering
with the NAI (private or otherwise)? I realize we may have discussed that
elsewhere, but we should capture it in the requirement nonetheless. (Note
that I am _not_ disagreeing for a change :-) )

  Should there be a "Secure" in this requirement as well?

  For clarity,

  I expect the From/To debate will continue, probably to the end of time,
but I don't see a strong relationship with this issue.

  If people agree with my statement of the potential requirements, perhaps
we could open discussion on which of these should be considered for
immediate standardisation. The others can be put into the pot for discussion
of the generic privacy requirements.

  Regards...Mark

---

From: Chris Martin <[email-masked]>
Date: Wed, 17 Apr 2002 20:24:35 -0500

> Mark Watson wrote:
> statement. Entities within a domain trust each other, entities in
> different domains are mutually untrusted.

Is this different than a "realm", as in wcom.com is a domain, but "wcom"
is a realm in the sip sense?

> identity and pass to other network entities within the same trust

insert a new header (like RPID)? or as in modification of existing
headers, I think you mean the first just want to be clear for own
edification? Agreee.

> asserted identity directly to a UA

non-private, as in an inbound identity contained in a request from an
untrusted entity to an internal (in relation to the SP domain) UA? If
so, I agree.

> networks back to the same trust domain (including between trust
> 'islands' - disconnected parts of a single trust domain)

Such as IPsec encryption, TLS, as an example, over untrusted networks?

> 
> NAI4) Transport of network asserted identity between trust domains
> (i.e. transport in one domain of a network asserted identity received
> from another domain)
> For clarity,
> (a) the requirement for a user to choose one of a number of
> identities, whilst retaining privacy, is a 3GPP requirement, but is
> *out of scope* of this thread.

What draft would be good to catch up on these requirements?

> 
> (b) Call Trace implemented by encrypting the identity and passing this
> to the called user, who can then pass the encrypted identity to the
> generating service provider/authorities, is considered a sub-case of
> NAI3 - the identity is passed to the 'untrusted' user and back to the
> original Trust Domain (the Service Provider) before being passed to
> the authorities.

This is interesting.

> 
> I expect the From/To debate will continue, probably to the end of
> time, but I don't see a strong relationship with this issue.

I kind of responded to this in a response to Christian, to the fact that
with the exception of the content/message body..the other fields may be
relevant. Think more discussion should be done in this respect to this
topic, (after the requirements are submitted  :^) )

> 
> If people agree with my statement of the potential requirements,
> perhaps we could open discussion on which of these should be
> considered for immediate standardisation. The others can be put into
> the pot for discussion of the generic privacy requirements.

agree with the requirements

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP