From nobody Mon May 2 12:49:20 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6999012D17C; Mon, 2 May 2016 12:49:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502194916.15826.10556.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 12:49:16 -0700 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-dns-dual-stack-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 19:49:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core of the IETF. Title : Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network Authors : Olle E. Johansson Gonzalo Salgueiro Vijay Gurbani Dale R. Worley Filename : draft-ietf-sipcore-dns-dual-stack-06.txt Pages : 11 Date : 2016-05-02 Abstract: RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying Happy Eyeballs principles to SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-dns-dual-stack-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-dns-dual-stack-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 2 12:50:32 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E1F12B00C for ; Mon, 2 May 2016 12:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZelZocmTNFvo for ; Mon, 2 May 2016 12:50:28 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4691F12D623 for ; Mon, 2 May 2016 12:50:28 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by comcast with SMTP id xJrNamLPQjuYRxJrPavbu0; Mon, 02 May 2016 19:50:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1462218627; bh=Pl6b5n4q7+PsnycqVuTjQD2Qfky1skoVdRvdhTEjDtg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=XjJ7DgbKqgnlLkh6XxKiupv46BaQXBaH6fvAFbp72xducti3eAuedUxTJMeIUB6A5 GAKevT2kkEj7DfLM5tUxL5r0byx6Y82/mlkadukUJBR3B94dXnLzPJc/gIqhxhX/+g EM4EB3rHdT3uakx7V4bBzB+udOSrsKL61iDosZ3qzQmoDlzqVLBKcOiEJ9lF64KJe0 4bmW+7BdHsAE1IvAshtTcptbgHqwWVqP/syB82WWx4jy/jjGlyYbBNCNSQ5Qf+xgdt yKeJ7IX5ArIMR1E/hbNzUIFCi2E2pu3+fgmx7qnHgsmlMh/Y/8vmqtdkjHtVSJRxcm kOLcmq7iKxyng== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-08v.sys.comcast.net with comcast id pXqS1s00M1nMCLR01XqTLR; Mon, 02 May 2016 19:50:27 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u42JoQ6s008870 for ; Mon, 2 May 2016 15:50:26 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u42JoPAF008867; Mon, 2 May 2016 15:50:25 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 02 May 2016 15:50:25 -0400 Message-ID: <87oa8outmm.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] draft-ietf-sipcore-dns-dual-stack-06 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 19:50:29 -0000 I think that draft-ietf-sipcore-dns-dual-stack-06 covers everything that's been raised during the WGLC. Dale From nobody Tue May 3 05:16:26 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B63112D1D3 for ; Tue, 3 May 2016 05:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdD6G5qFriyK for ; Tue, 3 May 2016 05:16:19 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8B912D7B0 for ; Tue, 3 May 2016 05:16:05 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id c189so20364776vkb.3 for ; Tue, 03 May 2016 05:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=VbQmIJgcixJJm5Qe7vVQVNdgJ8lGCA42t/8z6q2dViA=; b=qKrCzMPe27V65u2ZLqfLFHZCn3tU/12wnAYn1uJ4IwrDrCyEeQ5ms1un4uAs1iVM1C PTuq1Dy8pBTFC8q0yBGGVyYISjO6yiBcTKBkqCYpoEJ8yg+dhCDwi0SRCwUqYEfehT9S 210BX53vdh8lYWV+0Ph3LmqrKVj8kU9cwvwKdQVxCj1081vfuoTaphts0l0oBhaUaVaw 13WGAeGczUg9jtixbcoMLtpeKS46ktVjGu+QtcMSMLf5h6d0VF8/0DLdcmop53uHTqFj JOsnDvUGqTcXHA5QIHMhdc0VipdifxdUxqX0XElHuL8844xSQTjkGBNnyyac7pu2cn4i S+gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=VbQmIJgcixJJm5Qe7vVQVNdgJ8lGCA42t/8z6q2dViA=; b=dXJ/KjZFyU79N0W7Csdyf/WbkobRCJUnLHNS3tJft3NqjAVaX6WYNEntyM9veXaqXB M5gsZmdTH7dM9Grf1TXlBZsptvSBoQ5I/ArSKrNXefns029S68a92rJQYe7x75Ghs/h2 yZYIciqx4DCPwbMZfv5NGuTYPE0Cdgh5ve3/megLc5+mLvA02vIdCFxpIIOsha9bwBXb 8reIRQ3s9ikfEPfjcCDhbjeCfNGrFtm5ooMlwkjkgqSPpRQlNP9C+zV2yAMKu2M8YsCu sZsbxgosEobNqBzTkdt3BTFSrfBNxFfR88BUg3o2QvHDiTQq+olHOROZy8wwN5zlCBoE 8hYQ== X-Gm-Message-State: AOPr4FXQFyDM+73bVfBOL8utUePoqkUjYBWoSHLDm18fZVbcsQAPUVdHPDJiHeGStcAHytVRf//sGMr5doELFw== MIME-Version: 1.0 X-Received: by 10.31.149.10 with SMTP id x10mr857774vkd.73.1462277764127; Tue, 03 May 2016 05:16:04 -0700 (PDT) Received: by 10.176.7.101 with HTTP; Tue, 3 May 2016 05:16:04 -0700 (PDT) Date: Tue, 3 May 2016 08:16:04 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=001a11408b14b1a1950531ef12e8 Archived-At: Subject: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 12:16:23 -0000 --001a11408b14b1a1950531ef12e8 Content-Type: text/plain; charset=UTF-8 All, The following is v3 of the problem statement based on the feedback provided. Thoughts? Regards, Rifaat --- Overview -------- The following is a simplified classic SIP deployment model: +--------+ | SIP | ,---------------------------| Registrar | | | +--------+ +--------+ +--------+ | | | SIP | | SIP App| | UA |----------------------| Proxy |----------------------| Server | | | | | | | +--------+ +--------+ +--------+ With this model, the endpoint is assigned a dedicated SIP proxy/registrar and all SIP communications must go through that SIP proxy. The SIP Proxy/Registrar plays 3 different roles: 1. Authentication Server (SIP Registrar) 2. Authorization Server 3. Service provider, e.g. basic calls, call forwarding, call transfer, etc. SIP Application Servers provide advanced SIP services, e.g. conference, presence, etc. Application Servers usually have their own authentication and authorization mechanism that is separate from the one provided by the SIP proxy. We would like to discuss the idea of "outsourcing" the user authentication and services authorization to separate network element(s): Authentication (AuthN) ---------------------- There are two types of authentications in a SIP network: user-to-server authentication and user-to-user authentication. These authentications could be in the context of one trust domain, or it could cross boundaries between different trust domains. We would like to explore the idea of "outsourcing" the user authentication part to a separate IdP entity, to allow the SIP user to use his non-SIP credentials, e.g. corporate credentials, with the IdP to register with the SIP registrar, get basic services from the SIP Proxy, and get access to the advanced services provided by the SIP Application Servers. We would also like to explore the idea of using the same "outsourcing" mechanism to address the user authentication when it crosses trust domain boundaries. IdP Definition: "IdP (Identity Provider), is a system that creates, maintains, and manages identity information for principals (users, services, or systems) and provides principal authentication to other service providers (applications) within a federation or distributed network. It is a trusted third party that can be relied upon by users and servers when users and servers are establishing a dialog that must be authenticated. The IdP sends an attribute assertion containing trusted information about the user to the SP". The above IdP definition is borrowed from the following MIT Knowledge Base site: http://kb.mit.edu/confluence/display/glossary/IdP+(Identity+Provider) Authorization (AuthZ) --------------------- We would like to explore the idea of "outsourcing" the authorization part to a separate network element to allow the administrator to grant access to the basic services provided by the SIP Proxy, and the various advanced services provided by the SIP Application Servers. In general, there are two authorization mechanisms that could be used in this case: 1. Self-contained token, which includes all the authorizations needed for the server providing the service to be able to make a decision to grant or deny the service request, and might include control over the level of service provided to the user. 2. Opaque token, which requires an introspection step, where the server providing the service would reach to the authorization server to get the details of the authorizations provided for that specific token. There are pros and cons to each approach that we need to discuss and make a decision on supporting one of these, or maybe both. Trust Relationships ------------------- An important aspect of this exercise is to properly define the trust relationship between the various network elements that would enable the new desired functionalities. The following is one possible Enterprise deployment model. With this model, a trust relationship must be established between the SIP Proxy, the SIP Application servers, and the IdP. ....................................................... : : : +--------+ Trust Domain : : | IdP | : +--------------:-------| AuthZ |---------------------------+ : | : | | | : | : +--------+ | : | : | | : | : | | : +--------+ : +--------+ +--------+_ : | | : | SIP | | SIP App| | : | UA |---------:-------| Proxy |----------------------| Server | | : | | : | | | | | : +--------+ : +--------+ +--------+ | : : ---------+ : : : ....................................................... The following is one possible Internet deployment model where the SIP App is deployed in the cloud, and the local users get access to the cloud service based on local authNZ. With this model, a trust relationship must be established between the cloud service provider and the customer. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ : : | IdP | : : +-------------| AuthZ | : : | | | : : | +--------+ : : | | : : | | : : +--------+ +--------+ : : +--------+ | | | SIP | : : | SIP App| | UA |--------| Proxy |-----:-----------------:-----| Video | | | | | : : | Conference +--------+ +--------+ : : +--------+ : : The following is one possible Internet deployment model where one SIP App is deployed in the cloud and is used to provide some service which requires access to some resources in a local SIP App. With this model, a trust relationship must be established between the cloud service provider and the customer. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ +--------+ : : | IdP | | SIP App| : : +-------| AuthZ |---| VM | : : | | | | Server | : : | +--------+ +--------+ : : | | | : : | | | : : +--------+ +--------+ : : +--------+ | | | SIP | : : | SIP App| | UA |--------| Proxy |---------:-----------------:-----| Text | | | | | : : | Transcribe +--------+ +--------+ : : +--------+ : : The following is one possible Internet deployment model with two separate trust domains where a user from one trust domain is calling another user in the other trust domain. With this model, no initial trust relationship between the trust domains is needed to allow the call to be established. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ : : +--------+ | IdP | : : | IdP | +-----------| AuthZ | : : | AuthZ |-----------+ | | | : : | | | | +--------+ : : +--------+ | | : : | | : : | +--------+ +--------+ : : +--------+ +--------+ | | | SIP | : : | SIP | | | | UA |------| Proxy |--:-----------------:--| Proxy |------| UA | | | | | : : | | | | +--------+ +--------+ : : +--------+ +--------+ : : Types of Clients ---------------- The solution must take into consideration the various types of SIP clients that might be involved and active in the system, e.g. softclient, hardphones, etc. The solution must also take into consideration the limitation on some of these clients that might impact the way assertions are obtained and handled. For example, the following client limitation would require an interim step to obtain an assertion: 1. UI Limitation: a hardphone with limited UI capability that only allows the user to interact with the phone through the phone's keypad. 2. Security Limitation: a client that is incapable of maintaining the security of the user's credentials or the assertion. In these use cases, we would need a way to get the assertion to the servers that will provide the service without requiring the client to get access to the assertion. --001a11408b14b1a1950531ef12e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

The following is v3 of the problem statem= ent based on the feedback provided.

Tho= ughts?

= Regards,
=C2=A0Rifaat<= /font>

=
---


Overview
--------

T= he following is a simplified classic SIP deployment model:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | SIP= =C2=A0 =C2=A0|
=C2=A0= =C2=A0 ,---------------------------| Registrar
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0= =C2=A0 =C2=A0|
+-----= ---+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+--------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SIP =C2=A0 =C2=A0| =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SIP App|
| =C2=A0 UA =C2=A0 |---= -------------------| Proxy =C2=A0|----------------------| Server |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+--------+ =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----= ---+

=

With this model, the endpoint is assigned a dedic= ated SIP proxy/registrar
and all SIP communications must go through that SIP proxy.
<= div>
The SIP Proxy/Registrar plays 3 different roles:
1. Authentication Server = (SIP Registrar)
2. Aut= horization Server
3. S= ervice provider, e.g. basic calls, call forwarding, call transfer, etc.

SIP Application Servers provide advanced S= IP services, e.g. conference,
presence, etc. Application Servers usually have their own authentic= ation
and authorizatio= n mechanism that is separate from the one provided by the
= SIP proxy.

We would like to discuss the idea of "outsourcing" the u= ser authentication
and= services authorization to separate network element(s):


=
Authentication (A= uthN)
----------------= ------

There are two types of authentic= ations in a SIP network: user-to-server
authentication and user-to-user authentication. These aut= hentications could
be = in the context of one trust domain, or it could cross boundaries between
different trust domains.=

We would like to explore the idea of &= quot;outsourcing" the user authentication
part to a separate IdP entity, to allow the SIP u= ser to use his non-SIP
credentials, e.g. corporate credentials, with the IdP to register with the=
SIP registrar, get ba= sic services from the SIP Proxy, and get access to the
advanced services provided by the SIP Appl= ication Servers.

<= /font>
We would also like to = explore the idea of using the same "outsourcing"
mechanism to address the user authenti= cation when it crosses trust domain
boundaries.


IdP Definition:

=C2=A0 =C2=A0 "IdP (Identity Provider), is a sys= tem that creates, maintains, and
=C2=A0 =C2=A0 manages identity information for principals (users= , services, or
=C2=A0 = =C2=A0 systems) and provides principal authentication to other service
=C2=A0 =C2=A0 providers (a= pplications) within a federation or distributed network.
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0 It is a trusted third part= y that can be relied upon by users and
=C2=A0 =C2=A0 servers when users and servers are establish= ing a dialog that must be
=C2=A0 =C2=A0 authenticated. The IdP sends an attribute assertion conta= ining trusted
=C2=A0 = =C2=A0 information about the user to the SP".

The above IdP definition is borrowed from the following MIT Kno= wledge Base
site:



= Authorization (AuthZ)
= ---------------------
=
We would like to = explore the idea of "outsourcing" the authorization part
to a separate network element = to allow the administrator to grant access to
the basic services provided by the SIP Proxy, and= the various advanced
= services provided by the SIP Application Servers.

In general, there are two authorization mechanisms that could be= used in
this case:

1. Self-contained token, which includes a= ll the authorizations needed for
=C2=A0 =C2=A0the server providing the service to be able to make= a decision to grant
= =C2=A0 =C2=A0or deny the service request, and might include control over th= e level of
=C2=A0 =C2= =A0service provided to the user.

2. Opa= que token, which requires an introspection step, where the server
=C2=A0 =C2=A0providing the serv= ice would reach to the authorization server to get the
=C2=A0 =C2=A0details of the authorizations= provided for that specific token.

Ther= e are pros and cons to each approach that we need to discuss and make a
decision on supporting on= e of these, or maybe both.


<= /div>
Trust Relationships
-------------------

An important aspect of this exercise is to proper= ly define the trust
re= lationship between the various network elements that would enable the new
desired functionalities= .


The following is one possible Enterprise deployment mo= del. With this model,
= a trust=C2=A0relationship=C2=A0must be established between the SIP Proxy, t= he SIP
Application ser= vers, and the IdP.
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0..........................= .............................
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Trust Domain =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 | IdP =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 +--------------:------= -| AuthZ =C2=A0|---------------------------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 +--------+ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0:
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2= =A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+_ =C2=A0 :
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 | SIP =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SIP App| | =C2= =A0:
| =C2=A0 UA =C2= =A0 |---------:-------| Proxy =C2=A0|----------------------| Server | | =C2= =A0:
| =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| | =C2=A0:
+--------+ =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ | =C2=A0:
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 ---------+ =C2=A0:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0............................................= ...........



The following is one possible Internet deployment model where= the SIP App
is deploy= ed in the cloud, and the local users get access to the cloud
service based on local authNZ.

With this model, a trust=C2=A0relationship= =C2=A0must be established between the cloud
service provider and the customer.
<= font face=3D"monospace, monospace">

=C2=A0 =C2=A0 =C2=A0Trust Domain 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: =C2=A0 =C2=A0Internet =C2=A0 =C2=A0 : =C2=A0Trust Domain 2
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 :
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 := =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | IdP =C2=A0 =C2=A0| =C2=A0 =C2=A0 : =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 +-------------| AuthZ =C2=A0| =C2=A0 = =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 : = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
= =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0 : = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 +--= ------+
| =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| SIP =C2=A0 =C2=A0| =C2=A0 = =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 = =C2=A0 | SIP App|
| = =C2=A0 UA =C2=A0 |--------| Proxy =C2=A0|-----:-----------------:-----| Vid= eo =C2=A0|
| =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : =C2=A0 =C2=A0 | Conference
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0 := =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 +-= -------+
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 :


<= font face=3D"monospace, monospace">

The following is one possible Internet deployment model where one SIP App<= /font>
is deployed in the clo= ud and is used to provide some service which
requires access to some resources in a local SIP App= .

With this model, a trust=C2=A0relatio= nship=C2=A0must be established between the cloud
service provider and the customer.
<= div>

=C2=A0 =C2=A0 =C2=A0Trust Domain 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0Internet =C2=A0 =C2=A0 : =C2=A0T= rust Domain 2
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 = +--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = :
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 | IdP =C2=A0 =C2=A0| =C2=A0 | SIP App| =C2=A0: =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 +-------| AuthZ =C2=A0|---| VM = =C2=A0 =C2=A0 | =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 :
=C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 | Server | = =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 +--------+ =C2=A0 +--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 = =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : =C2=A0 =C2=A0 +--------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| SIP = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 | SIP App|
| =C2=A0 UA =C2=A0 |--------| Proxy =C2=A0= |---------:-----------------:-----| Text =C2=A0 |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 | T= ranscribe
+--------+ = =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 +--------+=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 :



The following is one possible Internet deployment= model with two separate
trust domains where a user from one trust domain is calling another user= in
the other trust do= main.

With this model, no initial trust= relationship between the trust domains is
needed to allow the call to be established.


=C2=A0 =C2=A0 =C2=A0Trust Domain 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = =C2=A0 =C2=A0Internet =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tru= st Domain 2
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0+--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | IdP =C2=A0 =C2=A0| =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0| IdP =C2=A0 =C2=A0|
=C2=A0 =C2=A0 +-----------| AuthZ =C2=A0| = =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0| A= uthZ =C2=A0|-----------+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = |
=C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+--------+ =C2=A0 =C2=A0 =C2=A0+= --------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0+--------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0| SIP =C2=A0 =C2=A0| =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : =C2=A0| SIP =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
| = =C2=A0 UA =C2=A0 |------| Proxy =C2=A0|--:-----------------:--| Proxy =C2= =A0|------| =C2=A0 UA =C2=A0 |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0= =C2=A0 =C2=A0| =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
= +--------+ =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0+---= -----+
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :


Types of Clients
----------------

The solution= must take into consideration the various types of SIP clients
=
that might be involved and active = in the system, e.g. softclient,
hardphones, etc.

The solution= must also take into consideration the limitation on some of
these clients that might impact the = way assertions are obtained and
handled. For example, the following client limitation would requi= re an
interim step to = obtain an assertion:
<= br>
1. UI Limitation: = a hardphone with limited UI capability that only allows
=C2=A0 =C2=A0the user to interact with th= e phone through the phone's keypad.

2. Security Limitation: a client that is incapable of maintaining the
=C2=A0 =C2=A0security of t= he user's credentials or the assertion.

In these use cases, we would need a way to get the assertion to the se= rvers
that will provid= e the service without requiring the client to get access to
the assertion.

