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

[Elwell, John]

Chris,
 
Thanks - that helps a lot.
 
John


  _____  

From: Chris Sibley [mailto:Chris.Sibley at cbeyond.net] 
Sent: 14 March 2006 14:47
To: Elwell, John; SIP Forum Tech WG
Subject: RE: [SIPForum-techwg] Draft Version 5 - remaining discussion poin
ts


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
<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/a423f352/attachment.html