Subject: RE: [Sip] Network Asserted Identity

From: "Mary Barnes"<[email-masked]>
Date: Thu, 9 May 2002 13:40:59 -0500

Hi all,

The only concern I have with NAI is purely wrt potential confusion with the
"Network Access Identifier" as defined in RFC 2486.  Back in the days that I
was working in the mobile IP and AAA space, this was a common term (per RFC
2794).  Maybe it's just me, but before I read the draft, I had assumed that
it was discussing the use of the RFC 2568 NAI in the SIP world, thus my
suggestion would be AI (Asserted-Identity).

Mary. 

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, May 09, 2002 12:31 PM
To: Watson, Mark [MDN05:EP10:EXCH]; [email-masked]'
Subject: RE: [Sip] Network Asserted Identity

I like Network Asserted ID best
NA From is okay, but if we DO decide to allow an NAI on a Reply To, for
example, 
we would need an NA-Reply-To, which has it's plusses and minuses
Network-From has the same problem Asserted-Indentity is okay, 
but not as nice a Network Asserted ID

On the hint, I don't understand why From isn't the hint.  Could you explain?
Assuming there is a good reason, I'd use the same header name.  
That kind of makes Asserted-Identity a better choice.

Brian
-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Thursday, May 09, 2002 12:42 PM
To: [email-masked]'
Subject: [Sip] Network Asserted Identity

All, 

Revision of the requirements draft coming soon. 
In the meantime there are two issues which we did not completely bottom out
at the meeting. It would be good if we could conclude on these asap,
particularly as 3GPP has a meeting next week at which I hope they will
incorporate this new IETF work into their spec.
1) Name of the identity header 
The following have been suggested: 
Network-Asserted-ID: 
Authenticated-Identity: 
NA-From: 
Network-From: 
Asserted-Identity: 
others ? 
Comments on these are: 
Network-Asserted-ID has an acronym clash with Network Access Identity from
AAA. 
Authenticated-Identity is not appropriate use of the term 'Authenticated' as
the identity is not actually accompanied by a signature
Asserted-Identity: what is an 'unasserted' identity ? 
Suggestions & votes please! (If you vote in order of preference I can do a
Single Transferable Vote election). 
2) UA 'hint' to authenticating proxy 
One of the 3GPP requirements was for the UA to be able to supply a 'hint' to
the Authenticating Proxy in the case that the UA has several identities.
i.e. the UA could choose from several possible NAIs. Cullen's draft proposes
that the same header be used for this purpose. If there are objections to
this please speak now!! The alternative would presumably be a P-Header for
this.
Regards...Mark 

_______________________________________________
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: "Mark Watson"<[email-masked]>
Date: Fri, 10 May 2002 10:46:45 +0100

So, all votes so far are for 'Asserted-Identity'.

To answer the obvious 'asserted by whom ?' question, I suggest some text
along the following lines (for Cullen's draft, not the requirements):

'In the absence of other indications, a node receiving an Asserted-Identity
header must assume that it is asserted by the node from which it was
received (assuming integrity protection on this hop). This does not by
itself imply that the sending node has the right to assert the identity, or
that the identity has any validity.

So, for example, if the nodes are members of the same Trust Domain and the
receiving node trusts the node from which the Asserted-Identity was received
(in the sense of [nai-reqs]), then the sending node can be assumed to have
the right to assert identities on behalf of the Trust Domain. In this case
the Asserted-Identity is a Network Asserted Identity as defined in
[nai-reqs].

Alternatively, if a proxy receives an Asserted-Identity header from a UA,
then the Asserted-Identity represents only the UA's preference as to its
identity for Network Asserted Identity purposes. As with any header, in the
absence of some integrity protection between the UA and the proxy, there is
no guarantee that the identity has not been modified in transit.'

I will also update the requirements to include the 'hint' case.

Regards,

Mark

> From: Dean Willis [mailto:[email-masked]]
> Sent: 09 May 2002 20:09
> To: 'Rosen, Brian'; Watson, Mark [MDN05:EP10:EXCH]; [email-masked]
> > On the hint, I don't understand why From isn't the hint.  
> > Could you explain? Assuming there is a good reason, I'd use 
> > the same header name.  
> From: isn't the hint because there may need to be network assertion of
> identity even when there is a privacy request from the user. Unless we
> want proxies munging From: (insert my many arguments here) 
> then the hint
> needs to be in another place that CAN be proxy-munged. This leaves the
> UA responsible for its From: field (sets "anonymous" or equiavelent if
> privacy required) which is cleaner and has better
> backward-compatibility.
> 
> I like "Asserted-Identity", as future techniques lets us say WHO
> asserted the identity, and it might be "the network", the user, or a
> third-party authentication service.
> 
> --
> Dean
> 
>