--001a11408b14b1a1950531ef12e8-- From nobody Sun May 8 06:25:16 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C460B12B02B for ; Sun, 8 May 2016 06:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0PnyXs-iTA3 for ; Sun, 8 May 2016 06:25:12 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2190412D09A for ; Sun, 8 May 2016 06:25:11 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id m188so39119691vka.1 for ; Sun, 08 May 2016 06:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=6uU/qdtl7yuS246Ja1qIB7xf7sLtzJPS9u4DI9socF0=; b=Idz31I1Zmd5BUURp7NhPUrxxikyHjqcEA77gBOw/tSoLfpN1flwPeWWz82EaXml7GN A8CJU/7twCydhd3KWtuEMcmO0ZSyqlruDc7vDvMnwHOKoeosyQHpLiqUjUQVSd3tZohn BJuZfXghrxjAzaj7Q+ksqUlZWJE9ywfRT7s0Ii2gVj4DBXsKp/HSewNcTyfV1ZcGyiXP YBhc1nojrrJFaH9aecT4hN6iF84Z5j7O5NzeKidUrjNphq0WcnAHSU8H66cxceNYfWpV GGrLnwuQG3ftEKxiAEM913DbrRwFD1nOQHM3fVjnB75T6ehtShxC2qp4WvNPyfF7P3Xo YdNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=6uU/qdtl7yuS246Ja1qIB7xf7sLtzJPS9u4DI9socF0=; b=IYfclp4bsNsJs2Q8roqlOJhK4PASubNgY01tMVqm95HVX5TgsLiaPeP3yWIfBAEvi4 YzDOU94rOaQcc7riUbTu9mMHwlj6bQ+Re8qA5DqWQsa+rlWdQaoeWI+JThGHVGk+ElGC s3pSNYYEGUx3cG+pBrkn19ytrvpv1a9onhDk3935pcN0j+MxJB0wJSZXFinEAd8KjdnZ T9OFDOH0pD8/zATBoWjr20zT9gilgAR2BdEnY5AsaBhKSnSNTsrIJAkUdURpgMRF+HHD 1IiEBjPw3OPgcpQWxDtPh6bz6eHMNzrmxWu5MW8PC53e4sXjQofZ55yemqlbZf09/kOL pXSg== X-Gm-Message-State: AOPr4FUNuuY4lZfV3wFuT0yAZhJRBhr90O30a9c4o+9Oev47vcX6QkAzNtE6rg/wsHJ/hPKjwcndZBycq8QPBA== MIME-Version: 1.0 X-Received: by 10.176.1.240 with SMTP id 103mr17916405ual.46.1462713910144; Sun, 08 May 2016 06:25:10 -0700 (PDT) Received: by 10.176.7.101 with HTTP; Sun, 8 May 2016 06:25:10 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 May 2016 09:25:10 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=001a113cfa5005b7cb0532549fbf Archived-At: Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 13:25:15 -0000 --001a113cfa5005b7cb0532549fbf Content-Type: text/plain; charset=UTF-8 All, I did not receive any comment about this version of the text; does this mean that people are happy with the current text? Also, I have a question that I would like to get people's thoughts about it: The current text assumes that the AuthN and the AuthZ functions co-reside in one network element; should we consider the case that these functions reside in separate network elements? Regards, Rifaat On Tue, May 3, 2016 at 8:16 AM, Rifaat Shekh-Yusef wrote: > All, > > The following is v3 of the problem statement based on the feedback > provided. > > Thoughts? > > Regards, > Rifaat > > > --- > > > Overview > -------- > > The following is a simplified classic SIP deployment model: > > > +--------+ > | SIP | > ,---------------------------| Registrar > | | | > +--------+ +--------+ +--------+ > | | | SIP | | SIP App| > | UA |----------------------| Proxy |----------------------| Server | > | | | | | | > +--------+ +--------+ +--------+ > > > With this model, the endpoint is assigned a dedicated SIP proxy/registrar > and all SIP communications must go through that SIP proxy. > > The SIP Proxy/Registrar plays 3 different roles: > 1. Authentication Server (SIP Registrar) > 2. Authorization Server > 3. Service provider, e.g. basic calls, call forwarding, call transfer, etc. > > SIP Application Servers provide advanced SIP services, e.g. conference, > presence, etc. Application Servers usually have their own authentication > and authorization mechanism that is separate from the one provided by the > SIP proxy. > > We would like to discuss the idea of "outsourcing" the user authentication > and services authorization to separate network element(s): > > > > Authentication (AuthN) > ---------------------- > > There are two types of authentications in a SIP network: user-to-server > authentication and user-to-user authentication. These authentications could > be in the context of one trust domain, or it could cross boundaries between > different trust domains. > > We would like to explore the idea of "outsourcing" the user authentication > part to a separate IdP entity, to allow the SIP user to use his non-SIP > credentials, e.g. corporate credentials, with the IdP to register with the > SIP registrar, get basic services from the SIP Proxy, and get access to the > advanced services provided by the SIP Application Servers. > > We would also like to explore the idea of using the same "outsourcing" > mechanism to address the user authentication when it crosses trust domain > boundaries. > > > IdP Definition: > > "IdP (Identity Provider), is a system that creates, maintains, and > manages identity information for principals (users, services, or > systems) and provides principal authentication to other service > providers (applications) within a federation or distributed network. > It is a trusted third party that can be relied upon by users and > servers when users and servers are establishing a dialog that must be > authenticated. The IdP sends an attribute assertion containing trusted > information about the user to the SP". > > The above IdP definition is borrowed from the following MIT Knowledge Base > site: > http://kb.mit.edu/confluence/display/glossary/IdP+(Identity+Provider) > > > > Authorization (AuthZ) > --------------------- > > We would like to explore the idea of "outsourcing" the authorization part > to a separate network element to allow the administrator to grant access to > the basic services provided by the SIP Proxy, and the various advanced > services provided by the SIP Application Servers. > > In general, there are two authorization mechanisms that could be used in > this case: > > 1. Self-contained token, which includes all the authorizations needed for > the server providing the service to be able to make a decision to grant > or deny the service request, and might include control over the level of > service provided to the user. > > 2. Opaque token, which requires an introspection step, where the server > providing the service would reach to the authorization server to get the > details of the authorizations provided for that specific token. > > There are pros and cons to each approach that we need to discuss and make a > decision on supporting one of these, or maybe both. > > > Trust Relationships > ------------------- > > An important aspect of this exercise is to properly define the trust > relationship between the various network elements that would enable the new > desired functionalities. > > > The following is one possible Enterprise deployment model. With this model, > a trust relationship must be established between the SIP Proxy, the SIP > Application servers, and the IdP. > > ....................................................... > : : > : +--------+ Trust Domain : > : | IdP | : > +--------------:-------| AuthZ |---------------------------+ : > | : | | | : > | : +--------+ | : > | : | | : > | : | | : > +--------+ : +--------+ +--------+_ : > | | : | SIP | | SIP App| | : > | UA |---------:-------| Proxy |----------------------| Server | | : > | | : | | | | | : > +--------+ : +--------+ +--------+ | : > : ---------+ : > : : > ....................................................... > > > > The following is one possible Internet deployment model where the SIP App > is deployed in the cloud, and the local users get access to the cloud > service based on local authNZ. > > With this model, a trust relationship must be established between the cloud > service provider and the customer. > > > Trust Domain 1 : Internet : Trust Domain 2 > : : > +--------+ : : > | IdP | : : > +-------------| AuthZ | : : > | | | : : > | +--------+ : : > | | : : > | | : : > +--------+ +--------+ : : +--------+ > | | | SIP | : : | SIP App| > | UA |--------| Proxy |-----:-----------------:-----| Video | > | | | | : : | Conference > +--------+ +--------+ : : +--------+ > : : > > > > > The following is one possible Internet deployment model where one SIP App > is deployed in the cloud and is used to provide some service which > requires access to some resources in a local SIP App. > > With this model, a trust relationship must be established between the cloud > service provider and the customer. > > > Trust Domain 1 : Internet : Trust Domain 2 > : : > +--------+ +--------+ : : > | IdP | | SIP App| : : > +-------| AuthZ |---| VM | : : > | | | | Server | : : > | +--------+ +--------+ : : > | | | : : > | | | : : > +--------+ +--------+ : : +--------+ > | | | SIP | : : | SIP App| > | UA |--------| Proxy |---------:-----------------:-----| Text | > | | | | : : | Transcribe > +--------+ +--------+ : : +--------+ > : : > > > > The following is one possible Internet deployment model with two separate > trust domains where a user from one trust domain is calling another user in > the other trust domain. > > With this model, no initial trust relationship between the trust domains is > needed to allow the call to be established. > > > Trust Domain 1 : Internet : Trust Domain 2 > : : > +--------+ : : +--------+ > | IdP | : : | IdP | > +-----------| AuthZ | : : | AuthZ |-----------+ > | | | : : | | | > | +--------+ : : +--------+ | > | : : | > | : : | > +--------+ +--------+ : : +--------+ +--------+ > | | | SIP | : : | SIP | | | > | UA |------| Proxy |--:-----------------:--| Proxy |------| UA | > | | | | : : | | | | > +--------+ +--------+ : : +--------+ +--------+ > : : > > > Types of Clients > ---------------- > > The solution must take into consideration the various types of SIP clients > that might be involved and active in the system, e.g. softclient, > hardphones, etc. > > The solution must also take into consideration the limitation on some of > these clients that might impact the way assertions are obtained and > handled. For example, the following client limitation would require an > interim step to obtain an assertion: > > 1. UI Limitation: a hardphone with limited UI capability that only allows > the user to interact with the phone through the phone's keypad. > > 2. Security Limitation: a client that is incapable of maintaining the > security of the user's credentials or the assertion. > > In these use cases, we would need a way to get the assertion to the servers > that will provide the service without requiring the client to get access to > the assertion. > > --001a113cfa5005b7cb0532549fbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

I did not receive any commen= t about this version of the text; does this mean that people are happy with= the current text?

Also, I have a question that I would = like to get people's thoughts about it:
The current text assu= mes that the AuthN and the AuthZ functions co-reside in one network element= ; should we consider the case that these functions reside in separate netwo= rk elements?

Regards,
=C2=A0Rifaat


On Tue, May 3, 2016 at 8:16 AM, Rifaat Shekh-Yusef <rifaat.iet= f@gmail.com> wrote:
All,

The following is v3 of the problem statement bas= ed on the feedback provided.

Thoughts?<= /font>

Regards= ,
=C2=A0Rifaat<= /div>


---


<= font face=3D"monospace, monospace">Overview
--------

The foll= owing is a simplified classic SIP deployment model:


=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | SIP =C2=A0= =C2=A0|
=C2=A0 =C2=A0= ,---------------------------| Registrar
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0= =C2=A0|
+--------+ = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+--------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SIP =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SIP App|
| =C2=A0 UA =C2=A0 |----= ------------------| Proxy =C2=A0|----------------------| Server |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+--------+ =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----= ---+

=

With this model, the endpoint is assigned a dedic= ated SIP proxy/registrar
and all SIP communications must go through that SIP proxy.
<= div>
The SIP Proxy/Registrar plays 3 different roles:
1. Authentication Server = (SIP Registrar)
2. Aut= horization Server
3. S= ervice provider, e.g. basic calls, call forwarding, call transfer, etc.

SIP Application Servers provide advanced S= IP services, e.g. conference,
presence, etc. Application Servers usually have their own authentic= ation
and authorizatio= n mechanism that is separate from the one provided by the
= SIP proxy.

We would like to discuss the idea of "outsourcing" the u= ser authentication
and= services authorization to separate network element(s):


=
Authentication (A= uthN)
----------------= ------

There are two types of authentic= ations in a SIP network: user-to-server
authentication and user-to-user authentication. These aut= hentications could
be = in the context of one trust domain, or it could cross boundaries between
different trust domains.=

We would like to explore the idea of &= quot;outsourcing" the user authentication
part to a separate IdP entity, to allow the SIP u= ser to use his non-SIP
credentials, e.g. corporate credentials, with the IdP to register with the=
SIP registrar, get ba= sic services from the SIP Proxy, and get access to the
advanced services provided by the SIP Appl= ication Servers.

<= /font>
We would also like to = explore the idea of using the same "outsourcing"
mechanism to address the user authenti= cation when it crosses trust domain
boundaries.


IdP Definition:

=C2=A0 =C2=A0 "IdP (Identity Provider), is a sys= tem that creates, maintains, and
=C2=A0 =C2=A0 manages identity information for principals (users= , services, or
=C2=A0 = =C2=A0 systems) and provides principal authentication to other service
=C2=A0 =C2=A0 providers (a= pplications) within a federation or distributed network.
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0 It is a trusted third part= y that can be relied upon by users and
=C2=A0 =C2=A0 servers when users and servers are establish= ing a dialog that must be
=C2=A0 =C2=A0 authenticated. The IdP sends an attribute assertion conta= ining trusted
=C2=A0 = =C2=A0 information about the user to the SP".

The above IdP definition is borrowed from the following MIT Kno= wledge Base
site:



= Authorization (AuthZ)
= ---------------------
=
We would like to = explore the idea of "outsourcing" the authorization part
to a separate network element = to allow the administrator to grant access to
the basic services provided by the SIP Proxy, and= the various advanced
= services provided by the SIP Application Servers.

In general, there are two authorization mechanisms that could be= used in
this case:

1. Self-contained token, which includes a= ll the authorizations needed for
=C2=A0 =C2=A0the server providing the service to be able to make= a decision to grant
= =C2=A0 =C2=A0or deny the service request, and might include control over th= e level of
=C2=A0 =C2= =A0service provided to the user.

2. Opa= que token, which requires an introspection step, where the server
=C2=A0 =C2=A0providing the serv= ice would reach to the authorization server to get the
=C2=A0 =C2=A0details of the authorizations= provided for that specific token.

Ther= e are pros and cons to each approach that we need to discuss and make a
decision on supporting on= e of these, or maybe both.


<= /div>
Trust Relationships
-------------------

An important aspect of this exercise is to proper= ly define the trust
re= lationship between the various network elements that would enable the new
desired functionalities= .


The following is one possible Enterprise deployment mo= del. With this model,
= a trust=C2=A0relationship=C2=A0must be established between the SIP Proxy, t= he SIP
Application ser= vers, and the IdP.
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0..........................= .............................
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Trust Domain =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 | IdP =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 +--------------:------= -| AuthZ =C2=A0|---------------------------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 +--------+ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0:
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2= =A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+_ =C2=A0 :
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 | SIP =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SIP App| | =C2= =A0:
| =C2=A0 UA =C2= =A0 |---------:-------| Proxy =C2=A0|----------------------| Server | | =C2= =A0:
| =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| | =C2=A0:
+--------+ =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ | =C2=A0:
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 ---------+ =C2=A0:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0............................................= ...........



The following is one possible Internet deployment model where= the SIP App
is deploy= ed in the cloud, and the local users get access to the cloud
service based on local authNZ.

With this model, a trust=C2=A0relationship= =C2=A0must be established between the cloud
service provider and the customer.
<= font face=3D"monospace, monospace">

=C2=A0 =C2=A0 =C2=A0Trust Domain 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: =C2=A0 =C2=A0Internet =C2=A0 =C2=A0 : =C2=A0Trust Domain 2
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 :
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 := =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | IdP =C2=A0 =C2=A0| =C2=A0 =C2=A0 : =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 +-------------| AuthZ =C2=A0| =C2=A0 = =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 : = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
= =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0 : = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 +--= ------+
| =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| SIP =C2=A0 =C2=A0| =C2=A0 = =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 = =C2=A0 | SIP App|
| = =C2=A0 UA =C2=A0 |--------| Proxy =C2=A0|-----:-----------------:-----| Vid= eo =C2=A0|
| =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : =C2=A0 =C2=A0 | Conference
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0 := =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 +-= -------+
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 :


<= font face=3D"monospace, monospace">

The following is one possible Internet deployment model where one SIP App<= /font>
is deployed in the clo= ud and is used to provide some service which
requires access to some resources in a local SIP App= .

With this model, a trust=C2=A0relatio= nship=C2=A0must be established between the cloud
service provider and the customer.
<= div>

=C2=A0 =C2=A0 =C2=A0Trust Domain 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0Internet =C2=A0 =C2=A0 : =C2=A0T= rust Domain 2
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 = +--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = :
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 | IdP =C2=A0 =C2=A0| =C2=A0 | SIP App| =C2=A0: =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 +-------| AuthZ =C2=A0|---| VM = =C2=A0 =C2=A0 | =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 :
=C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 | Server | = =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 +--------+ =C2=A0 +--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 = =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : =C2=A0 =C2=A0 +--------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| SIP = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 | SIP App|
| =C2=A0 UA =C2=A0 |--------| Proxy =C2=A0= |---------:-----------------:-----| Text =C2=A0 |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 | T= ranscribe
+--------+ = =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 +--------+=
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 :



The following is one possible Internet deployment= model with two separate
trust domains where a user from one trust domain is calling another user= in
the other trust do= main.

With this model, no initial trust= relationship between the trust domains is
needed to allow the call to be established.


=C2=A0 =C2=A0 =C2=A0Trust Domain 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = =C2=A0 =C2=A0Internet =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tru= st Domain 2
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0+--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | IdP =C2=A0 =C2=A0| =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0| IdP =C2=A0 =C2=A0|
=C2=A0 =C2=A0 +-----------| AuthZ =C2=A0| = =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0| A= uthZ =C2=A0|-----------+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = |
=C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+--------+ =C2=A0 =C2=A0 =C2=A0+= --------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0+--------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0| SIP =C2=A0 =C2=A0| =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : =C2=A0| SIP =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
| = =C2=A0 UA =C2=A0 |------| Proxy =C2=A0|--:-----------------:--| Proxy =C2= =A0|------| =C2=A0 UA =C2=A0 |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0= =C2=A0 =C2=A0| =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
= +--------+ =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0+---= -----+
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :


Types of Clients
----------------

The solution= must take into consideration the various types of SIP clients
=
that might be involved and active = in the system, e.g. softclient,
hardphones, etc.

The solution= must also take into consideration the limitation on some of
these clients that might impact the = way assertions are obtained and
handled. For example, the following client limitation would requi= re an
interim step to = obtain an assertion:
<= br>
1. UI Limitation: = a hardphone with limited UI capability that only allows
=C2=A0 =C2=A0the user to interact with th= e phone through the phone's keypad.

2. Security Limitation: a client that is incapable of maintaining the
=C2=A0 =C2=A0security of t= he user's credentials or the assertion.

In these use cases, we would need a way to get the assertion to the se= rvers
that will provid= e the service without requiring the client to get access to
the assertion.


--001a113cfa5005b7cb0532549fbf-- From nobody Sun May 8 08:27:11 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26FD12D102 for ; Sun, 8 May 2016 08:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmRofH-054yT for ; Sun, 8 May 2016 08:27:06 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB2212B056 for ; Sun, 8 May 2016 08:27:04 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-07-572f5ac6bfd1 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BA.40.12516.6CA5F275; Sun, 8 May 2016 17:27:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Sun, 8 May 2016 17:27:02 +0200 From: Christer Holmberg To: Rifaat Shekh-Yusef , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0SdPYK36JzskyA13ZRS/LYCZ+vKcgT Date: Sun, 8 May 2016 15:27:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F97548ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbHdQPd4lH64weu5zBY7X7SyWXz9sYnN gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mr417qXseDiZ6aKedvnsDcwvl/D1MXIySEh YCJx/tYEFghbTOLCvfVsXYxcHEICRxgl7ne1sEA4ixklPlzczd7FyMHBJmAh0f1PG6RBRCBc Ysfui6wgtjBQ+PDN/8wQcUuJ75POsUPYRhKLGueD1bAIqEjMftEIFucV8JXo/HqCEWL+VEaJ I1MWgl3BKRAo8eLeWjYQmxHoou+nIC5lFhCXaPqykhXiUgGJJXvOM0PYohIvH/9jBbmNWSBf 4vGtaoj5ghInZz5hmcAoPAtJ9yyEqllIqiBKDCS+vL8NZWtLLFv4mhnC1pfofn+aCVl8ASP7 KkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzACDq45bfuDsbVrx0PMQpwMCrx8D64qhcuxJpY VlyZe4hRgoNZSYS31Fw/XIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILU IpgsEwenVAPjvPS6xcd1dtpP5k3ytpTI9vnocUQh4O3P87d9C9ttbjypWzCL/flqiUvzvjCn HVkdtu9H49ymuT9iyvI7dzxt7UnlfjinMXnW1d8l3n+yr3Syf+t30G54vjLce45a+4aln+b/ eKf38/lOnYuBGa5LDsc8PTrvou8G+bUnXuupbM6ZvN+VLfTcKSWW4oxEQy3mouJEAN4pTAWc AgAA Archived-At: Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 15:27:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F97548ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, >From my experience, it's always better to define FUNCTIONS and the relation= ship requirements (trust etc) between them. It is then an implementation is= sue whether they are located in the physical node. Of course, IF there is a reason why two functions must be located in the ph= ysical node we should say so, but typically that's not the case. Regards, Christer Sent from my Windows Phone ________________________________ From: Rifaat Shekh-Yusef Sent: =FD08/=FD05/=FD2016 16:25 To: sipcore@ietf.org Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 All, I did not receive any comment about this version of the text; does this mea= n that people are happy with the current text? Also, I have a question that I would like to get people's thoughts about it= : The current text assumes that the AuthN and the AuthZ functions co-reside i= n one network element; should we consider the case that these functions res= ide in separate network elements? Regards, Rifaat On Tue, May 3, 2016 at 8:16 AM, Rifaat Shekh-Yusef > wrote: All, The following is v3 of the problem statement based on the feedback provided= . Thoughts? Regards, Rifaat --- Overview -------- The following is a simplified classic SIP deployment model: +--------+ | SIP | ,---------------------------| Registrar | | | +--------+ +--------+ +--------+ | | | SIP | | SIP App| | UA |----------------------| Proxy |----------------------| Server | | | | | | | +--------+ +--------+ +--------+ With this model, the endpoint is assigned a dedicated SIP proxy/registrar and all SIP communications must go through that SIP proxy. The SIP Proxy/Registrar plays 3 different roles: 1. Authentication Server (SIP Registrar) 2. Authorization Server 3. Service provider, e.g. basic calls, call forwarding, call transfer, etc. SIP Application Servers provide advanced SIP services, e.g. conference, presence, etc. Application Servers usually have their own authentication and authorization mechanism that is separate from the one provided by the SIP proxy. We would like to discuss the idea of "outsourcing" the user authentication and services authorization to separate network element(s): Authentication (AuthN) ---------------------- There are two types of authentications in a SIP network: user-to-server authentication and user-to-user authentication. These authentications could be in the context of one trust domain, or it could cross boundaries between different trust domains. We would like to explore the idea of "outsourcing" the user authentication part to a separate IdP entity, to allow the SIP user to use his non-SIP credentials, e.g. corporate credentials, with the IdP to register with the SIP registrar, get basic services from the SIP Proxy, and get access to the advanced services provided by the SIP Application Servers. We would also like to explore the idea of using the same "outsourcing" mechanism to address the user authentication when it crosses trust domain boundaries. IdP Definition: "IdP (Identity Provider), is a system that creates, maintains, and manages identity information for principals (users, services, or systems) and provides principal authentication to other service providers (applications) within a federation or distributed network. It is a trusted third party that can be relied upon by users and servers when users and servers are establishing a dialog that must be authenticated. The IdP sends an attribute assertion containing trusted information about the user to the SP". The above IdP definition is borrowed from the following MIT Knowledge Base site: http://kb.mit.edu/confluence/display/glossary/IdP+(Identity+Provider) Authorization (AuthZ) --------------------- We would like to explore the idea of "outsourcing" the authorization part to a separate network element to allow the administrator to grant access to the basic services provided by the SIP Proxy, and the various advanced services provided by the SIP Application Servers. In general, there are two authorization mechanisms that could be used in this case: 1. Self-contained token, which includes all the authorizations needed for the server providing the service to be able to make a decision to grant or deny the service request, and might include control over the level of service provided to the user. 2. Opaque token, which requires an introspection step, where the server providing the service would reach to the authorization server to get the details of the authorizations provided for that specific token. There are pros and cons to each approach that we need to discuss and make a decision on supporting one of these, or maybe both. Trust Relationships ------------------- An important aspect of this exercise is to properly define the trust relationship between the various network elements that would enable the new desired functionalities. The following is one possible Enterprise deployment model. With this model, a trust relationship must be established between the SIP Proxy, the SIP Application servers, and the IdP. ....................................................... : : : +--------+ Trust Domain : : | IdP | : +--------------:-------| AuthZ |---------------------------+ : | : | | | : | : +--------+ | : | : | | : | : | | : +--------+ : +--------+ +--------+_ : | | : | SIP | | SIP App| | : | UA |---------:-------| Proxy |----------------------| Server | | : | | : | | | | | : +--------+ : +--------+ +--------+ | : : ---------+ : : : ....................................................... The following is one possible Internet deployment model where the SIP App is deployed in the cloud, and the local users get access to the cloud service based on local authNZ. With this model, a trust relationship must be established between the cloud service provider and the customer. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ : : | IdP | : : +-------------| AuthZ | : : | | | : : | +--------+ : : | | : : | | : : +--------+ +--------+ : : +--------+ | | | SIP | : : | SIP App| | UA |--------| Proxy |-----:-----------------:-----| Video | | | | | : : | Conference +--------+ +--------+ : : +--------+ : : The following is one possible Internet deployment model where one SIP App is deployed in the cloud and is used to provide some service which requires access to some resources in a local SIP App. With this model, a trust relationship must be established between the cloud service provider and the customer. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ +--------+ : : | IdP | | SIP App| : : +-------| AuthZ |---| VM | : : | | | | Server | : : | +--------+ +--------+ : : | | | : : | | | : : +--------+ +--------+ : : +--------+ | | | SIP | : : | SIP App| | UA |--------| Proxy |---------:-----------------:-----| Text | | | | | : : | Transcribe +--------+ +--------+ : : +--------+ : : The following is one possible Internet deployment model with two separate trust domains where a user from one trust domain is calling another user in the other trust domain. With this model, no initial trust relationship between the trust domains is needed to allow the call to be established. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ : : +--------+ | IdP | : : | IdP | +-----------| AuthZ | : : | AuthZ |-----------+ | | | : : | | | | +--------+ : : +--------+ | | : : | | : : | +--------+ +--------+ : : +--------+ +--------+ | | | SIP | : : | SIP | | | | UA |------| Proxy |--:-----------------:--| Proxy |------| UA | | | | | : : | | | | +--------+ +--------+ : : +--------+ +--------+ : : Types of Clients ---------------- The solution must take into consideration the various types of SIP clients that might be involved and active in the system, e.g. softclient, hardphones, etc. The solution must also take into consideration the limitation on some of these clients that might impact the way assertions are obtained and handled. For example, the following client limitation would require an interim step to obtain an assertion: 1. UI Limitation: a hardphone with limited UI capability that only allows the user to interact with the phone through the phone's keypad. 2. Security Limitation: a client that is incapable of maintaining the security of the user's credentials or the assertion. In these use cases, we would need a way to get the assertion to the servers that will provide the service without requiring the client to get access to the assertion. --_000_7594FB04B1934943A5C02806D1A2204B37F97548ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

>From my experience, it's always better to define FUNCTIONS and the relation= ship requirements (trust etc) between them. It is then an implementation is= sue whether they are located in the physical node.

Of course, IF there is a reason why two functions must be located in the ph= ysical node we should say so, but typically that's not the case.

Regards,

Christer

Sent from my Windows Phone
From: Rifaat Shekh-Yusef
Sent: =FD08= /=FD05/=FD2016 16:25
To: sipcore@ietf.org
Subject: Re: [= sipcore] SIP AuthNZ Problem Statement - v3

All,

I did not receive any comment about this version of the text; does this mea= n that people are happy with the current text?

Also, I have a question that I would like to get people's thoughts abo= ut it:
The current text assumes that the AuthN and the AuthZ functions co-res= ide in one network element; should we consider the case that these function= s reside in separate network elements?

Regards,
 Rifaat


