Internet DRAFT - draft-watson-sipping-nai-reqs

draft-watson-sipping-nai-reqs



                

               Internet Draft                                             Mark Watson 
               Document: draft-watson-sipping-nai-reqs-00.txt         Nortel Networks 
                                                                                      
               Category: Informational                                                
               Expires  November 2002                                        May 2002 
                
                          Short term requirements for Network Asserted Identity 
                    
                  Status of this Memo  
                   
                  This document is an Internet-Draft and is in full conformance with 
                  all provisions of Section 10 of RFC2026.  
                       
                  Internet-Drafts are working documents of the Internet Engineering 
                  Task Force (IETF), its areas, and its working groups.  Note that 
                  other groups may also distribute working documents as Internet-
                  Drafts.  
                       
                  Internet-Drafts are draft documents valid for a maximum of six months 
                  and may be updated, replaced, or obsoleted by other documents at any 
                  time. It is inappropriate to use Internet-Drafts as reference 
                  material or to cite them other than as "work in progress."  
                       
                  The list of current Internet-Drafts can be accessed at  
                       http://www.ietf.org/ietf/1id-abstracts.txt  
                  The list of Internet-Draft Shadow Directories can be accessed at  
                     http://www.ietf.org/shadow.html.  
                       
                  Abstract  
                   
                  There is no requirement for identities identities asserted by a UA in 
                  a SIP message to be anything other than the user∆s desired alias. An 
                  authenticated identity of a user can be obtained using SIP 
                  authentication, however it is unlikely that the necessary Public Key 
                  Infrastructure to facilitate this for UAs will be available soon. 
                   
                  A Network Asserted Identity is an identity obtained by a SIP network 
                  intermediary as a result of an authentication process. This draft 
                  describes short term requirements for the exchange of Network 
                  Asserted Identities within networks of securely interconnected 
                  trusted nodes and to User Agents securely connected to such networks. 
                   
                  General requirements for transport of Network Asserted Identities on 
                  the Internet are out of scope of this draft. 
                    
                  Table of Contents 
                   
                   
               1. Introduction 
                   
                
                
               Watson                 Expires - November 2002               [Page 1] 
               Network Asserted Identity Ż short term requirements           May 2002 
                
                
                  SIP [1] allows users to assert their identity in a number of ways 
                  e.g. using the From: header. However, there is no requirement for 
                  these identities to be anything other than the users desired alias. 
                   
                  An authenticated identity of a user can be obtained using SIP 
                  Authentication (or by other means). However, it is unlikely that the 
                  necessary Public Key Infrastructure to globally facilitate this for 
                  users will be available soon. 
                   
                  A Network Asserted Identity is an identity obtained by a SIP network 
                  intermediary as a result of an authentication process. This may or 
                  may not be based on SIP authentication. This draft describes short 
                  term requirements for the exchange of Network Asserted Identities 
                  within networks of securely interconnected trusted nodes and also to 
                  User Agents with secure connections to such networks. 
                   
                  Such a network is described in this draft as a Trust Domain. These 
                  short-term requirements provide only for the exchange of Network 
                  Asserted Identitied within a Trust Domain. 
                   
                  General requirements for transport of Network Asserted Identities on 
                  the Internet are out of scope of this draft. 
                       
               2. Trust Domains  
                   
                  A Trust Domain for the purposes of Network Asserted Identity is a set 
                  of SIP nodes (UAC, UAS, proxiesor other network intermediaries) that 
                  are known to be compliant to SIP specifications for Network Asserted 
                  Identity. 
                   
                  This document presents requirements for such specifications. 
                   
                  Trust Domains are constructed by human beings who know the properties 
                  of the equipment they are using/deploying. In the simplest case, a 
                  Trust Domain is a set of devices with a single owner/operator who can 
                  accurately know the behaviour of those devices. 
                   
                  Such simple Trust Domains may be joined into larger Trust Domains by 
                  bi-lateral agreements between the owners/operators of the devices. 
                   
                  We say a node is śtrusted∆ (with respect to a given Trust Domain) if 
                  it is a member of that domain. 
                   
                  We say that one node in the domain is śtrusted by∆ another if: 
                   
                  (i) there is a secure connection between the nodes, AND 
                  (ii) they have configuration information to indicate that they are 
                  members of the same Trust Domain. 
                   
                
                
               Watson              Expires - NovemberOctober 2002            [Page 2] 
               Network Asserted Identity Ż short term requirements           May 2002 
                
                
                  This most often applies to network intermediaries such as proxies in 
                  the Trust Domain. 
                   
                  A śsecure connection∆ in this context means that messages cannot be 
                  read by third parties and cannot be modified or inserted by third 
                  parties without detection (e.g. IPSEC, TLS etc.). 
                   
                  We say that a node, A, in the domain is śtrusted by∆ a node, B, 
                  outside the domain if: 
                   
                  (i) there is a secure connection between the nodes, AND 
                  (ii) B has configuration information indicating that A is a member of 
                  the Trust Domain. 
                   
                  This most often applies to a UA which trusts a given network 
                  intermediary (e.g. its home proxy). 
                   
                  The term śtrusted∆ (with respect to a given Trust Domain) can be 
                  applied to a given node in an absolute sense Ż it is just equivalent 
                  to saying the node is a member of the Trust Domain. However, the node 
                  itself does not know whether another arbitrary node is śtrusted∆, 
                  even within the Trust Domain. It does know about certain nodes with 
                  which it has secure connections as described above. 
                   
                  With the definition above, statements such as śA trusted node SHALL 
                  ...∆ are just shorthand for śA node compliant to this specification 
                  SHALL...∆. 
                   
                  Statements such as śWhen a node receives information from a trusted 
                  node...∆ are NOT valid, because one node does not have complete 
                  knowledge about all the other nodes in the trust domain. 
                   
                  Statements such as śWhen a node receives information from another 
                  node that it trusts...∆ ARE valid, and should be interpreted 
                  according to the criteria (i) and (ii) above. 
                   
                  Within this context, SIP signaling information received by one node 
                  from a node that it trusts is known to have been generated and passed 
                  through the network according to the procedures of the particular 
                  specification set, and therefore can be known to be valid, or at 
                  least as valid as specified in the specifications. 
                   
               3. Transport of Network Asserted Identity 
                   
               3.1 Passing of Network Asserted Identity within a Trust Domain 
                   
                  It shall be possible for one node within a Trust Domain to securely 
                  pass a Network Asserted Identity to another node that it trusts. 
                   
                
                
               Watson              Expires - NovemberOctober 2002            [Page 3] 
               Network Asserted Identity Ż short term requirements           May 2002 
                
                
               3.2 Passing of Network Asserted Identity to entities outside a Trust 
                   Domain 
                   
                  It shall be possible for a node within the Trust Domain to securely 
                  pass a Network Asserted Identity to a node outside the trust domain. 
                   
                  This is most often used to pass a Network Asserted Identity directly 
                  to a UA. 
                   
                  A node SHOULD disregard Network Asserted Identity received from a 
                  node it does not trust. 
                  Note that a node outside the Trust Domain receiving this information 
                  MAY pass it on to other nodes. However, such information SHOULD NOT 
                  be treated as valid, since nodes outside the Trust Domain are not 
                  guaranteed to operate according to the Network Asserted Identity 
                  specification, and so may have modified the Network Asserted 
                  Identity. 
                   
               4. Parties with Network Asserted Identities 
                   
               4.1 Calling user 
                   
                  A Network Asserted Identity of the calling user shall be supported. 
                   
               4.2 Called user 
                   
                  A Network Asserted Identity of the called user shall be supported. 
                   
               4.3 Extensibility 
                   
                  It shall be possible to define further parties to whom Network 
                  Asserted Identities may relate in future. 
                   
               5. Types of Network Asserted Identity 
                   
                  Each party shall have at most one Network Asserted Identity. 
                   
                  It shall be possible for the capability to transport multiple 
                  identities associated with a single party to be introduced in future. 
                   
               6. Privacy of Network Asserted Identity 
                   
                  The means by which any privacy requirements in respect of the Network 
                  Asserted Identity are determined are outside the scope of this draft. 
                   
                  It shall be possible to indicate that a Network Asserted Identity is 
                  subject to a privacy requirement which prevents it being passed to 
                  other users.  
                   
                
                
               Watson              Expires - NovemberOctober 2002            [Page 4] 
               Network Asserted Identity Ż short term requirements           May 2002 
                
                
                  In this case, the Network Asserted Identity specification shall 
                  require that the mechanism of 3.2 SHALL NOT be used i.e. a trusted 
                  node shall not pass the identity to a node it does not trust. 
                  However, the mechanism of 3.1 MAY be used to transfer the identity 
                  within the trusted network. 
                   
                  It shall be possible to indicate whether the Network Asserted 
                  Identity is private due to a request from the user/subscriber or for 
                  another reason. 
                   
                  Note that śanonymity∆ requests from users or subscribers may well 
                  require functionality in addition to the above handling of Network 
                  Asserted Identities. Such additional functionality is out of the 
                  scope of this document. 
                   
               7. Next steps 
                   
                  It is proposed to rapidly specify a mechanism to meet the 
                  requirements of this draft. 
                   
                  It should be noted that the mechanisms of [2] meet all the above 
                  requirements (and some others). 
                   
               8. Security considerations 
                   
                  The requirements in this draft are NOT intended to result in a 
                  mechanism with general applicability between arbitrary hosts on the 
                  Internet. 
                   
                  Rather, the intention is to state requirements for a mechanism to be 
                  used within a community of devices which are known to obey the 
                  specification of the mechanism and between which there are secure 
                  connections. Such a community is known as a Trust Domain. 
                   
                  Such devices may be hosts on the Internet. 
                   
                  The requirements also support the transfer of information from a node 
                  within the Trust Domain, via a secure connection to a node outside 
                  the Trust Domain. 
                   
                  Use of this mechanism in any other context has serious security 
                  shortcomings, namely that there is absolutely no guarantee that the 
                  information has not been modified, or was even correct in the first 
                  place. 
                   
               9. IANA Considerations 
                   
                  This document does not have any implications for IANA. 
                   
                
                
               Watson              Expires - NovemberOctober 2002            [Page 5] 
               Network Asserted Identity Ż short term requirements           May 2002 
                
                
               10. References  
                   
                  [1] J. Rosenberg et al, ŰSIP: Session initiation protocol," draft-
                  ietf-sip-rfc2543bis-09.txt, February 27th, 2002. 
                    
                  [2] W. Marshall et al, "SIP Extensions for Caller Identity and                                                                       th                  Privacy", draft-ietf-sip-privacy-04.txt, February 27 , 2002.  
                   
                    
               11. Acknowledgments 
                     
                   
                   
                           
                      
               12. Authors∆ Addresses  
                       
                  Mark Watson 
                  Nortel Networks (UK) 
                  Maidenhead Office Park (Bray House) 
                  Westacott Way 
                  Maidenhead, 
                  Berkshire                     Tel: +44 (0)1628-434456 
                  England                       Email:  mwatson@nortelnetworks.com 
                               
                   
               13. Full Copyright Statement 
                      
                  Copyright (C) The Internet Society (2002).  All Rights Reserved. 
                      
                  This document and translations of it may be copied and furnished to 
                  others, and derivative works that comment on or otherwise explain it 
                  or assist in its implementation may be prepared, copied, published 
                  and distributed, in whole or in part, without restriction of any 
                  kind, provided that the above copyright notice and this paragraph are 
                  included on all such copies and derivative works.  However, this 
                  document itself may not be modified in any way, such as by removing 
                  the copyright notice or references to the Internet Society or other 
                  Internet organizations, except as needed for the purpose of 
                  developing Internet standards in which case the procedures for 
                  copyrights defined in the Internet Standards process must be 
                  followed, or as required to translate it into languages other than 
                  English.  The limited permissions granted above are perpetual and 
                  will not be revoked by the Internet Society or its successors or 
                  assigns.  This document and the information contained 
                  herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 
                  THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 
                  EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 
                  THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 
                
                
               Watson              Expires - NovemberOctober 2002            [Page 6] 
               Network Asserted Identity Ż short term requirements           May 2002 
                
                
                  ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 
                  PARTICULAR PURPOSE." 















































                
                
               Watson              Expires - NovemberOctober 2002            [Page 7]