[SIPForum-techwg] Draft Version 5 - remaining discussion poin ts

[Chris Sibley]

Hi John,

I agree with your recommendation and propose that we modify the section
as follows. What do you think?

Thanks, --Chris

10	Authentication and Accounting
10.1	Authentication of the Enterprise by the Service Provider

Authentication of the Enterprise by the Service Provider can be
performed in one of two ways. PBX systems MUST implement Option 1 and
MAY implement Option 2.

SIP Application Servers MUST support both Option 1 and Option 2 in order
to ensure interoperability with all PBX systems.

10.1.1	Option 1: Authentication using TLS Credentials

The first method relies on authorization of the identity asserted by the
Enterprise's verified certificate used to establish the TLS connection
with the Service Provider's SIP Proxy Server. 

This model requires that the Service Provider's SIP Proxy Server and SIP
Application Server be capable of exchanging authorization, accounting,
and usage information on a per-call basis in order to ensure complete
billing traceability through the network. When this model is utilized,
information identifying the Enterprise is extracted from the
Enterprise's certificate (for example, domain name) by the SIP Proxy
Server and conveyed to the "downstream" device as necessary. (It is out
of the scope of this interface specification to specify the actual
mechanism used to convey this information within the Service Provider's
Network.)

10.1.2	Option 2: Digest Access Authentication

The second method of authenticating an Enterprise utilizes the digest
authentication scheme as described in section 22.4 of RFC 3261 [8]. In
this model the Service Provider assigns the Enterprise Network a
username and password (referred to as a "Network Account" hereafter)
that is valid within the Service Provider's domain (realm). It is
important to note that if the digest authentication scheme is employed,
it does not eliminate the requirement to utilize TLS between the Service
Provider and Enterprise Network SIP Proxy Servers.

When this model is employed, the following rules must be observed:

1.	When processing an INVITE request from an unauthenticated PBX,
the SIP Application Server MUST challenge the message, only accepting
authentication credentials that are valid within its realm.

2.	When processing a REGISTER request from an unauthenticated PBX,
the SIP Application Server MUST challenge the message, only accepting
authentication credentials that are valid within its realm.

3.	When challenged by the SIP Application Server, the PBX MUST
respond with authentication credentials that are valid within the
Service Provider's realm (i.e. the network account username and password
supplied by the Service Provider).

4. 	In order to avoid unnecessary challenges, the PBX SHOULD include
its authentication credentials using the current nonce in each request
sent to the SIP Application Server.








From: Elwell, John [mailto:john.elwell at siemens.com] 
Sent: Tuesday, March 14, 2006 3:19 AM
To: Chris Sibley; SIP Forum Tech WG
Subject: RE: [SIPForum-techwg] Draft Version 5 - remaining discussion
poin ts

Chris,
 
Ernst Horvath wrote:
- Section 9.1, bullet 2. If the PBX is a SIP proxy, the UA will need to 
provide authentication credentials, which does not seem reasonable. Does

this mean the PBX must be a B2BUA? We have made this comment before, but

nothing seems to have happened.
[Chris Sibley] 
Yes, this has been discussed before. Our specification intentionally
makes no assumption as to the physical or logical configuration of the
PBX. It can be implemented as a pure proxy or it can be a B2BUA. So,
*IF* the PBX manufacturer chose to architect their PBX as a pure proxy,
*AND IF* they wanted or needed to utilize Network Accounts, then yes,
the credentials would need to be provisioned on the Enterprise UAs. 
However, if a PBX manufacturer chose to build their PBX as a pure proxy
then they probably would *NOT* need (nor want) to utilize Network
Accounts in the first place. Instead, they would rely on TLS for
authentication (i.e. the first option outlined in the section). Network
Accounts are really only useful if the PBX is a B2BUA (in which case
they are very useful, to SP at least.)

[JRE] I do think we need some clarification in 10.1. This describes two
methods by which the service provider can authenticate the enterprise.
However, it does not say which methods have to be supported by which
side. Clearly from the answer you gave above we cannot mandate support
of the second method (digest authentication) on the IP PBX side, because
some IP PBX architectures will be unable to support it. So in the
traditional way, maybe we should say that the SP MUST support both
methods and the IP PBX MUST support at least one method. Or
alternatively say that the IP PBX MUST support the first method (based
on the IP PBX's certificate used for TLS establishment) and MAY support
the second method.
John


**********************************************************************
This email may contain confidential information. If you are not
the intended recipient, please advise by return email and delete
immediately without reading or forwarding to others.
 - Cbeyond 
**********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20060314/49a121ff/attachment.html