On Tue, May 3, 2016 at 8:16 AM, Rifaat Shekh-Yus= ef <rifaat.ietf@= gmail.com> wrote:
All,

The following is v3 of the problem= statement based on the feedback provided.

Thoughts?

Regards,
 Rifaat


---


Overview
--------

The following is a simplified clas= sic SIP deployment model:


         =                     &nbs= p; +--------+
         =                     &nbs= p; | SIP    |
    ,-------------------= --------| Registrar
    |     &nbs= p;                     | =        |
+--------+     &= nbsp;                +--------&= #43;                     =  +--------+
|        | &nb= sp;                    | = SIP    |                 =      | SIP App|
|   UA   |--------------= --------| Proxy  |----------------------| Server |
|        | &nb= sp;                    | =        |             &nbs= p;        |        |
+--------+     &= nbsp;                +--------&= #43;                     =  +--------+


With this model, the endpoint is a= ssigned a dedicated SIP proxy/registrar
and all SIP communications must go= through that SIP proxy.

The SIP Proxy/Registrar plays 3 di= fferent roles:
1. Authentication Server (SIP Regi= strar)
2. Authorization Server
3. Service provider, e.g. basic ca= lls, call forwarding, call transfer, etc.

SIP Application Servers provide ad= vanced SIP services, e.g. conference,
presence, etc. Application Servers= usually have their own authentication
and authorization mechanism that i= s separate from the one provided by the
SIP proxy.

We would like to discuss the idea = of "outsourcing" the user authentication
and services authorization to sepa= rate network element(s):



Authentication (AuthN)
----------------------

There are two types of authenticat= ions in a SIP network: user-to-server
authentication and user-to-user au= thentication. These authentications could
be in the context of one trust dom= ain, or it could cross boundaries between
different trust domains.

We would like to explore the idea = of "outsourcing" the user authentication
part to a separate IdP entity, to = allow the SIP user to use his non-SIP
credentials, e.g. corporate creden= tials, with the IdP to register with the
SIP registrar, get basic services = from the SIP Proxy, and get access to the
advanced services provided by the = SIP Application Servers.

We would also like to explore the = idea of using the same "outsourcing"
mechanism to address the user auth= entication when it crosses trust domain
boundaries.


IdP Definition:

    "IdP (Identity = Provider), is a system that creates, maintains, and
    manages identity inf= ormation for principals (users, services, or
    systems) and provide= s principal authentication to other service
    providers (applicati= ons) within a federation or distributed network.
    It is a trusted thir= d party that can be relied upon by users and
    servers when users a= nd servers are establishing a dialog that must be
    authenticated. The I= dP sends an attribute assertion containing trusted
    information about th= e user to the SP".

The above IdP definition is borrow= ed from the following MIT Knowledge Base
site:



Authorization (AuthZ)
---------------------

We would like to explore the idea = of "outsourcing" the authorization part
to a separate network element to a= llow the administrator to grant access to
the basic services provided by the= SIP Proxy, and the various advanced
services provided by the SIP Appli= cation Servers.

In general, there are two authoriz= ation mechanisms that could be used in
this case:

1. Self-contained token, which inc= ludes all the authorizations needed for
   the server providing = the service to be able to make a decision to grant
   or deny the service r= equest, and might include control over the level of
   service provided to t= he user.

2. Opaque token, which requires an= introspection step, where the server
   providing the service= would reach to the authorization server to get the
   details of the author= izations provided for that specific token.

There are pros and cons to each ap= proach that we need to discuss and make a
decision on supporting one of thes= e, or maybe both.


Trust Relationships
-------------------

An important aspect of this exerci= se is to properly define the trust
relationship between the various n= etwork elements that would enable the new
desired functionalities.


The following is one possible Ente= rprise deployment model. With this model,
a trust relationship mus= t be established between the SIP Proxy, the SIP
Application servers, and the IdP.<= /font>

         =          ........................................= ...............
         =          :           &nb= sp;                     &= nbsp;                   :
         =          :       +--------+= ;           Trust Domain       &nbs= p;     :
         =          :       | IdP   &nbs= p;|                     &= nbsp;              :
    +--------------:= -------| AuthZ  |---------------------------+      =  :
    |     &nbs= p;        :       |      =  |                   &nb= sp;       |        :
    |     &nbs= p;        :       +--------+ &nb= sp;                     &= nbsp;   |        :
    |     &nbs= p;        :           |  =                     &nbs= p;        |        :
    |     &nbs= p;        :           |  =                     &nbs= p;        |        :
+--------+     &= nbsp;   :       +--------+      =                +--------+_=   :
|        | &nb= sp;       :       | SIP    |  =                    | SIP= App| |  :
|   UA   |---------:----= ---| Proxy  |----------------------| Server | |  :
|        | &nb= sp;       :       |       &nbs= p;|                     &= nbsp;|        | |  :
+--------+     &= nbsp;   :       +--------+      =                +--------+ = |  :
         =          :           &nb= sp;                     &= nbsp;       ---------+  :
         =          :           &nb= sp;                     &= nbsp;                   :
         =          ........................................= ...............



The following is one possible Inte= rnet deployment model where the SIP App
is deployed in the cloud, and the = local users get access to the cloud
service based on local authNZ.

With this model, a trust rela= tionship must be established between the cloud
service provider and the customer.=


     Trust Domain 1=              :    Internet &n= bsp;   :  Trust Domain 2
         =                     &nbs= p;  :                 :=
         =         +--------+     :   &nbs= p;             :
         =         | IdP    |     :   &n= bsp;             :
    +-------------| = AuthZ  |     :             &nb= sp;   :
    |     &nbs= p;       |        |     : &nbs= p;               :
    |     &nbs= p;       +--------+     :     &n= bsp;           :
    |     &nbs= p;           |          :=                 :
    |     &nbs= p;           |          :=                 :
+--------+     &= nbsp;  +--------+     :         =         :     +--------+
|        | &nb= sp;      | SIP    |     :     =             :     | SIP App|=
|   UA   |--------| Prox= y  |-----:-----------------:-----| Video  |
|        | &nb= sp;      |        |     : &nbs= p;               :     | Confe= rence
+--------+     &= nbsp;  +--------+     :         =         :     +--------+
         =                     &nbs= p;  :                 :=




The following is one possible Inte= rnet deployment model where one SIP App
is deployed in the cloud and is us= ed to provide some service which
requires access to some resources = in a local SIP App.

With this model, a trust rela= tionship must be established between the cloud
service provider and the customer.=


     Trust Domain 1=                  :   &nb= sp;Internet     :  Trust Domain 2
         =                     &nbs= p;      :               &= nbsp; :
         =   +--------+   +--------+  :     =             :
         =   | IdP    |   | SIP App|  :      =           :
    +-------| AuthZ =  |---| VM     |  :           &= nbsp;     :
    |     &nbs= p; |        |   | Server |  :     &= nbsp;           :
    |     &nbs= p; +--------+   +--------+  :      = ;           :
    |     &nbs= p;         |     |        = ;  :                 :<= /div>
    |     &nbs= p;         |     |        = ;  :                 :<= /div>
+--------+     &= nbsp;  +--------+         :     =             :     +--------+= ;
|        | &nb= sp;      | SIP    |         : =                 :     | S= IP App|
|   UA   |--------| Prox= y  |---------:-----------------:-----| Text   |
|        | &nb= sp;      |        |      =   :                 :   =   | Transcribe
+--------+     &= nbsp;  +--------+         :     =             :     +--------+= ;
         =                     &nbs= p;      :               &= nbsp; :



The following is one possible Inte= rnet deployment model with two separate
trust domains where a user from on= e trust domain is calling another user in
the other trust domain.

With this model, no initial trust = relationship between the trust domains is
needed to allow the call to be est= ablished.


     Trust Domain 1=         :    Internet     :  =        Trust Domain 2
         =                   :   &n= bsp;             :
         =       +--------+  :        = ;         :  +--------+
         =       | IdP    |  :       &nb= sp;         :  | IdP    |
    +-----------| Au= thZ  |  :                = :  | AuthZ  |-----------+
    |     &nbs= p;     |        |  :      = ;           :  |        |=           |
    |     &nbs= p;     +--------+  :         &nb= sp;       :  +--------+       &n= bsp;   |
    |     &nbs= p;                 :     =             :         &nb= sp;             |
    |     &nbs= p;                 :     =             :         &nb= sp;             |
+--------+     &= nbsp;+--------+  :             &= nbsp;   :  +--------+      +--------&#= 43;
|        | &nb= sp;    | SIP    |  :         &= nbsp;       :  | SIP    |      = ;|        |
|   UA   |------| Proxy =  |--:-----------------:--| Proxy  |------|   UA   |
|        | &nb= sp;    |        |  :      = ;           :  |        |=      |        |
+--------+     &= nbsp;+--------+  :             &= nbsp;   :  +--------+      +--------&#= 43;
         =                   :   &n= bsp;             :


Types of Clients
----------------

The solution must take into consid= eration the various types of SIP clients
that might be involved and active = in the system, e.g. softclient,
hardphones, etc.

The solution must also take into c= onsideration the limitation on some of
these clients that might impact th= e way assertions are obtained and
handled. For example, the followin= g client limitation would require an
interim step to obtain an assertio= n:

1. UI Limitation: a hardphone with= limited UI capability that only allows
   the user to interact = with the phone through the phone's keypad.

2. Security Limitation: a client t= hat is incapable of maintaining the
   security of the user'= s credentials or the assertion.

In these use cases, we would need = a way to get the assertion to the servers
that will provide the service with= out requiring the client to get access to
the assertion.


--_000_7594FB04B1934943A5C02806D1A2204B37F97548ESESSMB209erics_-- From nobody Mon May 9 12:40:41 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F4212D147 for ; Mon, 9 May 2016 12:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbwmm6QUyHSK for ; Mon, 9 May 2016 12:40:36 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0124212D0E7 for ; Mon, 9 May 2016 12:40:35 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u49JX4F2006299; Mon, 9 May 2016 15:40:32 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 22scfsd0re-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 09 May 2016 15:40:31 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Mon, 9 May 2016 15:40:30 -0400 From: "Peterson, Jon" To: Christer Holmberg , Rifaat Shekh-Yusef , "sipcore@ietf.org" Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQA= Date: Mon, 9 May 2016 19:40:29 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.151] Content-Type: multipart/alternative; boundary="_000_D356252318AAA1jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-09_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1605090280 Archived-At: Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 19:40:39 -0000 --_000_D356252318AAA1jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do think this is getting sharper - the use cases in the Trust Relationshi= ps section make a lot of this more clear. Please do number those examples s= o we can refer to them in discussion. On authentication, I'm not sure it is so easy or helpful to break it down i= nto user-to-user versus user-to-server authN. A number of ways that we coul= d add identity information to SIP might be totally agnostic to whether a us= er or server ends up being the relying party, and I don't think we want to = cordon these options off from one another. At the end of the day, in cases = where identity information is going to be consumed by the recipient of a SI= P request, I'd be happier talking about the SIP roles and functions; i.e. t= ext that says something like "authentication information carried in SIP may= be consumed by intermediaries such as proxy servers or endpoints such as u= ser agents." How that identity gets rendered to a user or a service is a se= parate question. Also, one smaller point on the authentication text: is it that you want "th= e SIP user to use his non-SIP credentials... to register with the SIP regis= trar", or, is it that you want the SIP user to be able to use a token gener= ated by the IdP to authenticate to a SIP registrar? Perhaps a question abou= t how we are defining credentials. The latter sounds more like SSO, where t= he user first logs in to the IdP; the former sounds like the registrar prox= ies the user's shared secret to the IdP in order to log the user in. Maybe = either flow is possible. It is nice to have a definition of IdP on hand, though there are a couple f= eatures of this definition I'd point out. It contains some terms like "prin= cipal authentication" which seems to carry a connotation beyond baseline au= thentication where I'm not entirely sure what is implied. I'd also single = out text that seems very narrow, like, "The IdP sends an attribute assertio= n containing trusted information about the user to the SP." The term "attri= bute assertion" there implies much of the classic SAML-like model where the= IdP is a broker for accessing a set of fields associated with a user. Is t= hat what we're solving for? Along those lines, I still do have some confusion about exactly what inform= ation we expect the IdP will supply to services for authorization. I guess = I imagine the primary decision decision here for carrying authorization inf= ormation in SIP, as it relates to authentication, is not between a self-con= tained or opaque token, but is more like these two high level choices: A) SIP carries the identity of the user as assured by the IdP. Each relying= party uses that identity to make an authorization decision about access to= its services (like a classic ACL). B) SIP carries (either by value or by reference) a set of attributes about = the user as assured by the IdP. Each relying party uses or more of those at= tributes to make an authorization decision about access to its services. Part of my disconnect here is that I think most traditional SSO-style use c= ases don't require B, they just require A. This makes me think there must b= e something interesting about the attributes that will be shared here such = that an approach more like B is needed. Anonymization is an example of a re= quirement that gets us closer to B. If we assume the existence of a "self-c= ontained token" that would tell the service everything it needs to know abo= ut whether it should authorize a request - what do we imagine that it might= contain? The Trust Relationship use cases shed the most light because they let us kn= ow whether the services have a relationship with the user. In an SSO-like c= ase for the "cloud" video conferencing service, if the service has a trust = relationship with the customer, rather than with the IdP, that would seem t= o argue for an A-like authorization method. It is in B-like architectures t= hat the services trust attributes provided by the IdP instead of the identi= ty of the customer. Though again, rather than seeing concepts of "service" = and "customer" I'd rather see this be clear about the SIP entities in the a= rchitecture that are involved. Jon Peterson Neustar, Inc. From: sipcore > o= n behalf of Christer Holmberg > Date: Sunday, May 8, 2016 at 8:27 AM To: Rifaat Shekh-Yusef = >, "sipcore@ietf.org" > Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 Hi, >From my experience, it's always better to define FUNCTIONS and the relatio= nship requirements (trust etc) between them. It is then an implementation i= ssue whether they are located in the physical node. Of course, IF there is a reason why two functions must be located in the ph= ysical node we should say so, but typically that's not the case. Regards, Christer Sent from my Windows Phone ________________________________ From: Rifaat Shekh-Yusef Sent: ?08/?05/?2016 16:25 To: sipcore@ietf.org Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 All, I did not receive any comment about this version of the text; does this mea= n that people are happy with the current text? Also, I have a question that I would like to get people's thoughts about it= : The current text assumes that the AuthN and the AuthZ functions co-reside i= n one network element; should we consider the case that these functions res= ide in separate network elements? Regards, Rifaat On Tue, May 3, 2016 at 8:16 AM, Rifaat Shekh-Yusef > wrote: All, The following is v3 of the problem statement based on the feedback provided= . Thoughts? Regards, Rifaat --- Overview -------- The following is a simplified classic SIP deployment model: +--------+ | SIP | ,---------------------------| Registrar | | | +--------+ +--------+ +--------+ | | | SIP | | SIP App| | UA |----------------------| Proxy |----------------------| Server | | | | | | | +--------+ +--------+ +--------+ With this model, the endpoint is assigned a dedicated SIP proxy/registrar and all SIP communications must go through that SIP proxy. The SIP Proxy/Registrar plays 3 different roles: 1. Authentication Server (SIP Registrar) 2. Authorization Server 3. Service provider, e.g. basic calls, call forwarding, call transfer, etc. SIP Application Servers provide advanced SIP services, e.g. conference, presence, etc. Application Servers usually have their own authentication and authorization mechanism that is separate from the one provided by the SIP proxy. We would like to discuss the idea of "outsourcing" the user authentication and services authorization to separate network element(s): Authentication (AuthN) ---------------------- There are two types of authentications in a SIP network: user-to-server authentication and user-to-user authentication. These authentications could be in the context of one trust domain, or it could cross boundaries between different trust domains. We would like to explore the idea of "outsourcing" the user authentication part to a separate IdP entity, to allow the SIP user to use his non-SIP credentials, e.g. corporate credentials, with the IdP to register with the SIP registrar, get basic services from the SIP Proxy, and get access to the advanced services provided by the SIP Application Servers. We would also like to explore the idea of using the same "outsourcing" mechanism to address the user authentication when it crosses trust domain boundaries. IdP Definition: "IdP (Identity Provider), is a system that creates, maintains, and manages identity information for principals (users, services, or systems) and provides principal authentication to other service providers (applications) within a federation or distributed network. It is a trusted third party that can be relied upon by users and servers when users and servers are establishing a dialog that must be authenticated. The IdP sends an attribute assertion containing trusted information about the user to the SP". The above IdP definition is borrowed from the following MIT Knowledge Base site: http://kb.mit.edu/confluence/display/glossary/IdP+(Identity+Provider) Authorization (AuthZ) --------------------- We would like to explore the idea of "outsourcing" the authorization part to a separate network element to allow the administrator to grant access to the basic services provided by the SIP Proxy, and the various advanced services provided by the SIP Application Servers. In general, there are two authorization mechanisms that could be used in this case: 1. Self-contained token, which includes all the authorizations needed for the server providing the service to be able to make a decision to grant or deny the service request, and might include control over the level of service provided to the user. 2. Opaque token, which requires an introspection step, where the server providing the service would reach to the authorization server to get the details of the authorizations provided for that specific token. There are pros and cons to each approach that we need to discuss and make a decision on supporting one of these, or maybe both. Trust Relationships ------------------- An important aspect of this exercise is to properly define the trust relationship between the various network elements that would enable the new desired functionalities. The following is one possible Enterprise deployment model. With this model, a trust relationship must be established between the SIP Proxy, the SIP Application servers, and the IdP. ....................................................... : : : +--------+ Trust Domain : : | IdP | : +--------------:-------| AuthZ |---------------------------+ : | : | | | : | : +--------+ | : | : | | : | : | | : +--------+ : +--------+ +--------+_ : | | : | SIP | | SIP App| | : | UA |---------:-------| Proxy |----------------------| Server | | : | | : | | | | | : +--------+ : +--------+ +--------+ | : : ---------+ : : : ....................................................... The following is one possible Internet deployment model where the SIP App is deployed in the cloud, and the local users get access to the cloud service based on local authNZ. With this model, a trust relationship must be established between the cloud service provider and the customer. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ : : | IdP | : : +-------------| AuthZ | : : | | | : : | +--------+ : : | | : : | | : : +--------+ +--------+ : : +--------+ | | | SIP | : : | SIP App| | UA |--------| Proxy |-----:-----------------:-----| Video | | | | | : : | Conference +--------+ +--------+ : : +--------+ : : The following is one possible Internet deployment model where one SIP App is deployed in the cloud and is used to provide some service which requires access to some resources in a local SIP App. With this model, a trust relationship must be established between the cloud service provider and the customer. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ +--------+ : : | IdP | | SIP App| : : +-------| AuthZ |---| VM | : : | | | | Server | : : | +--------+ +--------+ : : | | | : : | | | : : +--------+ +--------+ : : +--------+ | | | SIP | : : | SIP App| | UA |--------| Proxy |---------:-----------------:-----| Text | | | | | : : | Transcribe +--------+ +--------+ : : +--------+ : : The following is one possible Internet deployment model with two separate trust domains where a user from one trust domain is calling another user in the other trust domain. With this model, no initial trust relationship between the trust domains is needed to allow the call to be established. Trust Domain 1 : Internet : Trust Domain 2 : : +--------+ : : +--------+ | IdP | : : | IdP | +-----------| AuthZ | : : | AuthZ |-----------+ | | | : : | | | | +--------+ : : +--------+ | | : : | | : : | +--------+ +--------+ : : +--------+ +--------+ | | | SIP | : : | SIP | | | | UA |------| Proxy |--:-----------------:--| Proxy |------| UA | | | | | : : | | | | +--------+ +--------+ : : +--------+ +--------+ : : Types of Clients ---------------- The solution must take into consideration the various types of SIP clients that might be involved and active in the system, e.g. softclient, hardphones, etc. The solution must also take into consideration the limitation on some of these clients that might impact the way assertions are obtained and handled. For example, the following client limitation would require an interim step to obtain an assertion: 1. UI Limitation: a hardphone with limited UI capability that only allows the user to interact with the phone through the phone's keypad. 2. Security Limitation: a client that is incapable of maintaining the security of the user's credentials or the assertion. In these use cases, we would need a way to get the assertion to the servers that will provide the service without requiring the client to get access to the assertion. --_000_D356252318AAA1jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <7D49A3A674F6794AA9A9B66788FECE04@neustar.biz> Content-Transfer-Encoding: quoted-printable

I do think this is getting sharper - the use cases in the Trust Relati= onships section make a lot of this more clear. Please do number those examp= les so we can refer to them in discussion.

On authentication, I'm not sure it is so easy or helpful to break it d= own into user-to-user versus user-to-server authN. A number of ways that we= could add identity information to SIP might be totally agnostic to whether= a user or server ends up being the relying party, and I don't think we want to cordon these options off f= rom one another. At the end of the day, in cases where identity information= is going to be consumed by the recipient of a SIP request, I'd be happier = talking about the SIP roles and functions; i.e. text that says something like "authentication informa= tion carried in SIP may be consumed by intermediaries such as proxy servers= or endpoints such as user agents." How that identity gets rendered to= a user or a service is a separate question.

Also, one smaller point on the authentication text: is it that you wan= t "the SIP user to use his non-SIP credentials... to register with the= SIP registrar", or, is it that you want the SIP user to be able to us= e a token generated by the IdP to authenticate to a SIP registrar? Perhaps a question about how we are defining credentia= ls. The latter sounds more like SSO, where the user first logs in to the Id= P; the former sounds like the registrar proxies the user's shared secret to= the IdP in order to log the user in. Maybe either flow is possible.

It is nice to have a definition of IdP on hand, though there are a cou= ple features of this definition I'd point out. It contains some terms like = "principal authentication" which seems to carry a connotation bey= ond baseline authentication where I'm not entirely sure what is implied.  I'd also single out text that seems v= ery narrow, like, "= The IdP sends an attribute assertion containing trusted information about the user to the SP." The term "attribute asser= tion" there implies much of the classic SAML-like model where the IdP = is a broker for accessing a set of fields associated with a user. Is that w= hat we're solving for?

Along those lines, I still do have some confusion about exactly what i= nformation we expect the IdP will supply to services for authorization. I g= uess I imagine the primary decision decision here for carrying authorizatio= n information in SIP, as it relates to authentication, is not between a self-contained or opaque token, but is= more like these two high level choices:

A) SIP carries the identity of the user as assured by the IdP. Each re= lying party uses that identity to make an authorization decision about acce= ss to its services (like a classic ACL).

B) SIP carries (either by value or by reference) a set of attributes a= bout the user as assured by the IdP. Each relying party uses or more of tho= se attributes to make an authorization decision about access to its service= s.

Part of my disconnect here is that I think most traditional SSO-style = use cases don't require B, they just require A. This makes me think there m= ust be something interesting about the attributes that will be shared here = such that an approach more like B is needed. Anonymization is an example of a requirement that gets us clo= ser to B. If we assume the existence of a "self-contained token" = that would tell the service everything it needs to know about whether it sh= ould authorize a request - what do we imagine that it might contain?

The Trust Relationship use cases shed the most light because they let = us know whether the services have a relationship with the user. In an SSO-l= ike case for the "cloud" video conferencing service, if the servi= ce has a trust relationship with the customer, rather than with the IdP, that would seem to argue for an A-like authoriza= tion method. It is in B-like architectures that the services trust attribut= es provided by the IdP instead of the identity of the customer. Though agai= n, rather than seeing concepts of "service" and "customer" I'd rather see this be clear = about the SIP entities in the architecture that are involved.

Jon Peterson
Neustar, Inc.

From: sipcore <sipcore-bounces@ietf.org> on behalf of Ch= rister Holmberg <chris= ter.holmberg@ericsson.com>
Date: Sunday, May 8, 2016 at 8:27 A= M
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] SIP AuthNZ P= roblem Statement - v3

