Diameter SIP application IETF 64 Vancouver, 6-11 November,

Status draft-ietf-aaa-diameter-sip-app-10.txt passed the 3 rd WG Last Call in October New requirements have been coming during each previous WGLC After the 3 rd WGLC new issues were raised, mainly due to compatibility with the 3GPP Diameter application for the Cx interface. All issues are tracked at:

Issue 49: Required Authentication parameters (1) Use case: Nonces are generated in the Diameter client Check for final authentication also takes place in the Diameter client. The Diameter client sends the generated nonce to the Diameter server in MAR |Diameter| | SIP | | server | | server | | | 1. SIP INVITE | >| | | Proxy Authentication Required) | < | | | 3. SIP INVITE | >| | 4. MAR | |< | | 5. MAA | | >| 6. SIP INVITE | | > | | 8. SIP 200 (OK) 8. SIP 200 (OK) |< < | | |

Issue 49: Required Authentication parameters (2) Optimization 1: MAA command includes a SIP-Authenticate AVP which mandates to include a nonce (Digest-Nonce AVP). Since the nonce has been previously generated in the Diameter client, there is not need to repeat this AVP anymore. Proposal: make Digest-Nonce AVP optional in SIP- Authenticate AVP

Issue 49: Required Authentication parameters (3) Optimization 2: MAR command includes a SIP-Authorization AVP which mandates to include Digest-URI and Digest-Response AVPs. The Diameter server does not really need Digest-URI or Digest-Response Proposal: Make Digest-URI and Digest- Response AVP optional in the SIP-authorization AVP

Issue 49: Required Authentication parameters (4) Optimization 3 SIP-Authentication-Info AVP mandates the inclusion of a Digest-Nextnonce AVP Since nonces are generated in the Diameter client, there is no point in the Diameter server including a Digest-Nextnonce AVP Proposal: make Digest-Nextnonce AVP in the SIP-Authentication-Info AVP

Issue 50: User-Data AVP in PPR PPR mandates to include a User-Data AVP However, there is a use case where the User- Data AVP is not updated, but the SIP- Accounting-Information AVP instead. Proposal: Make User-Data AVP optional, modify the explanatory text accordingly.

Issue 51: Result-Code AVP Message formats are not open to vendor extensions because all commands mandate Auth-Application-ID AVP. Complaint: can’t use Experimental- Result/Experimental-Result-Code AVPs But Diameter SIP application is not a vendor specific application, so commands MUST contain a Result-Code AVP Proposal: do nothing

Issue 52: Auth-Application-ID AVP Message formats are not open to vendor extensions because all commands mandate Auth-Application-ID AVP. Complaint: Vendor-Specific-Application-ID AVP cannot be used in a command But Diameter SIP application is not a vendor specific application, so commands MUST contain Auth-Application-ID. Proposal: do nothing.

Issue 53: MAR processing The user is not authenticated until the MAA command is received, but the MAR processing assumes it is. Authentication flag is set if the SIP-Server AVP contains a different value than in the past. The flag is cleared if the stored value matches the SIP- Server AVP However, the user is not completely authenticated at this stage (MAR/MAA). Proposal: the flag must be cleared when processing the SAR/SAA commands instead

Issue 54: Auth-Application-ID AVP in UAR command The syntax of the UAR command defines the Auth- Application-ID as a fixed AVP (i.e., syntax within <> brackets), but the rest of the commands list it as a mandatory AVP (i.e., syntax within {} brackets). No specific guidance is provided in RFC 3588, but in all commands the Auth-Application-ID appears as mandatory AVP Proposal: be consistent with other commands and change with { Auth-Application-Id } in the syntax of the UAR command