Hi,

>From my experience, it's always better to define FUNCTIONS and the rela= tionship requirements (trust etc) between them. It is then an implementatio= n issue whether they are located in the physical node.

Of course, IF there is a reason why two functions must be located in the ph= ysical node we should say so, but typically that's not the case.

Regards,

Christer

Sent from my Windows Phone
From: Rifaat Shekh-Yusef
Sent: ?08/?= 05/?2016 16:25
To: sipcore@ietf.org
Subject: Re: [= sipcore] SIP AuthNZ Problem Statement - v3

All,

I did not receive any comment about this version of the text; does this mea= n that people are happy with the current text?

Also, I have a question that I would like to get people's thoughts abo= ut it:
The current text assumes that the AuthN and the AuthZ functions co-res= ide in one network element; should we consider the case that these function= s reside in separate network elements?

Regards,
 Rifaat


On Tue, May 3, 2016 at 8:16 AM, Rifaat Shekh-Yus= ef <rifaat.ietf@= gmail.com> wrote:
All,

The following is v3 of the problem = statement based on the feedback provided.

Thoughts?

Regards,
 Rifaat


---


Overview
--------

The following is a simplified class= ic SIP deployment model:


          =                      = ; +--------+
          =                      = ; | SIP    |
    ,--------------------= -------| Registrar
    |      = ;                     | &= nbsp;      |
+--------+     &n= bsp;                +--------&#= 43;                     &= nbsp;+--------+
|        | &nbs= p;                    | S= IP    |                 &= nbsp;    | SIP App|
|   UA   |---------------= -------| Proxy  |----------------------| Server |
|        | &nbs= p;                    | &= nbsp;      |              = ;        |        |
+--------+     &n= bsp;                +--------&#= 43;                     &= nbsp;+--------+


With this model, the endpoint is as= signed a dedicated SIP proxy/registrar
and all SIP communications must go = through that SIP proxy.

The SIP Proxy/Registrar plays 3 dif= ferent roles:
1. Authentication Server (SIP Regis= trar)
2. Authorization Server
3. Service provider, e.g. basic cal= ls, call forwarding, call transfer, etc.

SIP Application Servers provide adv= anced SIP services, e.g. conference,
presence, etc. Application Servers = usually have their own authentication
and authorization mechanism that is= separate from the one provided by the
SIP proxy.

We would like to discuss the idea o= f "outsourcing" the user authentication
and services authorization to separ= ate network element(s):



Authentication (AuthN)
----------------------

There are two types of authenticati= ons in a SIP network: user-to-server
authentication and user-to-user aut= hentication. These authentications could
be in the context of one trust doma= in, or it could cross boundaries between
different trust domains.

We would like to explore the idea o= f "outsourcing" the user authentication
part to a separate IdP entity, to a= llow the SIP user to use his non-SIP
credentials, e.g. corporate credent= ials, with the IdP to register with the
SIP registrar, get basic services f= rom the SIP Proxy, and get access to the
advanced services provided by the S= IP Application Servers.

We would also like to explore the i= dea of using the same "outsourcing"
mechanism to address the user authe= ntication when it crosses trust domain
boundaries.


IdP Definition:

    "IdP (Identity P= rovider), is a system that creates, maintains, and
    manages identity info= rmation for principals (users, services, or
    systems) and provides= principal authentication to other service
    providers (applicatio= ns) within a federation or distributed network.
    It is a trusted third= party that can be relied upon by users and
    servers when users an= d servers are establishing a dialog that must be
    authenticated. The Id= P sends an attribute assertion containing trusted
    information about the= user to the SP".

The above IdP definition is borrowe= d from the following MIT Knowledge Base
site:



Authorization (AuthZ)
---------------------

We would like to explore the idea o= f "outsourcing" the authorization part
to a separate network element to al= low the administrator to grant access to
the basic services provided by the = SIP Proxy, and the various advanced
services provided by the SIP Applic= ation Servers.

In general, there are two authoriza= tion mechanisms that could be used in
this case:

1. Self-contained token, which incl= udes all the authorizations needed for
   the server providing t= he service to be able to make a decision to grant
   or deny the service re= quest, and might include control over the level of
   service provided to th= e user.

2. Opaque token, which requires an = introspection step, where the server
   providing the service = would reach to the authorization server to get the
   details of the authori= zations provided for that specific token.

There are pros and cons to each app= roach that we need to discuss and make a
decision on supporting one of these= , or maybe both.


Trust Relationships
-------------------

An important aspect of this exercis= e is to properly define the trust
relationship between the various ne= twork elements that would enable the new
desired functionalities.


The following is one possible Enter= prise deployment model. With this model,
a trust relationship must= be established between the SIP Proxy, the SIP
Application servers, and the IdP.

          =          .........................................= ..............
          =          :           &nbs= p;                     &n= bsp;                   :
          =          :       +--------+=           Trust Domain        = ;     :
          =          :       | IdP    = ;|                     &n= bsp;              :
    +--------------:-= ------| AuthZ  |---------------------------+       =  :
    |      = ;        :       |       =  |                   &nbs= p;       |        :
    |      = ;        :       +--------+ &nbs= p;                     &n= bsp;   |        :
    |      = ;        :           |   =                      = ;        |        :
    |      = ;        :           |   =                      = ;        |        :
+--------+     &n= bsp;   :       +--------+       =                +--------+_ =   :
|        | &nbs= p;       :       | SIP    |   =                    | SIP = App| |  :
|   UA   |---------:-----= --| Proxy  |----------------------| Server | |  :
|        | &nbs= p;       :       |        = ;|                     &n= bsp;|        | |  :
+--------+     &n= bsp;   :       +--------+       =                +--------+ |=  :
          =          :           &nbs= p;                     &n= bsp;       ---------+  :
          =          :           &nbs= p;                     &n= bsp;                   :
          =          .........................................= ..............



The following is one possible Inter= net deployment model where the SIP App
is deployed in the cloud, and the l= ocal users get access to the cloud
service based on local authNZ.

With this model, a trust relat= ionship must be established between the cloud
service provider and the customer.<= /font>


     Trust Domain 1 =              :    Internet &nb= sp;   :  Trust Domain 2
          =                      = ;  :                 :<= /div>
          =         +--------+     :    = ;             :
          =         | IdP    |     :   &nb= sp;             :
    +-------------| A= uthZ  |     :             &nbs= p;   :
    |      = ;       |        |     :  = ;               :
    |      = ;       +--------+     :     &nb= sp;           :
    |      = ;           |          : =                 :
    |      = ;           |          : =                 :
+--------+     &n= bsp;  +--------+     :         &= nbsp;       :     +--------+
|        | &nbs= p;      | SIP    |     :     &= nbsp;           :     | SIP App|<= /div>
|   UA   |--------| Proxy=  |-----:-----------------:-----| Video  |
|        | &nbs= p;      |        |     :  = ;               :     | Confer= ence
+--------+     &n= bsp;  +--------+     :         &= nbsp;       :     +--------+
          =                      = ;  :                 :<= /div>




The following is one possible Inter= net deployment model where one SIP App
is deployed in the cloud and is use= d to provide some service which
requires access to some resources i= n a local SIP App.

With this model, a trust relat= ionship must be established between the cloud
service provider and the customer.<= /font>


     Trust Domain 1 =                  :   &nbs= p;Internet     :  Trust Domain 2
          =                      = ;      :               &n= bsp; :
          =   +--------+   +--------+  :     &= nbsp;           :
          =   | IdP    |   | SIP App|  :       =           :
    +-------| AuthZ &= nbsp;|---| VM     |  :           &n= bsp;     :
    |      = ; |        |   | Server |  :     &n= bsp;           :
    |      = ; +--------+   +--------+  :      =           :
    |      = ;         |     |        =  :                 :
    |      = ;         |     |        =  :                 :
+--------+     &n= bsp;  +--------+         :     &= nbsp;           :     +--------+=
|        | &nbs= p;      | SIP    |         : &= nbsp;               :     | SI= P App|
|   UA   |--------| Proxy=  |---------:-----------------:-----| Text   |
|        | &nbs= p;      |        |       =   :                 :   &= nbsp; | Transcribe
+--------+     &n= bsp;  +--------+         :     &= nbsp;           :     +--------+=
          =                      = ;      :               &n= bsp; :



The following is one possible Inter= net deployment model with two separate
trust domains where a user from one= trust domain is calling another user in
the other trust domain.

With this model, no initial trust r= elationship between the trust domains is
needed to allow the call to be esta= blished.


     Trust Domain 1 =         :    Internet     :   =        Trust Domain 2
          =                   :   &nb= sp;             :
          =       +--------+  :        =         :  +--------+
          =       | IdP    |  :       &nbs= p;         :  | IdP    |
    +-----------| Aut= hZ  |  :                 = :  | AuthZ  |-----------+
    |      = ;     |        |  :      =           :  |        | =           |
    |      = ;     +--------+  :         &nbs= p;       :  +--------+       &nb= sp;   |
    |      = ;                 :     &= nbsp;           :         &nbs= p;             |
    |      = ;                 :     &= nbsp;           :         &nbs= p;             |
+--------+     &n= bsp;+--------+  :             &n= bsp;   :  +--------+      +--------= 3;
|        | &nbs= p;    | SIP    |  :         &n= bsp;       :  | SIP    |      = |        |
|   UA   |------| Proxy &= nbsp;|--:-----------------:--| Proxy  |------|   UA   |
|        | &nbs= p;    |        |  :      =           :  |        | =      |        |
+--------+     &n= bsp;+--------+  :             &n= bsp;   :  +--------+      +--------= 3;
          =                   :   &nb= sp;             :


Types of Clients
----------------

The solution must take into conside= ration the various types of SIP clients
that might be involved and active i= n the system, e.g. softclient,
hardphones, etc.

The solution must also take into co= nsideration the limitation on some of
these clients that might impact the= way assertions are obtained and
handled. For example, the following= client limitation would require an
interim step to obtain an assertion= :

1. UI Limitation: a hardphone with = limited UI capability that only allows
   the user to interact w= ith the phone through the phone's keypad.

2. Security Limitation: a client th= at is incapable of maintaining the
   security of the user's= credentials or the assertion.

In these use cases, we would need a= way to get the assertion to the servers
that will provide the service witho= ut requiring the client to get access to
the assertion.


 --_000_D356252318AAA1jonpetersonneustarbiz_-- From nobody Wed May 11 09:31:00 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D564612D1F0 for ; Wed, 11 May 2016 09:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kcq2MCI-fHj7 for ; Wed, 11 May 2016 09:30:51 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBFF512D1E8 for ; Wed, 11 May 2016 09:30:50 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id f66so64010237vkh.2 for ; Wed, 11 May 2016 09:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=VHFTK20jyxMHIGEtTcEEKt4P0YMoZOHAe66exD3i9II=; b=UYZo3KqXDb3AW62PMHMzbt4HBA/u0yrAkEaEWlymBnaQvQWjCi05k82iv758640JuW RyNQd65p6hIk2CLwyFxRA48zH515vuJUjf7QenAV4+8ix6Wo+fG6gBwgLg+2/AJGF75T /dLufJNbYq847k0T1v++qhViN4wbPfsas3ju+10xDJDTxvBfm1uqjH+egHAv5K8HEnTF tYF6EJQ4rvvEBZ7mfze3XbECkEpaOW9hF0p8MUIj2byjVEf3dlFo91MMJqdm+ULkY+Sr X+PLAphjbGG/XUDspVKLn1Kdmkp2Ky9fV5tBfcs5BdPqOgAHEPcQ9y+WEMnJKt3G+1AR /wyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=VHFTK20jyxMHIGEtTcEEKt4P0YMoZOHAe66exD3i9II=; b=c8zpLfHDSYKrWdmAJQ4AMihg2Ag4J/1qIfDGsjAkXtMGYZg1wM9kMEBufanCkaypSr xB2WwvKv3pNz4TmiIxRD1KI6/C6RcfxEituhKJDAO/2hSUfPdaBv3qAwee3SwXRuBPdY S7kHsOxVWdenLbe/NLoZp0NRF/04cNQaYdcKRF/Yyp7Q3uS6wogMJxwAElqRoqCiFKA+ L+n6hi+oNa5mH37tTGee26Ax4+WixCvD99KrLCYhqLyhKvJXthlUL0ANjVmrQO3SUrV2 GAY01kJNPX7AgvxhKKIC/sL7R1+5FLrT29b9qlAPjlng8Tzv1jAdLdh5RK67tm1YNYUS snMw== X-Gm-Message-State: AOPr4FUqiNeD87w5458IR3nRawc07IatufoOseN4EHnkSro9tp+zMDspzgFcl0pPOOGzoaJIGbCFThY17BrzOg== MIME-Version: 1.0 X-Received: by 10.176.69.235 with SMTP id u98mr2241912uau.131.1462984249871; Wed, 11 May 2016 09:30:49 -0700 (PDT) Received: by 10.176.7.101 with HTTP; Wed, 11 May 2016 09:30:49 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> Date: Wed, 11 May 2016 12:30:49 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=94eb2c11c4c286a89a0532939066 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 16:31:00 -0000 --94eb2c11c4c286a89a0532939066 Content-Type: text/plain; charset=UTF-8 On Mon, May 9, 2016 at 3:40 PM, Peterson, Jon wrote: > > I do think this is getting sharper - the use cases in the Trust > Relationships section make a lot of this more clear. Please do number those > examples so we can refer to them in discussion. > > Sure. > On authentication, I'm not sure it is so easy or helpful to break it down > into user-to-user versus user-to-server authN. A number of ways that we > could add identity information to SIP might be totally agnostic to whether > a user or server ends up being the relying party, and I don't think we want > to cordon these options off from one another. At the end of the day, in > cases where identity information is going to be consumed by the recipient > of a SIP request, I'd be happier talking about the SIP roles and functions; > i.e. text that says something like "authentication information carried in > SIP may be consumed by intermediaries such as proxy servers or endpoints > such as user agents." How that identity gets rendered to a user or a > service is a separate question. > > I guess that depends on how you envision the solution to the various use cases would work. Let's take the conference server use case as an example: In this case the user would authenticate to the IdP locally, but that authenticated user identity does not have to travel all the way to the conference server; all the conference server should care about is that it received a token from a trusted entity for a specific domain to authorize access to its service; the identity of the user is not important to the server providing the service. This obviously is not the case with the user-to-user authentication use case, where the identity of the caller is the main issue at hand. Also, one smaller point on the authentication text: is it that you want > "the SIP user to use his non-SIP credentials... to register with the SIP > registrar", or, is it that you want the SIP user to be able to use a token > generated by the IdP to authenticate to a SIP registrar? Perhaps a question > about how we are defining credentials. The latter sounds more like SSO, > where the user first logs in to the IdP; the former sounds like the > registrar proxies the user's shared secret to the IdP in order to log the > user in. Maybe either flow is possible. > > I think that the registrar should *not *be part of the authentication process at all, and it should never get access to the shared secret. The whole idea is to delegate the authentication process to the IdP. The user should authenticate to the IdP, get a token(s) (or a code) and use that to register with the registrar. > It is nice to have a definition of IdP on hand, though there are a couple > features of this definition I'd point out. It contains some terms like > "principal authentication" which seems to carry a connotation beyond > baseline authentication where I'm not entirely sure what is implied. I'd > also single out text that seems very narrow, like, "The IdP sends an > attribute assertion containing trusted information about the user to the > SP." The term "attribute assertion" there implies much of the classic > SAML-like model where the IdP is a broker for accessing a set of fields > associated with a user. Is that what we're solving for? > > Along those lines, I still do have some confusion about exactly what > information we expect the IdP will supply to services for authorization. I > guess I imagine the primary decision decision here for carrying > authorization information in SIP, as it relates to authentication, is not > between a self-contained or opaque token, but is more like these two high > level choices: > > A) SIP carries the identity of the user as assured by the IdP. Each > relying party uses that identity to make an authorization decision about > access to its services (like a classic ACL). > > B) SIP carries (either by value or by reference) a set of attributes about > the user as assured by the IdP. Each relying party uses or more of those > attributes to make an authorization decision about access to its services. > > Part of my disconnect here is that I think most traditional SSO-style use > cases don't require B, they just require A. This makes me think there must > be something interesting about the attributes that will be shared here such > that an approach more like B is needed. Anonymization is an example of a > requirement that gets us closer to B. If we assume the existence of a > "self-contained token" that would tell the service everything it needs to > know about whether it should authorize a request - what do we imagine that > it might contain? > > I think that we need two types of tokens; let's, for now, call them *AuthN Token* and *AuthZ Token*. (we need more that two, but this is good enough for now). AuthN Token represents the user identity, while the AuthZ Token represents the services the user is authorized to access. The AuthN Token could be used inside the trusted domain but is not required to leave that trust domain in the user-to-server use cases. The AuthZ Token is the token that will be allowed to leave the trust domain and be consumed by the server providing the service. This would allow us to achieve the SSO inside the trust domain, and control the access to services inside and outside the trust domain. > The Trust Relationship use cases shed the most light because they let us > know whether the services have a relationship with the user. In an SSO-like > case for the "cloud" video conferencing service, if the service has a trust > relationship with the customer, rather than with the IdP, that would seem > to argue for an A-like authorization method. It is in B-like architectures > that the services trust attributes provided by the IdP instead of the > identity of the customer. Though again, rather than seeing concepts of > "service" and "customer" I'd rather see this be clear about the SIP > entities in the architecture that are involved. > > Ok. Regards, Rifaat > Jon Peterson > Neustar, Inc. > > From: sipcore on behalf of Christer Holmberg < > christer.holmberg@ericsson.com> > Date: Sunday, May 8, 2016 at 8:27 AM > To: Rifaat Shekh-Yusef , "sipcore@ietf.org" < > sipcore@ietf.org> > Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 > > Hi, > > >From my experience, it's always better to define FUNCTIONS and the > relationship requirements (trust etc) between them. It is then an > implementation issue whether they are located in the physical node. > > Of course, IF there is a reason why two functions must be located in the > physical node we should say so, but typically that's not the case. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Rifaat Shekh-Yusef > Sent: ?08/?05/?2016 16:25 > > To: sipcore@ietf.org > Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 > > All, > > I did not receive any comment about this version of the text; does this > mean that people are happy with the current text? > > Also, I have a question that I would like to get people's thoughts about > it: > The current text assumes that the AuthN and the AuthZ functions co-reside > in one network element; should we consider the case that these functions > reside in separate network elements? > > Regards, > Rifaat > > > On Tue, May 3, 2016 at 8:16 AM, Rifaat Shekh-Yusef > wrote: > >> All, >> >> The following is v3 of the problem statement based on the feedback >> provided. >> >> Thoughts? >> >> Regards, >> Rifaat >> >> >> --- >> >> >> Overview >> -------- >> >> The following is a simplified classic SIP deployment model: >> >> >> +--------+ >> | SIP | >> ,---------------------------| Registrar >> | | | >> +--------+ +--------+ +--------+ >> | | | SIP | | SIP App| >> | UA |----------------------| Proxy |----------------------| Server | >> | | | | | | >> +--------+ +--------+ +--------+ >> >> >> With this model, the endpoint is assigned a dedicated SIP proxy/registrar >> and all SIP communications must go through that SIP proxy. >> >> The SIP Proxy/Registrar plays 3 different roles: >> 1. Authentication Server (SIP Registrar) >> 2. Authorization Server >> 3. Service provider, e.g. basic calls, call forwarding, call transfer, >> etc. >> >> SIP Application Servers provide advanced SIP services, e.g. conference, >> presence, etc. Application Servers usually have their own authentication >> and authorization mechanism that is separate from the one provided by the >> SIP proxy. >> >> We would like to discuss the idea of "outsourcing" the user authentication >> and services authorization to separate network element(s): >> >> >> >> Authentication (AuthN) >> ---------------------- >> >> There are two types of authentications in a SIP network: user-to-server >> authentication and user-to-user authentication. These authentications >> could >> be in the context of one trust domain, or it could cross boundaries >> between >> different trust domains. >> >> We would like to explore the idea of "outsourcing" the user authentication >> part to a separate IdP entity, to allow the SIP user to use his non-SIP >> credentials, e.g. corporate credentials, with the IdP to register with the >> SIP registrar, get basic services from the SIP Proxy, and get access to >> the >> advanced services provided by the SIP Application Servers. >> >> We would also like to explore the idea of using the same "outsourcing" >> mechanism to address the user authentication when it crosses trust domain >> boundaries. >> >> >> IdP Definition: >> >> "IdP (Identity Provider), is a system that creates, maintains, and >> manages identity information for principals (users, services, or >> systems) and provides principal authentication to other service >> providers (applications) within a federation or distributed network. >> It is a trusted third party that can be relied upon by users and >> servers when users and servers are establishing a dialog that must be >> authenticated. The IdP sends an attribute assertion containing trusted >> information about the user to the SP". >> >> The above IdP definition is borrowed from the following MIT Knowledge Base >> site: >> http://kb.mit.edu/confluence/display/glossary/IdP+(Identity+Provider) >> >> >> >> Authorization (AuthZ) >> --------------------- >> >> We would like to explore the idea of "outsourcing" the authorization part >> to a separate network element to allow the administrator to grant access >> to >> the basic services provided by the SIP Proxy, and the various advanced >> services provided by the SIP Application Servers. >> >> In general, there are two authorization mechanisms that could be used in >> this case: >> >> 1. Self-contained token, which includes all the authorizations needed for >> the server providing the service to be able to make a decision to grant >> or deny the service request, and might include control over the level >> of >> service provided to the user. >> >> 2. Opaque token, which requires an introspection step, where the server >> providing the service would reach to the authorization server to get >> the >> details of the authorizations provided for that specific token. >> >> There are pros and cons to each approach that we need to discuss and make >> a >> decision on supporting one of these, or maybe both. >> >> >> Trust Relationships >> ------------------- >> >> An important aspect of this exercise is to properly define the trust >> relationship between the various network elements that would enable the >> new >> desired functionalities. >> >> >> The following is one possible Enterprise deployment model. With this >> model, >> a trust relationship must be established between the SIP Proxy, the SIP >> Application servers, and the IdP. >> >> ....................................................... >> : : >> : +--------+ Trust Domain : >> : | IdP | : >> +--------------:-------| AuthZ |---------------------------+ : >> | : | | | : >> | : +--------+ | : >> | : | | : >> | : | | : >> +--------+ : +--------+ +--------+_ : >> | | : | SIP | | SIP App| | : >> | UA |---------:-------| Proxy |----------------------| Server | | : >> | | : | | | | | : >> +--------+ : +--------+ +--------+ | : >> : ---------+ : >> : : >> ....................................................... >> >> >> >> The following is one possible Internet deployment model where the SIP App >> is deployed in the cloud, and the local users get access to the cloud >> service based on local authNZ. >> >> With this model, a trust relationship must be established between the >> cloud >> service provider and the customer. >> >> >> Trust Domain 1 : Internet : Trust Domain 2 >> : : >> +--------+ : : >> | IdP | : : >> +-------------| AuthZ | : : >> | | | : : >> | +--------+ : : >> | | : : >> | | : : >> +--------+ +--------+ : : +--------+ >> | | | SIP | : : | SIP App| >> | UA |--------| Proxy |-----:-----------------:-----| Video | >> | | | | : : | Conference >> +--------+ +--------+ : : +--------+ >> : : >> >> >> >> >> The following is one possible Internet deployment model where one SIP App >> is deployed in the cloud and is used to provide some service which >> requires access to some resources in a local SIP App. >> >> With this model, a trust relationship must be established between the >> cloud >> service provider and the customer. >> >> >> Trust Domain 1 : Internet : Trust Domain 2 >> : : >> +--------+ +--------+ : : >> | IdP | | SIP App| : : >> +-------| AuthZ |---| VM | : : >> | | | | Server | : : >> | +--------+ +--------+ : : >> | | | : : >> | | | : : >> +--------+ +--------+ : : +--------+ >> | | | SIP | : : | SIP App| >> | UA |--------| Proxy |---------:-----------------:-----| Text | >> | | | | : : | Transcribe >> +--------+ +--------+ : : +--------+ >> : : >> >> >> >> The following is one possible Internet deployment model with two separate >> trust domains where a user from one trust domain is calling another user >> in >> the other trust domain. >> >> With this model, no initial trust relationship between the trust domains >> is >> needed to allow the call to be established. >> >> >> Trust Domain 1 : Internet : Trust Domain 2 >> : : >> +--------+ : : +--------+ >> | IdP | : : | IdP | >> +-----------| AuthZ | : : | AuthZ |-----------+ >> | | | : : | | | >> | +--------+ : : +--------+ | >> | : : | >> | : : | >> +--------+ +--------+ : : +--------+ >> +--------+ >> | | | SIP | : : | SIP | | >> | >> | UA |------| Proxy |--:-----------------:--| Proxy |------| UA >> | >> | | | | : : | | | >> | >> +--------+ +--------+ : : +--------+ >> +--------+ >> : : >> >> >> Types of Clients >> ---------------- >> >> The solution must take into consideration the various types of SIP clients >> that might be involved and active in the system, e.g. softclient, >> hardphones, etc. >> >> The solution must also take into consideration the limitation on some of >> these clients that might impact the way assertions are obtained and >> handled. For example, the following client limitation would require an >> interim step to obtain an assertion: >> >> 1. UI Limitation: a hardphone with limited UI capability that only allows >> the user to interact with the phone through the phone's keypad. >> >> 2. Security Limitation: a client that is incapable of maintaining the >> security of the user's credentials or the assertion. >> >> In these use cases, we would need a way to get the assertion to the >> servers >> that will provide the service without requiring the client to get access >> to >> the assertion. >> >> > --94eb2c11c4c286a89a0532939066 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, May 9, 2016 at 3:40 PM, Peterson, Jon <jon.peterson@neu= star.biz> wrote:

I do think this is getting sharper - the use cases in the Trust Relati= onships section make a lot of this more clear. Please do number those examp= les so we can refer to them in discussion.


Sure.

=C2=A0
On authentication, I'm not sure it is so easy or helpful to break = it down into user-to-user versus user-to-server authN. A number of ways tha= t we could add identity information to SIP might be totally agnostic to whe= ther a user or server ends up being the relying party, and I don't think we want to cordon these options o= ff from one another. At the end of the day, in cases where identity informa= tion is going to be consumed by the recipient of a SIP request, I'd be = happier talking about the SIP roles and functions; i.e. text that says something like "authentication informa= tion carried in SIP may be consumed by intermediaries such as proxy servers= or endpoints such as user agents." How that identity gets rendered to= a user or a service is a separate question.


I guess that depends on how you envision the so= lution to the various use cases would work. Let's take the conference s= erver use case as an example:=C2=A0
In this case the user would authenticate to the IdP l= ocally, but that authenticated user identity does not have to travel all th= e way to the conference server; all the conference server should care about= is that it received a token from a trusted entity for a specific domain to= authorize access to its service; the identity of the user is not important= to the server providing the service.

This obviously is not the case with the user-to-user a= uthentication use case, where the identity of the caller is the main issue = at hand.



Also, one smaller point on the authentication text: is it that you wan= t "the SIP user to use his non-SIP credentials... to register with the= SIP registrar", or, is it that you want the SIP user to be able to us= e a token generated by the IdP to authenticate to a SIP registrar? Perhaps a question about how we are defining credentia= ls. The latter sounds more like SSO, where the user first logs in to the Id= P; the former sounds like the registrar proxies the user's shared secre= t to the IdP in order to log the user in. Maybe either flow is possible.


I think that the registrar should not be part= of the authentication process at all, and it should never get access to th= e shared secret. The whole idea is to delegate the authentication process t= o the IdP.=C2=A0
The user should authenticate to the IdP, get a token(s) (or a code) and = use that to register with the registrar.

= =C2=A0
It is nice to have a definition of IdP on hand, though there are a cou= ple features of this definition I'd point out. It contains some terms l= ike "principal authentication" which seems to carry a connotation= beyond baseline authentication where I'm not entirely sure what is implied.=C2=A0 I'd also single out text that see= ms very narrow, like, "The IdP sends an attribute assertion containing trusted=C2=A0information about the user to the SP."=C2=A0The term "attribute asser= tion" there implies much of the classic SAML-like model where the IdP = is a broker for accessing a set of fields associated with a user. Is that w= hat we're solving for?

The Trust Relationship use cases shed the most light because they let = us know whether the services have a relationship with the user. In an SSO-l= ike case for the "cloud" video conferencing service, if the servi= ce has a trust relationship with the customer, rather than with the IdP, that would seem to argue for an A-like authoriza= tion method. It is in B-like architectures that the services trust attribut= es provided by the IdP instead of the identity of the customer. Though agai= n, rather than seeing concepts of "service" and "customer" I'd rather see this be cl= ear about the SIP entities in the architecture that are involved.


Ok.

Regards,
=C2=A0Rifaat


=
=C2=A0
Jon Peterson
Neustar, Inc.

From: sipcore <sipcore-bounces@ietf.org&g= t; on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Sunday, May 8, 2016 at 8:27 A= M
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, "sipcore= @ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] SIP AuthNZ P= roblem Statement - v3

Hi,

>From my experience, it's always better to define FUNCTIONS and the = relationship requirements (trust etc) between them. It is then an implement= ation issue whether they are located in the physical node.

Of course, IF there is a reason why two functions must be located in the ph= ysical node we should say so, but typically that's not the case.

Regards,

Christer

Sent from my Windows Phone
From: Rifaat Shekh-Yusef=
Sent: ?08/?0= 5/?2016 16:25

To: sipcore@ietf.org=
Subject: Re: [s= ipcore] SIP AuthNZ Problem Statement - v3

All,

I did not receive any comment about this version of the text; does this mea= n that people are happy with the current text?

Also, I have a question that I would like to get people's thoughts= about it:
The current text assumes that the AuthN and the AuthZ functions co-res= ide in one network element; should we consider the case that these function= s reside in separate network elements?

Regards,
=C2=A0Rifaat


On Tue, May 3, 2016 at 8:16 AM, Rifaat Shekh-Yus= ef <rifaat.ietf@= gmail.com> wrote:
All,

The following is v3 of the problem = statement based on the feedback provided.

Thoughts?

Regards,
=C2=A0Rifaat


---


Overview
--------

The following is a simplified class= ic SIP deployment model:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | SIP =C2=A0 =C2=A0|
=C2=A0 =C2=A0 ,--------------------= -------| Registrar
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------= +
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = SIP =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| SIP App|
| =C2=A0 UA =C2=A0 |---------------= -------| Proxy =C2=A0|----------------------| Server |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------= +


With this model, the endpoint is as= signed a dedicated SIP proxy/registrar
and all SIP communications must go = through that SIP proxy.

The SIP Proxy/Registrar plays 3 dif= ferent roles:
1. Authentication Server (SIP Regis= trar)
2. Authorization Server
3. Service provider, e.g. basic cal= ls, call forwarding, call transfer, etc.

SIP Application Servers provide adv= anced SIP services, e.g. conference,
presence, etc. Application Servers = usually have their own authentication
and authorization mechanism that is= separate from the one provided by the
SIP proxy.

We would like to discuss the idea o= f "outsourcing" the user authentication
and services authorization to separ= ate network element(s):



Authentication (AuthN)
----------------------

There are two types of authenticati= ons in a SIP network: user-to-server
authentication and user-to-user aut= hentication. These authentications could
be in the context of one trust doma= in, or it could cross boundaries between
different trust domains.

We would like to explore the idea o= f "outsourcing" the user authentication
part to a separate IdP entity, to a= llow the SIP user to use his non-SIP
credentials, e.g. corporate credent= ials, with the IdP to register with the
SIP registrar, get basic services f= rom the SIP Proxy, and get access to the
advanced services provided by the S= IP Application Servers.

We would also like to explore the i= dea of using the same "outsourcing"
mechanism to address the user authe= ntication when it crosses trust domain
boundaries.


IdP Definition:

=C2=A0 =C2=A0 "IdP (Identity P= rovider), is a system that creates, maintains, and
=C2=A0 =C2=A0 manages identity info= rmation for principals (users, services, or
=C2=A0 =C2=A0 systems) and provides= principal authentication to other service
=C2=A0 =C2=A0 providers (applicatio= ns) within a federation or distributed network.
=C2=A0 =C2=A0 It is a trusted third= party that can be relied upon by users and
=C2=A0 =C2=A0 servers when users an= d servers are establishing a dialog that must be
=C2=A0 =C2=A0 authenticated. The Id= P sends an attribute assertion containing trusted
=C2=A0 =C2=A0 information about the= user to the SP".

The above IdP definition is borrowe= d from the following MIT Knowledge Base
site:
http://kb.= mit.edu/confluence/display/glossary/IdP+(Identity+Provider)



Authorization (AuthZ)
---------------------

We would like to explore the idea o= f "outsourcing" the authorization part
to a separate network element to al= low the administrator to grant access to
the basic services provided by the = SIP Proxy, and the various advanced
services provided by the SIP Applic= ation Servers.

In general, there are two authoriza= tion mechanisms that could be used in
this case:

1. Self-contained token, which incl= udes all the authorizations needed for
=C2=A0 =C2=A0the server providing t= he service to be able to make a decision to grant
=C2=A0 =C2=A0or deny the service re= quest, and might include control over the level of
=C2=A0 =C2=A0service provided to th= e user.

2. Opaque token, which requires an = introspection step, where the server
=C2=A0 =C2=A0providing the service = would reach to the authorization server to get the
=C2=A0 =C2=A0details of the authori= zations provided for that specific token.

There are pros and cons to each app= roach that we need to discuss and make a
decision on supporting one of these= , or maybe both.


Trust Relationships
-------------------

An important aspect of this exercis= e is to properly define the trust
relationship between the various ne= twork elements that would enable the new
desired functionalities.


The following is one possible Enter= prise deployment model. With this model,
a trust=C2=A0relationship=C2=A0must= be established between the SIP Proxy, the SIP
Application servers, and the IdP.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.........................................= ..............
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Trust Domain =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 | IdP =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 +--------------:-----= --| AuthZ =C2=A0|---------------------------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0:<= /font>
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0:
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0:
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+_ =C2=A0 :
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 | SIP =C2=A0 =C2=A0| =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SIP= App| | =C2=A0:
| =C2=A0 UA =C2=A0 |---------:-----= --| Proxy =C2=A0|----------------------| Server | | =C2=A0:
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| | =C2=A0:
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ | =C2=A0:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 ---------+ =C2=A0:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.........................................= ..............



The following is one possible Inter= net deployment model where the SIP App
is deployed in the cloud, and the l= ocal users get access to the cloud
service based on local authNZ.

With this model, a trust=C2=A0relat= ionship=C2=A0must be established between the cloud
service provider and the customer.<= /font>


=C2=A0 =C2=A0 =C2=A0Trust Domain 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0Internet =C2= =A0 =C2=A0 : =C2=A0Trust Domain 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | IdP =C2=A0 =C2=A0| =C2=A0 =C2=A0 : =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 +-------------| AuthZ= =C2=A0| =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 : =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------+ =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : =C2=A0 =C2=A0 +--------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0| SIP =C2=A0 =C2=A0| =C2=A0 =C2=A0 : =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 | SIP App|=
| =C2=A0 UA =C2=A0 |--------| Proxy= =C2=A0|-----:-----------------:-----| Video =C2=A0|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 : =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 | Conf= erence
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------+ =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : =C2=A0 =C2=A0 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :




The following is one possible Inter= net deployment model where one SIP App
is deployed in the cloud and is use= d to provide some service which
requires access to some resources i= n a local SIP App.

With this model, a trust=C2=A0relat= ionship=C2=A0must be established between the cloud
service provider and the customer.<= /font>


=C2=A0 =C2=A0 =C2=A0Trust Domain 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2= =A0Internet =C2=A0 =C2=A0 : =C2=A0Trust Domain 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +--------+ =C2=A0 +--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | IdP =C2=A0 =C2=A0| =C2=A0 | SIP App| =C2=A0: =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 +-------| AuthZ =C2= =A0|---| VM =C2=A0 =C2=A0 | =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 | Server | =C2=A0: =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 +--------+ =C2=A0 +--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 +--------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0| SIP =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 | S= IP App|
| =C2=A0 UA =C2=A0 |--------| Proxy= =C2=A0|---------:-----------------:-----| Text =C2=A0 |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0= =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 = =C2=A0 | Transcribe
+--------+ =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 +--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 :



The following is one possible Inter= net deployment model with two separate
trust domains where a user from one= trust domain is calling another user in
the other trust domain.

With this model, no initial trust r= elationship between the trust domains is
needed to allow the call to be esta= blished.


=C2=A0 =C2=A0 =C2=A0Trust Domain 1 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0Internet =C2=A0 =C2=A0 : =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Trust Domain 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 : =C2=A0+--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | IdP =C2=A0 =C2=A0| =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0| IdP =C2=A0 =C2=A0|
=C2=A0 =C2=A0 +-----------| AuthZ = =C2=A0| =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = =C2=A0| AuthZ =C2=A0|-----------+
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0: =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--------+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 : =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+--------+ =C2=A0 =C2=A0 =C2=A0+---= -----+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0+--------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0| SIP =C2=A0 =C2=A0| =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0| SIP =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| =C2=A0 UA =C2=A0 |------| Proxy = =C2=A0|--:-----------------:--| Proxy =C2=A0|------| =C2=A0 UA =C2=A0 |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0: =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+--------+ =C2=A0 =C2=A0 =C2=A0+---= -----+ =C2=A0: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0+--------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :


Types of Clients
----------------

The solution must take into conside= ration the various types of SIP clients
that might be involved and active i= n the system, e.g. softclient,
hardphones, etc.

The solution must also take into co= nsideration the limitation on some of
these clients that might impact the= way assertions are obtained and
handled. For example, the following= client limitation would require an
interim step to obtain an assertion= :

1. UI Limitation: a hardphone with = limited UI capability that only allows
=C2=A0 =C2=A0the user to interact w= ith the phone through the phone's keypad.

2. Security Limitation: a client th= at is incapable of maintaining the
=C2=A0 =C2=A0security of the user&#= 39;s credentials or the assertion.

In these use cases, we would need a= way to get the assertion to the servers
that will provide the service witho= ut requiring the client to get access to
the assertion.

--94eb2c11c4c286a89a0532939066-- From nobody Fri May 13 10:25:59 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEA812D09E for ; Fri, 13 May 2016 10:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG-SKO5oqF_l for ; Fri, 13 May 2016 10:25:56 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0CEC12B043 for ; Fri, 13 May 2016 10:25:55 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4DHNRXA032429; Fri, 13 May 2016 13:25:52 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 22vrkdg5wu-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 May 2016 13:25:52 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.235]) with mapi id 14.03.0279.002; Fri, 13 May 2016 13:25:50 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkA Date: Fri, 13 May 2016 17:25:49 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.151] Content-Type: multipart/alternative; boundary="_000_D35B4CE318D9ABjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-13_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605130231 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 17:25:58 -0000 --_000_D35B4CE318D9ABjonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I guess that depends on how you envision the solution to the various use ca= ses would work. Let's take the conference server use case as an example: In this case the user would authenticate to the IdP locally, but that authe= nticated user identity does not have to travel all the way to the conferenc= e server; all the conference server should care about is that it received a= token from a trusted entity for a specific domain to authorize access to i= ts service; the identity of the user is not important to the server providi= ng the service. I think we need to distinguish cases where the conference server doesn't ca= re about the user identity from cases where, for various reason, the identi= ty of the user must be withheld from the conference server. Ultimately, if = relying parties are going to receive this token, whatever it is, and then q= uery an authorization server for more specific instructions, then it matter= s whether the user identity can serve as a key for that query, or whether i= t must not serve as a key for that query to achieve some security or policy= aim. This is the distinction I was trying to inject into this discussion. I think that the registrar should not be part of the authentication process= at all, and it should never get access to the shared secret. The whole ide= a is to delegate the authentication process to the IdP. The user should authenticate to the IdP, get a token(s) (or a code) and use= that to register with the registrar. That is what I assumed you meant; I just wanted to make sure that the descr= iption of "credential" here was crisp enough for us to use. Part of my disconnect here is that I think most traditional SSO-style use c= ases don't require B, they just require A. This makes me think there must b= e something interesting about the attributes that will be shared here such = that an approach more like B is needed. Anonymization is an example of a re= quirement that gets us closer to B. If we assume the existence of a "self-c= ontained token" that would tell the service everything it needs to know abo= ut whether it should authorize a request - what do we imagine that it might= contain? I think that we need two types of tokens; let's, for now, call them AuthN T= oken and AuthZ Token. (we need more that two, but this is good enough for n= ow). Statements of that form make me very wary. I can imagine that there would b= e two ways to do this, one where we have the identity of the user serve as = a key and one where we don't. When you suggest we need a plurality of token= s, you're setting us up for a world of complexity and non-interoperability. AuthN Token represents the user identity, while the AuthZ Token represents = the services the user is authorized to access. The AuthN Token could be used inside the trusted domain but is not required= to leave that trust domain in the user-to-server use cases. The AuthZ Token is the token that will be allowed to leave the trust domain= and be consumed by the server providing the service. As a scope decision, that seems pretty arbitrary. Again, as I said previous= ly, I have a hard time imagining why we would want to specify an AuthN mech= anism that works inside the trusted domain but will require something else = if it leaves the trust domain. If a UA implementation can't anticipate whet= her or not a SIP request is going to terminate in the local trust domain (a= nd ordinarily, how could it?), then it would always have to add both. In ad= dition of course to the From header. And don't forge the PAI. And however m= any other things 3GPP has us stuff into these messages that carry the "real= " identity of the user. Our job is to arrive at architectural commonality, and to reduce the needle= ss proliferation of identifiers in SIP requests. This would allow us to achieve the SSO inside the trust domain, and control= the access to services inside and outside the trust domain. I think achieving SSO inside a trust domain can be achieved with virtually = no new protocol work on our part. It is understanding the need for anonymit= y here, and the precise requirement for access control for SIP services, an= d how those are entangled with the aforementioned SSO identifiers, that see= ms potentially worth a dispatch. Jon Peterson Neustar, Inc. --_000_D35B4CE318D9ABjonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <9EBD5F262053264C9A8E5C4BF881A9FB@neustar.biz> Content-Transfer-Encoding: quoted-printable

I guess that depends on how = you envision the solution to the various use cases would work. Let's take t= he conference server use case as an example: 
In this case the user would = authenticate to the IdP locally, but that authenticated user identity does = not have to travel all the way to the conference server; all the conference= server should care about is that it received a token from a trusted entity for a specific domain to authori= ze access to its service; the identity of the user is not important to the = server providing the service.

I think we need to distinguish cases where the conference server doesn= 't care about the user identity from cases where, for various reason, the i= dentity of the user must be withheld from the conference server. Ultimately= , if relying parties are going to receive this token, whatever it is, and then query an authorization server= for more specific instructions, then it matters whether the user identity = can serve as a key for that query, or whether it must not serve as a key fo= r that query to achieve some security or policy aim. This is the distinction I was trying to inject into this di= scussion.

I think tha= t the registrar should not be part of the authe= ntication process at all, and it should never get access to the shared secr= et. The whole idea is to delegate the authentication process to the IdP. 
The user should authenticate= to the IdP, get a token(s) (or a code) and use that to register with the r= egistrar.

That is what I assumed you meant; I just wanted to make sure that the = description of "credential" here was crisp enough for us to use.<= /div>



Part of my disconnect here is that I think most traditional SSO-style = use cases don't require B, they just require A. This makes me think there m= ust be something interesting about the attributes that will be shared here = such that an approach more like B is needed. Anonymization is an example of a requirement that gets us clo= ser to B. If we assume the existence of a "self-contained token" = that would tell the service everything it needs to know about whether it sh= ould authorize a request - what do we imagine that it might contain?


I think that we need two types of tokens; let's, for now, call them AuthN Token and AuthZ Token. (we need more that two, but this is good enough for now= ).

Statements of that form make me very wary. I can imagine that there wo= uld be two ways to do this, one where we have the identity of the user serv= e as a key and one where we don't. When you suggest we need a plurality of = tokens, you're setting us up for a world of complexity and non-interoperability.

AuthN Token represents the user identity, while the AuthZ Token repres= ents the services the user is authorized to access.

The AuthN Token could be used inside the trusted domain but is not req= uired to leave that trust domain in the user-to-server use cases.
The AuthZ Token is the token that will be allowed to leave the trust d= omain and be consumed by the server providing the service.

As a scope decision, that seems pretty arbitrary. Again, as I said pre= viously, I have a hard time imagining why we would want to specify an AuthN= mechanism that works inside the trusted domain but will require something = else if it leaves the trust domain. If a UA implementation can't anticipate whether or not a SIP request is go= ing to terminate in the local trust domain (and ordinarily, how could it?),= then it would always have to add both. In addition of course to the From h= eader. And don't forge the PAI. And however many other things 3GPP has us stuff into these messages that c= arry the "real" identity of the user.

Our job is to arrive at architectural commonality, and to reduce the n= eedless proliferation of identifiers in SIP requests.

This would allow us to achieve the SSO inside the trust domain, and co= ntrol the access to services inside and outside the trust domain.

I think achieving SSO inside a trust domain can be achieved with virtu= ally no new protocol work on our part. It is understanding the need for ano= nymity here, and the precise requirement for access control for SIP service= s, and how those are entangled with the aforementioned SSO identifiers, that seems potentially worth a dispatc= h.

Jon Peterson
Neustar, Inc.

 --_000_D35B4CE318D9ABjonpetersonneustarbiz_-- From nobody Sun May 15 06:28:38 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C59912D0D1 for ; Sun, 15 May 2016 06:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0zCbpMRhq_1 for ; Sun, 15 May 2016 06:28:35 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE01812B020 for ; Sun, 15 May 2016 06:28:34 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id s184so186219606vkb.3 for ; Sun, 15 May 2016 06:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=NftX4F3X33RoxQh2aPb9SSnaRP6fijUzDhonButw9vU=; b=OJ0eHhaYn1RmFI9L5NDt5rjM7FveJvkQcprV7iE36jnrVBItEEvyosbH3laAJC97Sd PbLHtv8neMFlro7mcaOYBvjxiJ5iIVGQx1IyNq552wlbFTvvMfYH9EluTJFDEpTl+BG8 8SdXtAVo2hkRCpD4Xlw2HK5dbvUIg7Nzn0Jo+qK/N7XLSexN1E3x2dscDWQGYbp8i0gG QXP2pS43KFxYXaV4UcOOg8bUUQf4PIH5oq2emR1IDPTHp+3+6crqDkyDHEDvueRv8Bi7 KfV1TWv89UZh23pnoDiQLNWVfFFHuRn5wqxQ6ADrZL8KGn2a4W29MGc/KvT4TWTn6qsF 2Fxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NftX4F3X33RoxQh2aPb9SSnaRP6fijUzDhonButw9vU=; b=gh3nww8+9Tr7s069yJDVeFchST+t7V26GdQZaROtVCqyxAGyrMAzG7tBp7qgh/aRie Hz72WXDEIydpZMeX/gfdFYdDLB0Tr1NYxDYaEOVryHGIkAsufCj4wIdRGZP9evic47z9 5YMJiMhxLC9Qo69cKxG4Kdz101Mt29XQGu0/zzFHxE9dypnUtBP4lWzj10HXrwvR7NAo bUj4FZM6MUafwvYP6NY51z7wGAdlNGHuDi05mJmZ80kBUGZs9Gru4Ty4xyTnZfXZu1UD ltajw2y4qPLw0JiKfn+oYT0kN9rY4qxnR6d/FsM0XoOfEi/Tvxqz3b1pIM5disViMCmz 74FQ== X-Gm-Message-State: AOPr4FV42RnE7h0bONoyY16F6kWEUEeUV461TyuABvw7vCgxHuAy7AzWyDZGpNz83uvAh7d2+teN5RgLcYV79A== MIME-Version: 1.0 X-Received: by 10.159.34.51 with SMTP id 48mr835366uad.103.1463318913917; Sun, 15 May 2016 06:28:33 -0700 (PDT) Received: by 10.176.7.101 with HTTP; Sun, 15 May 2016 06:28:33 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> Date: Sun, 15 May 2016 09:28:33 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=001a113ccd440eaa1b0532e17cb7 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 13:28:37 -0000 --001a113ccd440eaa1b0532e17cb7 Content-Type: text/plain; charset=UTF-8 On Fri, May 13, 2016 at 1:25 PM, Peterson, Jon wrote: > > I guess that depends on how you envision the solution to the various use > cases would work. Let's take the conference server use case as an example: > In this case the user would authenticate to the IdP locally, but that > authenticated user identity does not have to travel all the way to the > conference server; all the conference server should care about is that it > received a token from a trusted entity for a specific domain to authorize > access to its service; the identity of the user is not important to the > server providing the service. > > > I think we need to distinguish cases where the conference server doesn't > care about the user identity from cases where, for various reason, the > identity of the user must be withheld from the conference server. > Can you please elaborate on this? Can you provide an example? > Ultimately, if relying parties are going to receive this token, whatever > it is, and then query an authorization server for more specific > instructions, then it matters whether the user identity can serve as a key > for that query, or whether it must not serve as a key for that query to > achieve some security or policy aim. This is the distinction I was trying > to inject into this discussion. > > I think that the registrar should *not *be part of the authentication > process at all, and it should never get access to the shared secret. The > whole idea is to delegate the authentication process to the IdP. > The user should authenticate to the IdP, get a token(s) (or a code) and > use that to register with the registrar. > > > That is what I assumed you meant; I just wanted to make sure that the > description of "credential" here was crisp enough for us to use. > > Ok. I will clarify the text. > > >> Part of my disconnect here is that I think most traditional SSO-style use >> cases don't require B, they just require A. This makes me think there must >> be something interesting about the attributes that will be shared here such >> that an approach more like B is needed. Anonymization is an example of a >> requirement that gets us closer to B. If we assume the existence of a >> "self-contained token" that would tell the service everything it needs to >> know about whether it should authorize a request - what do we imagine that >> it might contain? >> >> > I think that we need two types of tokens; let's, for now, call them *AuthN > Token* and *AuthZ Token*. (we need more that two, but this is good enough > for now). > > > Statements of that form make me very wary. I can imagine that there would > be two ways to do this, one where we have the identity of the user serve as > a key and one where we don't. When you suggest we need a plurality of > tokens, you're setting us up for a world of complexity and > non-interoperability. > > There are few advantages to the idea of creating separate tokens for AuthN and AuthZ: 1. Allows separate independent entities to provide these functionalities, with some established trust between them. 2. Allows staged adoption of the new recommendation; you could start with delegation of authentication, and at a later stage delegate the authorization. > AuthN Token represents the user identity, while the AuthZ Token represents > the services the user is authorized to access. > > The AuthN Token could be used inside the trusted domain but is not > required to leave that trust domain in the user-to-server use cases. > The AuthZ Token is the token that will be allowed to leave the trust > domain and be consumed by the server providing the service. > > > As a scope decision, that seems pretty arbitrary. Again, as I said > previously, I have a hard time imagining why we would want to specify an > AuthN mechanism that works inside the trusted domain but will require > something else if it leaves the trust domain. If a UA implementation can't > anticipate whether or not a SIP request is going to terminate in the local > trust domain (and ordinarily, how could it?), then it would always have to > add both. In addition of course to the From header. And don't forge the > PAI. And however many other things 3GPP has us stuff into these messages > that carry the "real" identity of the user. > > It is not the UA's role to decide where a token would travel or not. In fact in some use cases the UA would never get access to any token at all. > Our job is to arrive at architectural commonality, and to reduce the > needless proliferation of identifiers in SIP requests. > > I am all for that; the question is how to achieve that. > This would allow us to achieve the SSO inside the trust domain, and > control the access to services inside and outside the trust domain. > > > I think achieving SSO inside a trust domain can be achieved with virtually > no new protocol work on our part. > Can you please elaborate on this? Keep in mind the use cases and the different types of endpoints and their limitations. Regards, Rifaat > It is understanding the need for anonymity here, and the precise > requirement for access control for SIP services, and how those are > entangled with the aforementioned SSO identifiers, that seems potentially > worth a dispatch. > > Jon Peterson > Neustar, Inc. > > --001a113ccd440eaa1b0532e17cb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, May 13, 2016 at 1:25 PM, Peterson, Jon <jon.peterson@ne= ustar.biz> wrote:

I guess that depends on how = you envision the solution to the various use cases would work. Let's ta= ke the conference server use case as an example:=C2=A0
In this case the user would = authenticate to the IdP locally, but that authenticated user identity does = not have to travel all the way to the conference server; all the conference= server should care about is that it received a token from a trusted entity for a specific domain to authori= ze access to its service; the identity of the user is not important to the = server providing the service.

I think we need to distinguish cases where the conference serve= r doesn't care about the user identity from cases where, for various re= ason, the identity of the user must be withheld from the conference server.=

Can you please elaborate on t= his?=C2=A0
Can you provide an example?

= =C2=A0
Ult= imately, if relying parties are going to receive this token, whatever it is, and then query an authorization server= for more specific instructions, then it matters whether the user identity = can serve as a key for that query, or whether it must not serve as a key fo= r that query to achieve some security or policy aim. This is the distinction I was trying to inject into this di= scussion.

I think that th= e registrar should not be part of the authenticatio= n process at all, and it should never get access to the shared secret. The = whole idea is to delegate the authentication process to the IdP.=C2=A0
The user should authenticate= to the IdP, get a token(s) (or a code) and use that to register with the r= egistrar.

That is what I assumed you meant; I just wanted to make sure th= at the description of "credential" here was crisp enough for us t= o use.


Ok. I will cla= rify the text.

=C2=A0


Part of my disconnect here is that I think most traditional SSO-style = use cases don't require B, they just require A. This makes me think the= re must be something interesting about the attributes that will be shared h= ere such that an approach more like B is needed. Anonymization is an example of a requirement that gets us clo= ser to B. If we assume the existence of a "self-contained token" = that would tell the service everything it needs to know about whether it sh= ould authorize a request - what do we imagine that it might contain?


I think that we need two types of tokens; let's, for now, call the= m AuthN Token and AuthZ Token. (we need more that two, but this is good enough for now= ).

Statements of that form make me very wary. I can imagine that t= here would be two ways to do this, one where we have the identity of the us= er serve as a key and one where we don't. When you suggest we need a pl= urality of tokens, you're setting us up for a world of complexity and non-interoperability.


There are few = advantages to the idea of creating separate tokens for AuthN and AuthZ:
1. Allows separate independent entities to provide these functionali= ties, with some established trust between them.
2. Allows staged = adoption of the new recommendation; you could start with delegation of auth= entication, and at a later stage delegate the authorization.

=
=C2=A0
AuthN Token represents the user identity, while the AuthZ Token repres= ents the services the user is authorized to access.

The AuthN Token could be used inside the trusted domain but is not req= uired to leave that trust domain in the user-to-server use cases.
The AuthZ Token is the token that will be allowed to leave the trust d= omain and be consumed by the server providing the service.

As a scope decision, that seems pretty arbitrary. Again, as I s= aid previously, I have a hard time imagining why we would want to specify a= n AuthN mechanism that works inside the trusted domain but will require som= ething else if it leaves the trust domain. If a UA implementation can't anticipate whether or not a SIP request i= s going to terminate in the local trust domain (and ordinarily, how could i= t?), then it would always have to add both. In addition of course to the Fr= om header. And don't forge the PAI. And however many other things 3GPP has us stuff into these messages that c= arry the "real" identity of the user.


It is not the UA'= s role to decide where a token would travel or not. In fact in some use cas= es the UA would never get access to any token at all.

<= div>=C2=A0
Our job is to arrive at architectural commonality, and to reduce the n= eedless proliferation of identifiers in SIP requests.


I am all for t= hat; the question is how to achieve that.

=C2=A0
This would allow us to achieve the SSO inside the trust domain, and co= ntrol the access to services inside and outside the trust domain.

I think achieving SSO inside a trust domain can be achieved wit= h virtually no new protocol work on our part.

Can you please elaborate on this?
Keep in mind th= e use cases and the different types of endpoints and their limitations.

Regards,
=C2=A0Rifaat

<= div>
=C2=A0
It is understanding the need for anonymity here, and the pr= ecise requirement for access control for SIP services, and how those are en= tangled with the aforementioned SSO identifiers, that seems potentially worth a dispatc= h.

Jon Peterson
Neustar, Inc.

--001a113ccd440eaa1b0532e17cb7-- From nobody Wed May 18 10:29:30 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F67A12D5EC for ; Wed, 18 May 2016 10:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rU29TFVU1Rtx for ; Wed, 18 May 2016 10:29:28 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24EA12D5E6 for ; Wed, 18 May 2016 10:29:27 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4IHNJrg008665; Wed, 18 May 2016 13:29:23 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 22wxnvun3x-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 May 2016 13:29:23 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Wed, 18 May 2016 13:29:21 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogA== Date: Wed, 18 May 2016 17:29:21 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.126] Content-Type: multipart/alternative; boundary="_000_D361F10A18F366jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-18_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605180224 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:29:29 -0000 --_000_D361F10A18F366jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think we need to distinguish cases where the conference server doesn't ca= re about the user identity from cases where, for various reason, the identi= ty of the user must be withheld from the conference server. Can you please elaborate on this? Can you provide an example? Some identity federation architectures require that you conceal the user's = identity from a relying party while still sharing attributes about that use= r. For example, in a single sign-on system that allows users to access a st= reaming video game service, the IdP might want to share with the service an= attribute attesting that the user is over 18 (and can thus play "M" rated = games) but not share the user's name or other personally identifying inform= ation. In any attribute-sharing scheme, you're going to be sharing some token that= lets relying parties access attributes associated with the individual. In = cases where you can share the user's identity, often the identity is the be= st token. In cases where you can't, you need something else, something more= opaque. I think this is a fundamental distinction in the architecture and = pretty much the only reason not to use one of our existing ways of sharing = identity as the token issued by an IdP. Our job is to arrive at architectural commonality, and to reduce the needle= ss proliferation of identifiers in SIP requests. I am all for that; the question is how to achieve that. Well, actually, you said you wanted more than two ways to do this, so I did= n't get the sense from your prior statement that commonality was your prior= ity. It is mine. This would allow us to achieve the SSO inside the trust domain, and control= the access to services inside and outside the trust domain. I think achieving SSO inside a trust domain can be achieved with virtually = no new protocol work on our part. Can you please elaborate on this? Keep in mind the use cases and the different types of endpoints and their l= imitations. We already have ways to carry around an identity in SIP. Within one trust d= omain, you don't have the kinds of confidentiality requirements that I arti= culate above, so surely one of our existing ways of sharing identity would = suffice. It is only when the identity crosses administrative boundaries, in= situations closer to a federated identity architecture, that you start see= ing requirements to share only selected information. So I should be careful= when we talk about "trust domains," as these federated cases amount only t= o partial trust, but that was what I meant. Jon Peterson Neustar, Inc. --_000_D361F10A18F366jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <9094A6848A270C40A9994A57407CC738@neustar.biz> Content-Transfer-Encoding: quoted-printable


I think we need to distinguish cases where the conference server doesn= 't care about the user identity from cases where, for various reason, the i= dentity of the user must be withheld from the conference server.

Can you please elaborate on this? 
Can you provide an example?

Some identity federation architectures require that you conceal the us= er's identity from a relying party while still sharing attributes about tha= t user. For example, in a single sign-on system that allows users to access= a streaming video game service, the IdP might want to share with the service an attribute attesting that t= he user is over 18 (and can thus play "M" rated games) but not sh= are the user's name or other personally identifying information.

In any attribute-sharing scheme, you're going to be sharing some token= that lets relying parties access attributes associated with the individual= . In cases where you can share the user's identity, often the identity is t= he best token. In cases where you can't, you need something else, something more opaque. I think this is a f= undamental distinction in the architecture and pretty much the only reason = not to use one of our existing ways of sharing identity as the token issued= by an IdP.

 
Our job is to arrive at architectural commonality, and to reduce the n= eedless proliferation of identifiers in SIP requests.


I am all for that; the question is how to achieve that.

Well, actually, you said you wanted more than two ways to do this, so = I didn't get the sense from your prior statement that commonality was your = priority. It is mine.


This would allow us to achieve the SSO inside the trust domain, and co= ntrol the access to services inside and outside the trust domain.

I think achieving SSO inside a trust domain can be achieved with virtu= ally no new protocol work on our part.

Can you please elaborate on this?
Keep in mind the use cases and the different types of endpoints and th= eir limitations.

We already have ways to carry around an identity in SIP. Within one tr= ust domain, you don't have the kinds of confidentiality requirements that I= articulate above, so surely one of our existing ways of sharing identity w= ould suffice. It is only when the identity crosses administrative boundaries, in situations closer to a fede= rated identity architecture, that you start seeing requirements to share on= ly selected information. So I should be careful when we talk about "tr= ust domains," as these federated cases amount only to partial trust, but that was what I meant.

Jon Peterson
Neustar, Inc.


 --_000_D361F10A18F366jonpetersonneustarbiz_-- From nobody Wed May 18 12:15:31 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DD812D64B for ; Wed, 18 May 2016 12:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-kKsxDTqb-0 for ; Wed, 18 May 2016 12:15:28 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BDD8128B44 for ; Wed, 18 May 2016 12:15:28 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by comcast with SMTP id 36tpbmoVjbFYY36wJbE2Br; Wed, 18 May 2016 19:15:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1463598927; bh=bLincqJJ11BMYj6PYMk4aU22zE/n+mbDq2tNkgjpzro=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=whL1qjtaugNnZ1Gd/6xozwmCvWlhBh+SBi515SeYaOLlitf1iQzP5w36Qh3bCoCRm BL/WcynmJnRGw7VqS53OqoeFP9PjQh05Ob1BWztsuCZU4P6SaEfNc5ltZYuV+eOCgY +xWYHcRdwwtCWPNIZoFLtz49LFIORrv768YWFvKNXXaoY09kQHBNnSGCpp2hqhT3f7 hzAf9Al1ErETvTb4AekFcygY1fErAqxwHXrJUB+LlGLhkQgw9lXQebktbAzOSTge2O mrMuocmpbnGoc+qa9sQstN4WbMP3g+j9dRRG7ur7agEFeS93CP9q/Jyef1P/LkdzYV R8LXj9dCTNd0w== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-11v.sys.comcast.net with comcast id vvFS1s00f1nMCLR01vFTh1; Wed, 18 May 2016 19:15:27 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u4IJFQW8030019 for ; Wed, 18 May 2016 15:15:26 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u4IJFQQT030016; Wed, 18 May 2016 15:15:26 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 18 May 2016 15:15:25 -0400 Message-ID: <87posjrxde.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] Remaining Happy Eyeballs work, the simple parts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 19:15:30 -0000 Now that draft-ietf-sipcore-dns-dual-stack is going to the IESG: To recast what I see as the agenda for the remaining "Happy Eyeballs" work, this is a list of what I see as the simple issues. My goal here is to get feedback on what the specifics of this part of the solution should be so we can start producing text. (The terms "flow" and "target" might not be the right vocabulary.) - Recommend SIP Outbound (RFC 5626) between UAs and edge proxies [everybody agrees that using SIP Outbound is the best solution in principle] - Allow devices to change the target order prescribed by RFC 3263/2782 using the Happy Eyeballs rules: - Prefer targets with existing flows - Prefer targets with a different address family than that of a non-responsive address - Deprecate targets known to be non-responsive - May simultaneously initiate flows with multiple targets as long as UA does not have more than one simultaneous outstanding copy of a request - Prefer simultaneously initiating flows with targets in different address families - Reduce client transaction timeouts: Timer B and Timer F are currently 64*T1, which defaults to 32 seconds I will summarize the vexed question of dealing with "simple" UDP (where "simple" means "not using the full facilities of SIP Outbound") in another message. ---------- The matter of the timers needs to be worked on. Right now, both INVITE and non-INVITE transactions use much the same structure: T1 is an estimate of the network RTT, and defaults to 500ms. Timer B/C is 64*T1, thus defaulting to 32s. When an INVITE request is sent, if there is no response within T1, then it is resent. Continuing lack of a response causes resends at doubling intervals, leading to transmissions at times: T0 + 0 T0 + T1 T0 + 3*T1 T0 + 7*T1 T0 + 15*T1 T0 + 31*T1 T0 + 63*T1 timeout at T0 + 64*T1 (7 transmissions in all) For non-INVITE requests and INVITE responses, the retransmit timer has a maximum of T2, which is 4s (= 8*T1), giving transmission times: T0 + 0 T0 + T1 T0 + 3*T1 T0 + 7*T1 T0 + 15*T1 T0 + 23*T1 T0 + 31*T1 T0 + 39*T1 T0 + 47*T1 T0 + 55*T1 T0 + 63*T1 timeout at T0 + 64*T1 (11 transmissions in all) It seems to me that we should reduce the total time until failure is declared to something like 5 seconds, on the grounds that people will not give up on a call if it takes an extra 5 seconds to start ringing. If we reduce T1 to 100ms, then Timer B/C becomes 6.4 seconds. It seems to me that 100ms as the default RTT is quite acceptable, and maybe an overestimate. I just ran 'ping' against the web sites in the open tabs in my web browser, and all of them had RTT of less than 50ms. Setting T1 to 50ms would reduce Timer B/C to 3.4 seconds. In addition, if we consider UDP networks to be relatively reliable, we could reduce the number of retransmissions. For instance, if the network loses a random 30% of packets, the probability of 4 retransmissions of a request being lost is only 0.81%. As an extreme proposal, if we reduce T1 to 50ms and Timer B/C to 16*T1 (allowing five transmissions), Timer B/C becomes 0.32 seconds. I think the largest risk from reducing retransmissions or sending them more densely is when networks have short-term congestion, so that the network essentially fails for times on the order of a few seconds. Dale From nobody Wed May 18 12:52:32 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D039E12D682 for ; Wed, 18 May 2016 12:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XgF24I6jPBI for ; Wed, 18 May 2016 12:52:30 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1516C12D67D for ; Wed, 18 May 2016 12:52:29 -0700 (PDT) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by comcast with SMTP id 37UNbSySkYPZX37W9bFxtj; Wed, 18 May 2016 19:52:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1463601149; bh=MCJa0+wfweKpMHOX2yC837VSzjEJKVmK2c1P3a7cVjc=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=H696miwKwZ5nmdD6WSdu/K6hxFQka/4EXQJuEwQFi6bMQlD5+zo3TRl7s83xpQJKZ 4Ted4GTIdCNCinIHUeQ02ljehq9wwJNvhq3I3/5Mj1UTIEmmOgy9ONP6duB152W2mC Yj/07JeuBOj+4PMHKphdlbIayNEkx/kkmVTJxTOtwU5g7VKfJRmFyWQH0KoYb8mrav J6XDGmdjZ853Mt2M4ZsetmlE83lz26ajAPJd9rZnoXcNzKLRrYYtf3u+l4pD7LJ6Yc XRQPX/LyKtcD66O9reP3b7TGJ5FYxY4rbkE+yGFnnV7tYB0U4jra4mbiMhOXc/fsVl QR0SpHI2WkzLg== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-12v.sys.comcast.net with comcast id vvsU1s00W1nMCLR01vsVU5; Wed, 18 May 2016 19:52:29 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u4IJqShE031991 for ; Wed, 18 May 2016 15:52:28 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u4IJqRqO031988; Wed, 18 May 2016 15:52:27 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 18 May 2016 15:52:27 -0400 Message-ID: <87h9dvrvno.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] Remaining Happy Eyeballs work, the hard part X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 19:52:31 -0000 A solution is needed for simple UDP, where "simple" means "without a full implementation of SIP Outbound". There are a number of decidedly different ways that this need might be satisfied. The ones that I can think of are: - documenting a suitable subset of SIP Outbound (if one exists) It's possible that the SIP Forum is already doing this in practice. If so, that would overcome the problem that Output implementations are not ubiquitous. - a lightweight SIP/DTLS (the cryptographic setup creates a flow) - the registration message flow from the UA is sufficient to keep the cached reachability information up to date This is really "client-side NAT compensation", where the SIP registrar records the NAT-external address of the UA rather than its interface address. It seems like a lot of SIP systems do this, which means that it works well in practice. (Is it possible/reasonable to specify this process? Is that any simpler than specifying Outbound?) - a mechanism to send simultaneous redundant requests to multiple addresses without causing problems with merged requests This is largely agreed to be too large an extension for this work. This is just a summary of where we are on this issue, as there has been discussion pointing to possible solutions and the relationship with other work (especially SIPConnect 2.0), but I don't have the time right now to incorporate everything we've discussed into this list. Dale From nobody Thu May 19 12:55:47 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD44112DC14 for ; Thu, 19 May 2016 12:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQJ1n_ygHPLt for ; Thu, 19 May 2016 12:55:46 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DB4E12D646 for ; Thu, 19 May 2016 12:55:40 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by comcast with SMTP id 3U0abpqnJBE6O3U2lbuQJG; Thu, 19 May 2016 19:55:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1463687739; bh=sbEqHhWxp/i3ABSwoo5SyCM6EAfOjbnib2VJBkOAbTY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=kcGeeYASzfYlmsWE6WrWklXi5Aax4WJaCumHVXC+2YuPmnlAniOcZGVNpwNdXII8+ lAT94cG9upoZFcDNfjWrdzCExjI60VL+YLZYMdTjiChtAWkA/26mNl1P5jQREmtj8s OFdojP5HeDM6KI9QJhN0uqbhDoUvny+hHssWL+l6wmR/zSQd+014wM1btl5/R6Ml9L y6jXvpVZwS7BQIX9yVS1BUCrY6IAT3FUkbt+8nbjCSBR0N4kMBzFRw5U4R+RAOSIvG h1mkrnC/aI3BHaq+EcTKbJ8bXPnvb9M/0TUuz2z/fTs2jQVTK+UP1+BGbpE6Hk95Jo CZ7H7MKeU/ryQ== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-18v.sys.comcast.net with comcast id wKvf1s0053KdFy101Kvftn; Thu, 19 May 2016 19:55:39 +0000 To: sipcore@ietf.org References: <87h9dvrvno.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <54bb77ff-0819-0aa9-e70f-d525784c18e9@alum.mit.edu> Date: Thu, 19 May 2016 15:55:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <87h9dvrvno.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Remaining Happy Eyeballs work, the hard part X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 19:55:47 -0000 On 5/18/16 3:52 PM, Dale R. Worley wrote: > A solution is needed for simple UDP, where "simple" means "without a > full implementation of SIP Outbound". > > There are a number of decidedly different ways that this need might be > satisfied. The ones that I can think of are: > > - documenting a suitable subset of SIP Outbound (if one exists) I was thinking this was brought up because outbound wasn't defined for a single connection. But then I looked and think that it is. So what is needed here? > It's possible that the SIP Forum is already doing this in practice. If > so, that would overcome the problem that Output implementations are not > ubiquitous. > > - a lightweight SIP/DTLS (the cryptographic setup creates a flow) ISTM this would be a good think on general principles, and if it helps with happy eyeballs then all the better. Of course DTLS decreases the max sip message size before fragmentation, hence limiting further when it will be useful. Those who have carefully optimized to fit within UDP might find that they don't fit with DTLS. The key is if there is interest in supporting this work. (Both a spec, and implementations of it.) Thanks, Paul > - the registration message flow from the UA is sufficient to keep the > cached reachability information up to date > > This is really "client-side NAT compensation", where the SIP registrar > records the NAT-external address of the UA rather than its interface > address. It seems like a lot of SIP systems do this, which means that > it works well in practice. (Is it possible/reasonable to specify this > process? Is that any simpler than specifying Outbound?) > > - a mechanism to send simultaneous redundant requests to multiple > addresses without causing problems with merged requests > > This is largely agreed to be too large an extension for this work. > > This is just a summary of where we are on this issue, as there has been > discussion pointing to possible solutions and the relationship with > other work (especially SIPConnect 2.0), but I don't have the time right > now to incorporate everything we've discussed into this list. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Fri May 20 15:30:00 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4453512D633 for ; Fri, 20 May 2016 15:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQifrzAnA18j for ; Fri, 20 May 2016 15:29:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573CA12D584 for ; Fri, 20 May 2016 15:29:58 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4KMTqiR006180 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 20 May 2016 17:29:54 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "Dale R. Worley" , sipcore@ietf.org References: <874mcobp0s.fsf@hobgoblin.ariadne.com> From: Adam Roach Message-ID: <8b719b37-30ff-7b9b-bf6e-f9895204c87c@nostrum.com> Date: Fri, 20 May 2016 17:29:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <874mcobp0s.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Happy Eyeballs -- UDP and RTT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 22:29:59 -0000 On 3/2/16 14:31, Dale R. Worley wrote: > Using TLS in a new connection adds a further RTT to TCP transmission times. As an aside, as long as the data isn't sensitive to replay attacks, TLS 1.3's 0-RTT data may help us here (assuming the host has been contacted before, which will be true most of the time in most SIP deployments). I'd have to double-check the status and properties of 0-RTT data to be sure that it's suitable, but I suspect it is. The point is that we may be finding relief here: by combining fast open and 0-RTT, I think we can get TCP/TLS SIP messages to the first hop as quickly as we can with UDP. /a From nobody Fri May 20 16:21:43 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A4812D523 for ; Fri, 20 May 2016 16:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DDHDuJFe3y6 for ; Fri, 20 May 2016 16:21:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB1012D1C0 for ; Fri, 20 May 2016 16:21:40 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4KNLbPp010185 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 20 May 2016 18:21:39 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "Dale R. Worley" , sipcore@ietf.org References: <87y49i9v9c.fsf@hobgoblin.ariadne.com> From: Adam Roach Message-ID: <662d1694-0902-7d5a-c45e-b9eb1058a249@nostrum.com> Date: Fri, 20 May 2016 18:21:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <87y49i9v9c.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] "Roman's problem" X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 23:21:41 -0000 On 3/16/16 12:40, Dale R. Worley wrote: > NAT traversal is handled by NAT compensation done by the edge proxy > rather than ICE (thus keeping messages small enough for UDP). FWIW, I expect the SIPBRANDY effort to change this. /a From nobody Fri May 20 16:52:12 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0411F12D5D2 for ; Fri, 20 May 2016 16:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9VvpqN8897e for ; Fri, 20 May 2016 16:52:08 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95ED012D0DA for ; Fri, 20 May 2016 16:52:08 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id b65so58467153oia.1 for ; Fri, 20 May 2016 16:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tjHdU8yc0lFCAWWqqUp9ve3/9XEuYkcmYxvOwJQODSI=; b=A+1IdSgIB3r6Su6KSMFbftVQgG3rksvy9Y6ZjhDwMaUnvPYVfrau0FxZYYQVQQuo6I FPoTtvqHyjEolfID7kw6ViEJszW9xuR6+eAHbog1ONoAe9vGZR2gJciPBrQy6D1XTKFV urZd1GSpbc12kWdHLoGxBl4g3ndnrkqm8vYke1uxkebbXtyF3w7gNRSLn5ALGFVFcg5R It+EvBdjrH+NAZnH51dJSjXHPasEUSEFsyG3Ac9sOB05k2oyagJdPM63u7OnEbtt3QDl Z7nwOQ66oYj6AOi2FB5wDMC86pMG7t3AMw4ZIbA3ikyBz5OECSWWyuV00iE9zrOWxWu3 Zmqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tjHdU8yc0lFCAWWqqUp9ve3/9XEuYkcmYxvOwJQODSI=; b=NzwDU9K+key4vZYlI77iCDZB0bZ3wQ/nHuaT5YcPrgSFURQ6LU8lnrIQTSC9vbonwA DS0vmbJkMUsuHJGqZrBLqN11h4fR58hEDAlwu8GolZNxcJrzchh1pELZh0eGXwrIFee1 V2tLqcUsU0OpONAhF1LJi0jgqC+rBPY165sBe4CnwZwC5s9R4i+YoULlNUt/orhlzdEH Hul3zbIdk3F4B7P/a3369+tE+WVgJTh3FQDvDuljtELS96AsUJcN9IAwKdt8/URWLNR+ J72T463enQS31cB6oez7QyRHC4BjpBqTJoHTyTXeQDNAJFIx1UXD1vIW041kqNcW5QnS Ohag== X-Gm-Message-State: AOPr4FU2cznqeflhP2BZyjE5BmTa+Aob6Uqwab8YCFkco0Bt7ylEL+9OMOIzJTdAoNnI6w== X-Received: by 10.202.102.202 with SMTP id m71mr3645417oik.79.1463788327964; Fri, 20 May 2016 16:52:07 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com. [209.85.213.181]) by smtp.gmail.com with ESMTPSA id e31sm1864521ote.34.2016.05.20.16.52.07 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 May 2016 16:52:07 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id bi2so2158750igb.0 for ; Fri, 20 May 2016 16:52:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.37.147 with SMTP id y19mr5019338igj.42.1463788326907; Fri, 20 May 2016 16:52:06 -0700 (PDT) Received: by 10.36.144.69 with HTTP; Fri, 20 May 2016 16:52:06 -0700 (PDT) In-Reply-To: <8b719b37-30ff-7b9b-bf6e-f9895204c87c@nostrum.com> References: <874mcobp0s.fsf@hobgoblin.ariadne.com> <8b719b37-30ff-7b9b-bf6e-f9895204c87c@nostrum.com> Date: Fri, 20 May 2016 19:52:06 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Adam Roach Content-Type: multipart/alternative; boundary=f46d0444006e408e3505334ec7d9 Archived-At: Cc: "Dale R. Worley" , sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs -- UDP and RTT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 23:52:10 -0000 --f46d0444006e408e3505334ec7d9 Content-Type: text/plain; charset=UTF-8 On Fri, May 20, 2016 at 6:29 PM, Adam Roach wrote: > On 3/2/16 14:31, Dale R. Worley wrote: > >> Using TLS in a new connection adds a further RTT to TCP transmission >> times. >> > > > As an aside, as long as the data isn't sensitive to replay attacks, TLS > 1.3's 0-RTT data may help us here (assuming the host has been contacted > before, which will be true most of the time in most SIP deployments). I'd > have to double-check the status and properties of 0-RTT data to be sure > that it's suitable, but I suspect it is. The point is that we may be > finding relief here: by combining fast open and 0-RTT, I think we can get > TCP/TLS SIP messages to the first hop as quickly as we can with UDP. There is still a big architectural difference between UDP and TLS based call flows. For TLS (TCP) based call flow, the flow needs to be established by the client for any client behind NAT. If Edge Proxy fails, new Edge Proxy cannot easily recover the flow, even if it takes over the IP address. Client needs to detect the flow failure using keep alive and then re-establish flow to a new Edge Proxy. With default keep alive timers for TLS, average failure detection time is 60 seconds. Which means server originated transactions, such as SIP Session timers will have a high chance of timing out and call failing. With UDP, new Edge Proxy, if it recovers IP address, it can immediately send SIP messages to the client behind NAT. Most of the times Edge Proxy can be designed to be completely stateless, with all the information necessary to forward the message stored in Route headers, so proxy fail over implementation is trivial. Finally, with current SIPS design, keep alive are sent over an encrypted channel, which is a waste of resources and created an unnecessary load on the Edge Proxies. Regards, _____________ Roman Shpount --f46d0444006e408e3505334ec7d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, May 20, 2016 at 6:29 PM, Adam Roach <adam@nostrum.com><= /span> wrote:
= On 3/2/16 14:31, Dale R. Worley wrote:
Using TLS in a new connection adds a further RTT to TCP transmission times.=


As an aside, as long as the data isn't sensitive to replay attacks, TLS= 1.3's 0-RTT data may help us here (assuming the host has been contacte= d before, which will be true most of the time in most SIP deployments). I&#= 39;d have to double-check the status and properties of 0-RTT data to be sur= e that it's suitable, but I suspect it is. The point is that we may be = finding relief here: by combining fast open and 0-RTT, I think we can get T= CP/TLS SIP messages to the first hop as quickly as we can with UDP.

There is still a big architectural difference betw= een UDP and TLS based call flows. For TLS (TCP) based call flow, the flow n= eeds to be established by the client for any client behind NAT. If Edge Pro= xy fails, new Edge Proxy cannot easily recover the flow, even if it takes o= ver the IP address. Client needs to detect the flow failure using keep aliv= e and then re-establish flow to a new Edge Proxy. With default keep alive t= imers for TLS, average failure detection time is 60 seconds. Which means se= rver originated transactions, such as SIP Session timers will have a high c= hance of timing out and call failing.

With UDP, ne= w Edge Proxy, if it recovers IP address, it can immediately send SIP messag= es to the client behind NAT. Most of the times Edge Proxy can be designed t= o be completely stateless, with all the information necessary to forward th= e message stored in Route headers, so proxy fail over implementation is tri= vial.

Finally, with current SIPS design, keep aliv= e are sent over an encrypted channel, which is a waste of resources and cre= ated an unnecessary load on the Edge Proxies.=C2=A0

Regards,
_____________
Roman = Shpount
=C2=A0
--f46d0444006e408e3505334ec7d9-- From nobody Mon May 23 05:04:06 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB83712D73E for ; Mon, 23 May 2016 05:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLerHtjDMxNQ for ; Mon, 23 May 2016 05:04:02 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBEC12D6FD for ; Mon, 23 May 2016 05:03:56 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id c189so219436722vkb.1 for ; Mon, 23 May 2016 05:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jHyTqjeeMck6Bl+AWUOvERBchKsKA0hD5b7Z+jrTay4=; b=s2XuRUAv5WJULd2v7YD44bkIn6JHtobwlY7K/LuV4IMSTVENnXLr9ZeYmxLg3MaurH kAQ3ajMQXgG8rSTGBIsVE0OLMh3BDipfc+hUXUedojiBCSdbhfidqJYK9BwZg6iJy02M zKsDBD8OBHTbXI7/VaMV+WWeW5XtlRBpe5I31211M9maVmpKHgfNpQ64cEuTzMODaGvf fpLSN/VSYQcg7tBkTWy3O40hrJuVBDilHMRvrtkfgDFdbPaA+fgj96OQqA7M7R3gOjIy 5q7k8c11o5XqZ4146pA2wKTB9gs5/V/BIPRGjxcir4ETWaSLPeMaeFkpXR6aQbA6THg/ d4Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jHyTqjeeMck6Bl+AWUOvERBchKsKA0hD5b7Z+jrTay4=; b=TBf8Vc4q0uTtUFTcgGisTrsUtBQRzc7cWXNdv3o+NlURlR63kc1yuXl8aisLS7FCfv o9FU4z23m7i7UMVPUqN210tjF44OBvVt/9Uyk/oiIQSNgXM1qv3lhmOlh1UywBKm4Rzz pJDtDoRmXpBYulsU3xD8U4daEBL5+ssj2UF9JeG8EGctjzqWLm/6K0P5XjPVNuoBsAHE +WQhPSpByTjUN4oUYDsHRYAefpqtDBEFAuF4ldPhhJbx6GZdFeqGV0fVPps6HZ6PInZa imQi6Pd3M4fjtjUoIT4CWP/SGZmaO4s0Mr7dKKiF6lTOic5UsErHwebrKdB1NFOF7Jo2 F9IA== X-Gm-Message-State: AOPr4FUgCWvPDpaH8lEruq3OXilHOyNtFhdyrO0wz2DAuWYIqtAYKRYGEuZkewAQXmUz4p8Uc+Whqb0s04qD2A== MIME-Version: 1.0 X-Received: by 10.31.166.72 with SMTP id p69mr9700843vke.14.1464005035278; Mon, 23 May 2016 05:03:55 -0700 (PDT) Received: by 10.176.64.231 with HTTP; Mon, 23 May 2016 05:03:55 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> Date: Mon, 23 May 2016 08:03:55 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=001a1142d22213cc260533813cd6 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 12:04:04 -0000 --001a1142d22213cc260533813cd6 Content-Type: text/plain; charset=UTF-8 On Wed, May 18, 2016 at 1:29 PM, Peterson, Jon wrote: > > >> I think we need to distinguish cases where the conference server doesn't >> care about the user identity from cases where, for various reason, the >> identity of the user must be withheld from the conference server. >> > > Can you please elaborate on this? > Can you provide an example? > > > Some identity federation architectures require that you conceal the user's > identity from a relying party while still sharing attributes about that > user. For example, in a single sign-on system that allows users to access a > streaming video game service, the IdP might want to share with the service > an attribute attesting that the user is over 18 (and can thus play "M" > rated games) but not share the user's name or other personally identifying > information. > > In any attribute-sharing scheme, you're going to be sharing some token > that lets relying parties access attributes associated with the individual. > In cases where you can share the user's identity, often the identity is the > best token. In cases where you can't, you need something else, something > more opaque. I think this is a fundamental distinction in the architecture > and pretty much the only reason not to use one of our existing ways of > sharing identity as the token issued by an IdP. > > Yet another reason to separate AuthN and AuthZ tokens. > > >> Our job is to arrive at architectural commonality, and to reduce the >> needless proliferation of identifiers in SIP requests. >> >> > I am all for that; the question is how to achieve that. > > > Well, actually, you said you wanted more than two ways to do this, so I > didn't get the sense from your prior statement that commonality was your > priority. It is mine. > > Sure :) I did not mean to imply that it is a *priority *for me. But I am definitely willing and interested in discussing the idea to see if we can come up with a way to do that, hence this whole exercise; but I am not seeing it yet, and I was hoping that you could help me see it, assuming that there is indeed a way to do that. > > This would allow us to achieve the SSO inside the trust domain, and >> control the access to services inside and outside the trust domain. >> >> >> I think achieving SSO inside a trust domain can be achieved with >> virtually no new protocol work on our part. >> > > Can you please elaborate on this? > Keep in mind the use cases and the different types of endpoints and their > limitations. > > > We already have ways to carry around an identity in SIP. Within one trust > domain, you don't have the kinds of confidentiality requirements that I > articulate above, so surely one of our existing ways of sharing identity > would suffice. It is only when the identity crosses administrative > boundaries, in situations closer to a federated identity architecture, that > you start seeing requirements to share only selected information. So I > should be careful when we talk about "trust domains," as these federated > cases amount only to partial trust, but that was what I meant. > > I guess it depends on your definition of *identity*; if it is the name and the AOR of the user, then you are correct that we have ways to carry this information in SIP today. But *identity* could include many other attributes like: address, age, contact info, etc; in this case SIP does not have away to carry all that info which could be included in a token. Also, if we decided to separate the AuthN and AuthZ, then we might need to carry more than one token. Another issues in the need, in some cases, to avoid sending the token to the UA; in this case there is a need for an interim step to get the token(s) to the SIP proxy. I do not know how you could achieve all of that " with virtually no new protocol work on our part". Regards, Rifaat > Jon Peterson > Neustar, Inc. > > > --001a1142d22213cc260533813cd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 18, 2016 at 1:29 PM, Peterson, Jon <jon.peterson@ne= ustar.biz> wrote:
I think we need to distinguish cases where the conference server doesn= 't care about the user identity from cases where, for various reason, t= he identity of the user must be withheld from the conference server.

Can you please elaborate on this?=C2=A0
Can you provide an example?

Some identity federation architectures require that you conceal= the user's identity from a relying party while still sharing attribute= s about that user. For example, in a single sign-on system that allows user= s to access a streaming video game service, the IdP might want to share with the service an attribute attesting that t= he user is over 18 (and can thus play "M" rated games) but not sh= are the user's name or other personally identifying information.

In any attribute-sharing scheme, you're going to be sharing some t= oken that lets relying parties access attributes associated with the indivi= dual. In cases where you can share the user's identity, often the ident= ity is the best token. In cases where you can't, you need something else, something more opaque. I think this is= a fundamental distinction in the architecture and pretty much the only rea= son not to use one of our existing ways of sharing identity as the token is= sued by an IdP.


Yet another re= ason to separate AuthN and AuthZ tokens.
=C2=A0
=C2=A0
Our job is to arrive at architectural commonality, and to reduce the n= eedless proliferation of identifiers in SIP requests.


I am all for that; the question is how to achieve that.

Well, actually, you said you wanted more than two ways to do th= is, so I didn't get the sense from your prior statement that commonalit= y was your priority. It is mine.


Sure :)
<= div>
I did not mean to imply that it is a priority for= me.
But I am definitely willing and interested in discussing the= idea to see if we can come up with a way to do that, hence this whole exer= cise; but I am not seeing it yet, and I was hoping that you could help me s= ee it, assuming that there is indeed a way to do that.

=
=C2=A0

This would allow us to achieve the SSO inside the trust domain, and co= ntrol the access to services inside and outside the trust domain.

I think achieving SSO inside a trust domain can be achieved with virtu= ally no new protocol work on our part.

Can you please elaborate on this?
Keep in mind the use cases and the different types of endpoints and th= eir limitations.

We already have ways to carry around an identity in SIP. Within= one trust domain, you don't have the kinds of confidentiality requirem= ents that I articulate above, so surely one of our existing ways of sharing= identity would suffice. It is only when the identity crosses administrative boundaries, in situations closer to a fede= rated identity architecture, that you start seeing requirements to share on= ly selected information. So I should be careful when we talk about "tr= ust domains," as these federated cases amount only to partial trust, but that was what I meant.


I guess= it depends on your definition of identity; if it is the name and th= e AOR of the user, then you are correct that we have ways to carry this inf= ormation in SIP today.
But identity could include many oth= er attributes like: address, age, contact info, etc; in this case SIP does = not have away to carry all that info which could be included in a token.

Also, if we decided to separate the AuthN and AuthZ,= then we might need to carry more than one token.
Another issues = in the need, in some cases, to avoid sending the token to the UA; in this c= ase there is a need for an interim step to get the token(s) to the SIP prox= y.

I do not know how you could achieve all of that= "=C2=A0with virtually no new protocol work on our part= ".

Regards,
=C2=A0Rifaat=

=C2=A0
Jon Peterson
Neustar, Inc.

--001a1142d22213cc260533813cd6-- From nobody Mon May 23 08:48:15 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866DE12D998 for ; Mon, 23 May 2016 08:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVXdHELVb4SQ for ; Mon, 23 May 2016 08:48:13 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A78E712D975 for ; Mon, 23 May 2016 08:48:12 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by comcast with SMTP id 4s0PbSBNH8DPn4s5TbVGwg; Mon, 23 May 2016 15:48:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464018491; bh=jruMbulY1WxBS4SDFOzc/03h+5drYOuOWrgmA5F2+dU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Baf4/DZHf5SbRrwqrNJS0+eIQhqW18L2fHY2gnQMYlKA2Q49ze9/4kLtRKzGSCOq6 l94ipt9zMMhoe4svjr9tOC5yMBlH5ZSIB86Ks+RJcblWKuvX6Wywuq1qTAfbqVlXac usFiKFxs5tyzvGUhK1LGTHjw0Od8FvV4rHUYWKqQciaMsxbMhVkwZd4mvFnI7VbK7z 5iuSRwRRLXTe4LmQWYoJwcbEnVPEn6W4C/oK6qit2Ku60p9e3lTQ5rF8MCmdyz0GZR JZHhNdYspfPOUnYJETAA8lOMTAMPQVC3gB8EfpoVXBx8M75ZiBcn/ijhAQ0cuc5wgB oKEQ9GHupnOTA== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id xroB1s00F3KdFy101roB4a; Mon, 23 May 2016 15:48:11 +0000 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Mon, 23 May 2016 11:47:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 15:48:14 -0000 On 5/23/16 8:03 AM, Rifaat Shekh-Yusef wrote: > We already have ways to carry around an identity in SIP. Within one > trust domain, you don't have the kinds of confidentiality > requirements that I articulate above, so surely one of our existing > ways of sharing identity would suffice. It is only when the identity > crosses administrative boundaries, in situations closer to a > federated identity architecture, that you start seeing requirements > to share only selected information. So I should be careful when we > talk about "trust domains," as these federated cases amount only to > partial trust, but that was what I meant. > > I guess it depends on your definition of *identity*; if it is the name > and the AOR of the user, then you are correct that we have ways to carry > this information in SIP today. > But *identity* could include many other attributes like: address, age, > contact info, etc; in this case SIP does not have away to carry all that > info which could be included in a token. That mixes up *identity* from properties/attributes of the identified entity. Even the name (display name) is a property. It typically isn't an identity because it isn't unique. Thanks, Paul From nobody Mon May 23 09:12:21 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E76912D9C6 for ; Mon, 23 May 2016 09:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pr_4gu-ZCWe for ; Mon, 23 May 2016 09:12:14 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878F612D9C8 for ; Mon, 23 May 2016 09:12:13 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id c189so229236663vkb.1 for ; Mon, 23 May 2016 09:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PGUnv+/KXT0vRS2TnoyUSrBl5ZGbyajD2YoM9t0l7DU=; b=W2uoDNBFszsFAYAcx+qSp0MKsv8RjrAiUPRE92aO6UcYWlot5mI7qsUmdokdMiMssk AOsw0Fn1q/FteV/pxsWMXjMZfF6m8YWhVnM+FAXHoG4k4evmzw458BBT3IOBzuxOIVVZ foN4qrbU5Ph2kztnNaoc9xrKkZZEIdsgZVKA3z7G9KXYOVR408Exf7TVMNvAJBe07reB NvKS2jsV5oyfTJ/kjKPy8mCanH1pPislal7pMCYZC/o7fHRSN5s7oo4K2YguJZP2YWi7 onIv6xE8VYdVUGN1t+WiS6huKNXpGICTGFjcT4Z6ATN9sf+jQS/qmDJGPQnzNvyLjQKI q98g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PGUnv+/KXT0vRS2TnoyUSrBl5ZGbyajD2YoM9t0l7DU=; b=hsEQgBo7vBbwZQ9NC0sh14wh7Aqy79zu6zmgQTRnxl3Oycx8CjT3/5tDENcrhsoVn4 x0XJCWpGaDGb78LkjWHRbvEO2sPuJsqA0P2bjcBWy5SCetTvoInkoqgcAAsYUpDkPbsC XvscK5caK915CxU6cpvXDAXbag1tSj2nlhTjpM4xgwtHYOc4uqaoGpG/jPeW2Fn8Bzah zYCfAIdDCwYgIrCtgOw29KP06Sx0b3QFl2rkDJtgJd65/eqAjNvnykBtBPNes9TPpU9+ zldigXL3hrG9X7SA9ZUKtfhyuG7ZuBP4UTUmEzFEFCnKyKwUl3qKelVTE/hZXY+nofMY KNzA== X-Gm-Message-State: AOPr4FUKPEqOtYWNBsvW7K725RsbFUUZTx+5dMZm4LlWvVhXm7W5Cgm8KO8727PhvtIl9iPC3xe1rJ77X7JS4w== MIME-Version: 1.0 X-Received: by 10.176.69.201 with SMTP id u67mr10002594uau.131.1464019932597; Mon, 23 May 2016 09:12:12 -0700 (PDT) Received: by 10.176.64.231 with HTTP; Mon, 23 May 2016 09:12:12 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> Date: Mon, 23 May 2016 12:12:12 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=94eb2c11c00806d44c053384b4be Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 16:12:19 -0000 --94eb2c11c00806d44c053384b4be Content-Type: text/plain; charset=UTF-8 On Mon, May 23, 2016 at 11:47 AM, Paul Kyzivat wrote: > On 5/23/16 8:03 AM, Rifaat Shekh-Yusef wrote: > > We already have ways to carry around an identity in SIP. Within one >> trust domain, you don't have the kinds of confidentiality >> requirements that I articulate above, so surely one of our existing >> ways of sharing identity would suffice. It is only when the identity >> crosses administrative boundaries, in situations closer to a >> federated identity architecture, that you start seeing requirements >> to share only selected information. So I should be careful when we >> talk about "trust domains," as these federated cases amount only to >> partial trust, but that was what I meant. >> >> I guess it depends on your definition of *identity*; if it is the name >> and the AOR of the user, then you are correct that we have ways to carry >> this information in SIP today. >> But *identity* could include many other attributes like: address, age, >> contact info, etc; in this case SIP does not have away to carry all that >> info which could be included in a token. >> > > That mixes up *identity* from properties/attributes of the identified > entity. Even the name (display name) is a property. It typically isn't an > identity because it isn't unique. > > Yeah, you are right. I will try to to make sure that this is clear in the next version of the text. Regards, Rifaat > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --94eb2c11c00806d44c053384b4be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, May 23, 2016 at 11:47 AM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
On 5/23/16 8:03 AM, Rifaat Shekh-Yusef wrote:

=C2=A0 =C2=A0 We already have ways to carry around an identity in SIP. With= in one
=C2=A0 =C2=A0 trust domain, you don't have the kinds of confidentiality=
=C2=A0 =C2=A0 requirements that I articulate above, so surely one of our ex= isting
=C2=A0 =C2=A0 ways of sharing identity would suffice. It is only when the i= dentity
=C2=A0 =C2=A0 crosses administrative boundaries, in situations closer to a<= br> =C2=A0 =C2=A0 federated identity architecture, that you start seeing requir= ements
=C2=A0 =C2=A0 to share only selected information. So I should be careful wh= en we
=C2=A0 =C2=A0 talk about "trust domains," as these federated case= s amount only to
=C2=A0 =C2=A0 partial trust, but that was what I meant.

 I guess it depends on your definition of *identity*; if it is the name
and the AOR of the user, then you are correct that we have ways to carry this information in SIP today.
But *identity* could include many other attributes like: address, age,
contact info, etc; in this case SIP does not have away to carry all that info which could be included in a token.

That mixes up *identity* from properties/attributes of the identified entit= y. Even the name (display name) is a property. It typically isn't an id= entity because it isn't unique.


Yeah, you are right.
I will = try to to make sure that this is clear in the next version of the text.

Regards,
=C2=A0Rifaat

<= div>
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--94eb2c11c00806d44c053384b4be-- From nobody Tue May 24 06:55:21 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E78912D7CC for ; Tue, 24 May 2016 06:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPz5RvAJhjBi for ; Tue, 24 May 2016 06:55:18 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BAB12D7C8 for ; Tue, 24 May 2016 06:55:17 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by comcast with SMTP id 5Clibx6EjBE6O5Cnkb8xdO; Tue, 24 May 2016 13:55:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464098116; bh=7wLm6s+be8ZigdKtNifG9K4K8FvMyKe63tkJSoQvkbs=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=OJT2slj7nis3ZiOgX4sqb9lomdDiLJ2yCy//747U/kYLp9CuPPw431Ci/1NM1rC7g hekg8PRVNlizze4aUs7sK/hBDGrD/SNyqpCeF08CKupjjemMJ3AyG+0Q9PzMg3yuhB x4ZIcMULQ0IFu8a3B6orko2KFCU3SNNM1X8FppHielz9frsCA7LNZ8dK9AbYMhU62B wAhiTHOqxsGrQ4fgWWsmxTtICzlKL/LQhHeJuftIde3ZwVAxjg2In40cSq512I9tlx HkkBo7ovQg3mx8Degn6EdV0Tcc2j1XLhL7ePH7LOjztraXEBaot7uKy7RWiwKzyx/3 JhxivJjVkDewA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-17v.sys.comcast.net with comcast id yDvF1s00G1nMCLR01DvFVp; Tue, 24 May 2016 13:55:16 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u4ODtEtO005527; Tue, 24 May 2016 09:55:14 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u4ODtEpU005522; Tue, 24 May 2016 09:55:14 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Adam Roach In-Reply-To: <662d1694-0902-7d5a-c45e-b9eb1058a249@nostrum.com> (adam@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 24 May 2016 09:55:14 -0400 Message-ID: <87eg8rh871.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] "Roman's problem" X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 13:55:20 -0000 Adam Roach writes: > On 3/16/16 12:40, Dale R. Worley wrote: >> NAT traversal is handled by NAT compensation done by the edge proxy >> rather than ICE (thus keeping messages small enough for UDP). > > FWIW, I expect the SIPBRANDY effort to change this. Do you mean that you expect the SIPBRANDY effort will get systems to use ICE generally? Dale From nobody Tue May 24 09:32:02 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47D912D0F8 for ; Tue, 24 May 2016 09:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Tug2fOH1UM0 for ; Tue, 24 May 2016 09:31:59 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D74412D89F for ; Tue, 24 May 2016 09:31:59 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4OGVtix033265 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 May 2016 11:31:56 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "Dale R. Worley" References: <87eg8rh871.fsf@hobgoblin.ariadne.com> From: Adam Roach Message-ID: <97f42d5d-52ce-bb9f-a02c-c01c7d1c5da0@nostrum.com> Date: Tue, 24 May 2016 11:31:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <87eg8rh871.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] "Roman's problem" X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 16:32:01 -0000 On 5/24/16 08:55, Dale R. Worley wrote: > Adam Roach writes: >> On 3/16/16 12:40, Dale R. Worley wrote: >>> NAT traversal is handled by NAT compensation done by the edge proxy >>> rather than ICE (thus keeping messages small enough for UDP). >> FWIW, I expect the SIPBRANDY effort to change this. > Do you mean that you expect the SIPBRANDY effort will get systems to use > ICE generally? Perhaps I spoke more strongly than I should have in selecting the word "expect." I suppose "hope" would be a better term. We identified the voice hammer attack over a decade ago, and still have no generalized mitigation for it in SIP. /a From nobody Wed May 25 12:07:08 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6100412D90F for ; Wed, 25 May 2016 12:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIyewEE6BCCh for ; Wed, 25 May 2016 12:07:06 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149C612D8F6 for ; Wed, 25 May 2016 12:07:06 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id u4PJ34AX010677; Wed, 25 May 2016 15:07:01 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 23442k6x98-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 May 2016 15:07:01 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Wed, 25 May 2016 15:07:00 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4A= Date: Wed, 25 May 2016 19:06:59 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.213] Content-Type: multipart/alternative; boundary="_000_D3688271191B87jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-25_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605250227 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 19:07:07 -0000 --_000_D3688271191B87jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Also, if we decided to separate the AuthN and AuthZ, then we might need to = carry more than one token. I could see an argument that there is a need to carry the identity of the u= ser in one header, and a reference to a place where you can get attributes = about the originating user in another header, say. That's more or less what= we envisioned the last time we went down this path, which led to the RFC44= 84 requirements, largely informed by SAML (which I seem to recall 3GPP was = interested in at the time). But it's no accident that the work on RFC4484 never went beyond requirement= s. Today, I think that much of the useful work that could be done on the au= thorization question is in identifying which SIP authorization policies are= likely to depend on attributes as opposed to just the identity of the end = user. While we can readily conceive of applications adjunct to communicatio= ns that would require attributes, the challenge has been justifying why you= would invoke those applications with SIP rather than, say, HTTP. The fund= amental semantics of a SIP INVITE have remained pretty close to those of pl= acing a telephone call. The authorization policies of a telephone call are= really different than that of a web service, say, both in terms of how and= why they are invoked, what kinds of parties are involved, what forms redir= ection or cross-domain interaction can occur. With appropriate caveats for = other methods (notably MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have = authorization policy requirements that look a lot like call treatment polic= ies. That much said, I am kind of interested in call treatment policies, and the= ir interaction with identity information. But just saying that there might = be a video conference service in the cloud, say, doesn't shed a lot of ligh= t for me. If there's a video conference, I'd ordinarily think you just call= into it. If the user who opens the conference bridge needs to be charged, = that's identity information - which in its usual form will convey the indiv= idual user and their domain, like user@domain. If you need more complex sem= antics than that, it's probably because you're doing something more complic= ated than just calling in to the conference. But it's less clear to me why = you'd use SIP for such cases. Drilling down deeper into these use cases wou= ld help me understand where we're going, anyway - the use cases in RFC4484 = Section 4, which largely involve billing (including when dealing with vario= us protocol gateways) and resource management (both preemption and priority= ), ultimately didn't seem sufficient to motivate protocol work. Another issues in the need, in some cases, to avoid sending the token to th= e UA; in this case there is a need for an interim step to get the token(s) = to the SIP proxy. If this information is carried in headers, then presumably it could be adde= d, consumed, subtracted, or whatever by any relevant intermediaries. Jon Peterson Neustar, Inc. --_000_D3688271191B87jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <09FEE4E0195F0A44A559F90E35EA3F70@neustar.biz> Content-Transfer-Encoding: quoted-printable

Also, if we decided to separate the AuthN and AuthZ, then we might nee= d to carry more than one token.

I could see an argument that there is a need to carry the identity of = the user in one header, and a reference to a place where you can get attrib= utes about the originating user in another header, say. That's more or less= what we envisioned the last time we went down this path, which led to the RFC4484 requirements, largely inf= ormed by SAML (which I seem to recall 3GPP was interested in at the time).<= /div>

But it's no accident that the work on RFC4484 never went beyond requir= ements. Today, I think that much of the useful work that could be done on t= he authorization question is in identifying which SIP authorization policie= s are likely to depend on attributes as opposed to just the identity of the end user. While we can readily conc= eive of applications adjunct to communications that would require attribute= s, the challenge has been justifying why you would invoke those application= s with SIP rather than, say, HTTP.  The fundamental semantics of a SIP INVITE have remained pretty close= to those of placing a telephone call.  The authorization policies of = a telephone call are really different than that of a web service, say, both= in terms of how and why they are invoked, what kinds of parties are involved, what forms redirection or cross-domain= interaction can occur. With appropriate caveats for other methods (notably= MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have authorization policy r= equirements that look a lot like call treatment policies.

That much said, I am kind of interested in call treatment policies, an= d their interaction with identity information. But just saying that there m= ight be a video conference service in the cloud, say, doesn't shed a lot of= light for me. If there's a video conference, I'd ordinarily think you just call into it. If the user who op= ens the conference bridge needs to be charged, that's identity information = - which in its usual form will convey the individual user and their domain,= like user@domain. If you need more complex semantics than that, it's probably because you're doing something = more complicated than just calling in to the conference. But it's less clea= r to me why you'd use SIP for such cases. Drilling down deeper into these u= se cases would help me understand where we're going, anyway - the use cases in RFC4484 Section 4, which larg= ely involve billing (including when dealing with various protocol gateways)= and resource management (both preemption and priority), ultimately didn't = seem sufficient to motivate protocol work.

Another issues in the need, in some cases, to avoid sending the token = to the UA; in this case there is a need for an interim step to get the toke= n(s) to the SIP proxy.

If this information is carried in headers, then presumably it could be= added, consumed, subtracted, or whatever by any relevant intermediaries.&n= bsp;

Jon Peterson
Neustar, Inc.
--_000_D3688271191B87jonpetersonneustarbiz_-- From nobody Thu May 26 10:28:14 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA6C12B015 for ; Thu, 26 May 2016 10:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v58piNyn8WFF for ; Thu, 26 May 2016 10:28:11 -0700 (PDT) Received: from uhil19pa11.eemsg.mail.mil (uhil19pa11.eemsg.mail.mil [214.24.21.84]) by ietfa.amsl.com (Postfix) with ESMTP id DDB9412B01A for ; Thu, 26 May 2016 10:28:10 -0700 (PDT) Received: from edge-cols03.mail.mil ([131.64.107.103]) by uhil19pa11.eemsg.mail.mil with ESMTP; 26 May 2016 17:28:10 +0000 Received: from UCOLHPPW.easf.csd.disa.mil (131.64.107.32) by edge-cols03.mail.mil (131.64.107.103) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 26 May 2016 17:27:57 +0000 Received: from UCOLHU2J.easf.csd.disa.mil ([131.64.107.4]) by UCOLHPPW.easf.csd.disa.mil ([131.64.107.32]) with mapi id 14.03.0266.001; Thu, 26 May 2016 17:27:57 +0000 From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" To: "Peterson, Jon" , Rifaat Shekh-Yusef Thread-Topic: [Non-DoD Source] Re: [sipcore] SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRqS0TDyFOI6cZKUWBz4pHTe07DJ+vbNaAgAFjyQCAA2UIgIACvqkAgANXvoCABITogIAH9hmAgAMlg4CAAaO6wA== Date: Thu, 26 May 2016 17:27:56 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDFA28450AA@UCOLHU2J.easf.csd.disa.mil> References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Non-DoD Source] Re: SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 17:28:13 -0000 Hi, Jon: You have done an excellent analysis of the SIP call scenario described belo= w: User and Conferencing server. Recently, media resource broker (MRB) RFC 6917 has been standardized. If th= e conferencing server interacts with MRB for setting up the media, the SIP = call scenario also need to include MRB. I like to see your analysis whether the existing security parameters of SIP= are sufficient for AuthN and AuthZ. In another note, we have not addressed the application sharing using SIP ca= ll (similar along the line of MRB). It may be another item we may look in t= he future, if there is a need. Right now, application sharing happens indep= endent of the SIP call. BR/Radhika=20 -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Peterson, Jon Sent: Wednesday, May 25, 2016 3:07 PM To: Rifaat Shekh-Yusef Cc: sipcore@ietf.org Subject: [Non-DoD Source] Re: [sipcore] SIP AuthNZ Problem Statement - v3 Also, if we decided to separate the AuthN and AuthZ, then we might need to= carry more than one token. I could see an argument that there is a need to carry the identity of the u= ser in one header, and a reference to a place where you can get attributes = about the originating user in another header, say. That's more or less what= we envisioned the last time we went down this path, which led to the RFC44= 84 requirements, largely informed by SAML (which I seem to recall 3GPP was = interested in at the time). But it's no accident that the work on RFC4484 never went beyond requirement= s. Today, I think that much of the useful work that could be done on the au= thorization question is in identifying which SIP authorization policies are= likely to depend on attributes as opposed to just the identity of the end = user. While we can readily conceive of applications adjunct to communicatio= ns that would require attributes, the challenge has been justifying why you= would invoke those applications with SIP rather than, say, HTTP. The fund= amental semantics of a SIP INVITE have remained pretty close to those of pl= acing a telephone call. The authorization policies of a telephone call are= really different than that of a web service, say, both in terms of how and= why they are invoked, what kinds of parties are involved, what forms redir= ection or cross-domain interaction can occur. With appropriate caveats for = other methods (notably MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have = authorization policy requirements that look a lot like call treatment polic= ies. That much said, I am kind of interested in call treatment policies, and the= ir interaction with identity information. But just saying that there might = be a video conference service in the cloud, say, doesn't shed a lot of ligh= t for me. If there's a video conference, I'd ordinarily think you just call= into it. If the user who opens the conference bridge needs to be charged, = that's identity information - which in its usual form will convey the indiv= idual user and their domain, like user@domain. If you need more complex sem= antics than that, it's probably because you're doing something more complic= ated than just calling in to the conference. But it's less clear to me why = you'd use SIP for such cases. Drilling down deeper into these use cases wou= ld help me understand where we're going, anyway - the use cases in RFC4484 = Section 4, which largely involve billing (including when dealing with vario= us protocol gateways) and resource management (both preemption and priority= ), ultimately didn't seem sufficient to motivate protocol work. Another issues in the need, in some cases, to avoid sending the token to t= he UA; in this case there is a need for an interim step to get the token(s)= to the SIP proxy. If this information is carried in headers, then presumably it could be adde= d, consumed, subtracted, or whatever by any relevant intermediaries.=20 Jon Peterson Neustar, Inc. From nobody Fri May 27 13:57:01 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5269812D8F6 for ; Fri, 27 May 2016 13:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBmQCc7jAZSv for ; Fri, 27 May 2016 13:56:56 -0700 (PDT) Received: from uhil19pa14.eemsg.mail.mil (uhil19pa14.eemsg.mail.mil [214.24.21.87]) by ietfa.amsl.com (Postfix) with ESMTP id DD1AC12D8F9 for ; Fri, 27 May 2016 13:56:55 -0700 (PDT) Received: from edge-cols03.mail.mil ([131.64.107.100]) by uhil19pa14.eemsg.mail.mil with ESMTP; 27 May 2016 20:56:54 +0000 Received: from UCOLHPPX.easf.csd.disa.mil (131.64.107.33) by edge-cols03.mail.mil (131.64.107.100) with Microsoft SMTP Server (TLS) id 14.3.266.1; Fri, 27 May 2016 20:56:53 +0000 Received: from UCOLHU2J.easf.csd.disa.mil ([169.254.6.121]) by UCOLHPPX.easf.csd.disa.mil ([131.64.107.33]) with mapi id 14.03.0266.001; Fri, 27 May 2016 20:56:53 +0000 From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" To: "Peterson, Jon" , Rifaat Shekh-Yusef Thread-Topic: [sipcore] [Non-DoD Source] Re: SIP AuthNZ Problem Statement - v3 Thread-Index: AQHRt3P+Ys8zCyFF6EC9zC76kvsgI5/NPUgA Date: Fri, 27 May 2016 20:56:53 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDFA2846378@UCOLHU2J.easf.csd.disa.mil> References: <7594FB04B1934943A5C02806D1A2204B37F97548@ESESSMB209.ericsson.se> <8486C8728176924BAF5BDB2F7D7EEDDFA28450AA@UCOLHU2J.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDFA28450AA@UCOLHU2J.easf.csd.disa.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Non-DoD Source] Re: SIP AuthNZ Problem Statement - v3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 20:57:00 -0000 Hi, Jon: I forgot to add a couple of other RFCs related to the security issue: SIP-b= ased centralized conferencing control manipulation protocol (CCMP) - RFC 45= 82 and Binary Floor Control Protocol (BFCP) - RFC 4582. So, we have three RFCs with different protocols (RFC 4582 - CCMP, RFC 4582 = - BFCP, and RFC 6917 - MRB) that are needed in the context SIP-based confer= encing call at least for now (although other applications may appear in the= future when multimedia conferencing becomes a usual feature over the publi= c Internet like multimedia streaming). The key is that all of them need SIP Conferencing UAs (XCON) AuthN and Auth= Z.=20 Now, we get a more complex scenario of SIP-based conferencing that is direc= tly related to media (MRB) for its media part, BFCP may be thought a kind o= f application sharing, and CCMP manipulated the overall conference that is = being "originally" initiated by SIP Conferencing UAs (XCON). It appears that there is a dependency between SIP, CCMP, MRB, and BFCP.=20 It makes the security scenario more interesting because there are four dif= ferent protocols (SIP, CCMP, MRB, and BFCP) although all of those protocols= must coordinate internally among themselves making conferencing successful= , and security function is one of them. Again, I like to see your analysis whether the existing security parameters= of SIP are sufficient for AuthN and AuthZ. BR/Radhika=20 -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Roy, Radhika R= CIV USARMY RDECOM CERDEC (US) Sent: Thursday, May 26, 2016 1:28 PM To: Peterson, Jon ; Rifaat Shekh-Yusef Cc: sipcore@ietf.org Subject: Re: [sipcore] [Non-DoD Source] Re: SIP AuthNZ Problem Statement - = v3 All active links contained in this email were disabled. Please verify the = identity of the sender, and confirm the authenticity of all links contained= within the message prior to copying and pasting the address to a Web brows= er. =20 ---- Hi, Jon: You have done an excellent analysis of the SIP call scenario described belo= w: User and Conferencing server. Recently, media resource broker (MRB) RFC 6917 has been standardized. If th= e conferencing server interacts with MRB for setting up the media, the SIP = call scenario also need to include MRB. I like to see your analysis whether the existing security parameters of SIP= are sufficient for AuthN and AuthZ. In another note, we have not addressed the application sharing using SIP ca= ll (similar along the line of MRB). It may be another item we may look in t= he future, if there is a need. Right now, application sharing happens indep= endent of the SIP call. BR/Radhika=20 -----Original Message----- From: sipcore [Caution-mailto:sipcore-bounces@ietf.org] On Behalf Of Peters= on, Jon Sent: Wednesday, May 25, 2016 3:07 PM To: Rifaat Shekh-Yusef Cc: sipcore@ietf.org Subject: [Non-DoD Source] Re: [sipcore] SIP AuthNZ Problem Statement - v3 Also, if we decided to separate the AuthN and AuthZ, then we might need to= carry more than one token. I could see an argument that there is a need to carry the identity of the u= ser in one header, and a reference to a place where you can get attributes = about the originating user in another header, say. That's more or less what= we envisioned the last time we went down this path, which led to the RFC44= 84 requirements, largely informed by SAML (which I seem to recall 3GPP was = interested in at the time). But it's no accident that the work on RFC4484 never went beyond requirement= s. Today, I think that much of the useful work that could be done on the au= thorization question is in identifying which SIP authorization policies are= likely to depend on attributes as opposed to just the identity of the end = user. While we can readily conceive of applications adjunct to communicatio= ns that would require attributes, the challenge has been justifying why you= would invoke those applications with SIP rather than, say, HTTP. The fund= amental semantics of a SIP INVITE have remained pretty close to those of pl= acing a telephone call. The authorization policies of a telephone call are= really different than that of a web service, say, both in terms of how and= why they are invoked, what kinds of parties are involved, what forms redir= ection or cross-domain interaction can occur. With appropriate caveats for = other methods (notably MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have = authorization policy re quirements that look a lot like call treatment policies. That much said, I am kind of interested in call treatment policies, and the= ir interaction with identity information. But just saying that there might = be a video conference service in the cloud, say, doesn't shed a lot of ligh= t for me. If there's a video conference, I'd ordinarily think you just call= into it. If the user who opens the conference bridge needs to be charged, = that's identity information - which in its usual form will convey the indiv= idual user and their domain, like user@domain. If you need more complex sem= antics than that, it's probably because you're doing something more complic= ated than just calling in to the conference. But it's less clear to me why = you'd use SIP for such cases. Drilling down deeper into these use cases wou= ld help me understand where we're going, anyway - the use cases in RFC4484 = Section 4, which largely involve billing (including when dealing with vario= us protocol gateways) and resource management (both preemption and priority= ), ultimately didn't se em sufficient to motivate protocol work. Another issues in the need, in some cases, to avoid sending the token to t= he UA; in this case there is a need for an interim step to get the token(s)= to the SIP proxy. If this information is carried in headers, then presumably it could be adde= d, consumed, subtracted, or whatever by any relevant intermediaries.=20 Jon Peterson Neustar, Inc. _______________________________________________ sipcore mailing list sipcore@ietf.org Caution-https://www.ietf.org/mailman/listinfo/sipcore