SIPPING Working Group Sanjoy Sen
Internet Draft Lee Valerius
Category: Standards Track Nortel Networks
Expires on: May 2002
Vesa Torvinen
Ericsson
November 2001
Single Hop Message Authentication in SIP
<draft-sen-sipping-onehop-digest-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
To date, the HTTP access authentication framework, as described in
[RFC2617] and as used in [SIPbis05], has permitted limited SIP
message authentication from UAC to Proxy/UAS, Proxy to Proxy, and
Proxy to UAS. This draft addresses some of the shortcomings of SIP
usage of Digest for message authentication between a SIP User Agent
and a Proxy one hop away (e.g., an outbound Proxy). For the messages
exchanged between the UA and a Proxy one hop away, the Service
Provider may want to provide a different level of protection than
that possible for the same messages end-to-end. Authentication of
both requests and responses traveling in either direction should be
possible with minimum number of necessary roundtrip exchanges. We
discuss some the limitations of SIP Digest message authentication
framework in satisfying these requirements and propose possible
solutions. A new value of the "qop-options" parameter would indicate
to a SIP entity that the challenging entity is one hop away and the
maximum protection of SIP message is required. Some other aspects of
Internet Draft Single Hop Message Authentication in SIP Nov 2001
this solution are in the form of behavior enhancements of SIP Proxy
and UA.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1 Introduction ...................................................2
2 Conventions used in this document ..............................2
3 Digest for SIP Message Authentication between UA and Proxy one
hop away...........................................................3
4 Example Call Flows .............................................5
5 Security Considerations ........................................9
6 References .....................................................9
7 Acknowledgments ................................................9
8 Author's Address ...............................................9
9 Full Copyright Statement ......................................10
1 Introduction
To date, the HTTP access authentication framework, as described in
[RFC2617] and as used in [SIPbis05], has permitted limited SIP
message authentication from UAC to Proxy/UAS, Proxy to Proxy, and
Proxy to UAS. This draft addresses some of the shortcomings of SIP
usage of Digest for message authentication between a SIP User Agent
and a Proxy one hop away (e.g., an outbound Proxy). For the messages
exchanged between the UA and a Proxy one hop away, the Service
Provider may want to provide a different level of protection than
that possible for the same messages end-to-end. Thus, it may be
required that integrity protection of the entire message (except
perhaps the header carrying the credential) be provided.
Authentication of both requests and responses traveling in either
direction should be possible with minimum number of necessary
roundtrip exchanges. The latter consideration is particularly
important for access networks that are resource-constrained and
prone to large round-trip times.
In Section 3, we discuss some the limitations of SIP Digest message
authentication framework in satisfying some of the above
requirements and propose possible solutions. A new value of the
"qop-options" parameter would indicate to a SIP entity that the
challenging entity is one hop away and the maximum protection of SIP
message is required. Other aspects of this solution are in the form
of behavior enhancements of SIP Proxy and UA. In Section 4, the
solution is exemplified with some high-level call flows.
2 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
Sen Expires May 2002 [Page 2]
Internet Draft Single Hop Message Authentication in SIP Nov 2001
this document are to be interpreted as described in RFC-2119.
3 Digest for SIP Message Authentication between UA and Proxy one hop
away
We believe that the requirements discussed in the rest of this
section are either not clearly addressed in the existing SIP
authentication framework or not addressed at all.
Requirement# 1: It would be possible to authenticate all SIP
messages between the UA and the Proxy at the level of protection
negotiated between them.
This can be decomposed into two scenarios.
A) UAC-Proxy message authentication:
For authenticating requests from the UAC [RFC2617], the Proxy issues
the Digest challenge in the Proxy-Authenticate header in a 407
response. In response to the challenge, the UAC should include the
credential in Proxy-Authorization header and resubmit the request.
It is not clear from [RFC2617] or [SIPbis05] how the response
forwarded upstream by the Proxy towards the UAC will be
authenticated at the protection level negotiated between the Proxy
and the UAC. It is proposed here that the Proxy insert the
Authentication-Info header (with the proper credential) in the
response that it forwards upstream towards the UAC.
B) UAS-Proxy message authentication:
According to [RFC2617], the UAS can authenticate requests forwarded
by the Proxy as follows: the UAS must generate a 407 response with a
Proxy-Authenticate header containing a Digest challenge. In
response, the Proxy should re-submit the request with a Proxy-
Authorization header carrying the credential. All subsequent
responses from the UAS to be authenticated by the Proxy should carry
the Proxy-Authentication-Info header with proper credential.
However, a couple of problems arise for UAS-Proxy authentication in
SIP. First, the use of Proxy-Authentication-Info header is not
mentioned in [SIPbis05]. Secondly, a Proxy is prohibited from adding
the Proxy-Authorization header to a forwarded request, unless the
request is re-submitted. It is required that a Proxy re-submitting a
Sen Expires May 2002 [Page 3]
Internet Draft Single Hop Message Authentication in SIP Nov 2001
request must increase the CSeq header field of the request implying
that when the corresponding response is received at the UAC, it
would be dropped. To alleviate the problem, it has been suggested in
the list that the Proxy should be able to "resubmit" a request just
by changing the branch parameter of the top-most Via header (this is
equivalent of doing an empty fork). To the UAS, this is a new
transaction anyway.
If the UA and the Proxy had already authenticated each other, this
would allow the Proxy to insert a Proxy-Authorization header
(containing its credential) in an incoming request to be forwarded
preemptively (i.e., without waiting for a challenge, and thereby
avoiding a roundtrip) to the UAS. If the credential is deemed valid
by the UAS, the response sent back should contain a Proxy-
Authentication-Info header for mutual authentication by the Proxy.
If the credential is deemed invalid to the UAS, it will send a 407
response with a Proxy-Authenticate header containing a Digest
challenge and the Proxy would "re-submit" the request in the same
way as above.
Requirement # 2: The security mechanism must be able to protect a
SIP message to the maximum extent possible, when the SIP entities
are just one hop away. Also, the framework should support replay
protection for all messages.
This is decomposed into two parts, which are evaluated separately.
A) Maximum Integrity protection of SIP messages:
Digest supports integrity protection of the SIP message body (not
the headers) when the qop-options directive within the Digest
challenge is set to the value "auth-int". A new qop-options value -
"auth-extd-int" is proposed, which when set by the SIP entity one
hop away issuing the challenge, will direct the client to include
for integrity protection all headers and bodies of the message that
are mutually agreed on for maximum protection. For example, this
might mean that the A2 parameter of the Digest response [RFC2617] is
computed as follows:
A2 = H(entire message with all headers in canonical form, excluding
the header which carries the credential).
B) Anti-replay protection:
This is really a function of how the server generates the nonce. In
order to limit performance impact, it may be required that the same
nonce be used over multiple messages. In that case, the nonce-count
is useful to provide replay protection. It is recommended that the
Proxy server generate a new nonce value whenever possible. For
example, if the UAS sends its authorization credentials to the Proxy
Sen Expires May 2002 [Page 4]
Internet Draft Single Hop Message Authentication in SIP Nov 2001
in the Proxy-Authentication-Info header, it should send a new next-
nonce value.
Requirement # 3: In order to avoid excess round-trip, a Proxy should
be able to piggyback its challenge in a 401 or 407 response that it
forwards upstream to the UAC. This is useful in certain operations
where the user authentication and message authentication mechanisms
are different and take place at different network entities. An
example of this is the third generation mobile network [3gpp-req]
where the authentication of the SIP UA might be conducted at an
entity different than the Proxy with whom the UA establishes the
message integrity relationship.
[RFC2617] notes that if a client is to be authenticated by multiple
entities, the challenges must be carried in different responses.
However, [SIPbis05] allows for the Proxy to aggregate multiple
challenges in responses to forked requests and insert them to a
single 401 or 407 response to be sent upstream. The same mechanism
can possibly be leveraged by the Proxy, which can add a Proxy-
Authenticate header (carrying its challenge) to a 401/407 response
that will be forwarded upstream. Generally, a Proxy sends its
challenge upstream in a 407 response. The UAC responds with a
matching credential for each challenge.
4 Example Call Flows
We will consider an example utilizing a mobile, wireless terminal as
UA to illustrate some of the above proposals. There is a SIP serving
proxy (also acting as a Registrar) that would authenticate the UA
and would also support the ability to terminate INVITEs to the UA.
There is a SIP outbound Proxy that acts as a "point of presence" for
the roaming UA to the SIP world. At the time of registration, the
roaming user is authenticated by the serving Proxy. Subsequently,
all messages between the user agent and the outbound Proxy must be
authenticated. Two cases are considered.
CASE 1: UA registering and originating a call
UA Outbound Proxy Serving Proxy
| | |
| REGISTER F1 | |
|---------------->| REGISTER F1 |
| |-------------------->|
| | |
| | 401 Unauthorized F2 |
Sen Expires May 2002 [Page 5]
Internet Draft Single Hop Message Authentication in SIP Nov 2001
| 401 F3 |<--------------------|
|<----------------| |
| | |
| REGISTER F4 | |
|---------------->| REGISTER F5 |
| |-------------------->|
| | 200 OK |
| 200 OK F6 |<--------------------|
|<----------------| |
| INVITE F7 | |
|---------------->| INVITE
| |------------->
| |
| |<-------------
|<----------------| 200 OK
| 200 OK F8 |
| |
|---------------->|
| ACK F9 |------------->
| | ACK
F1: UA sends a REGISTER message to the outbound Proxy, which is
forwarded to the serving Proxy.
F2: The serving Proxy returns a 401 "Unauthorized" message
containing a WWW-Authenticate header carrying an authentication
challenge. The challenge may utilize any known authentication
method.
SIP/2.0 401 Unauthorized
...
WWW-Authenticate:...
F3: The outbound Proxy adds a Proxy-Authenticate header to 401
containing the proxy-initiated security challenge. This example
features a Digest challenge so as to illustrate the usage of the new
qop-options value "auth-extd-int".
SIP/2.0 401 Unauthorized
...
WWW-Authenticate:...
Proxy-Authenticate: Digest realm=MOBILEUSR nonce=<anyvalue>,
algorithm=MD5, qop=auth-extd-int
F4: The UA re-sends the REGISTER with the authentication response in
Authorization header and the Digest response in Proxy-Authorization
header.
Sen Expires May 2002 [Page 6]
Internet Draft Single Hop Message Authentication in SIP Nov 2001
REGISTER sip:server.nortel.com SIP/2.0
...
Authorization:...
Proxy-Authorization: Digest username=<user>, realm=MOBILEUSR,
nonce=<anyvalue>, uri=<SIP-URI>, response=<message-digest>,
cnonce=<value>, nc=1, qop=auth-extd-int
F5: The outbound Proxy forwards the REGISTER after verifying the
Digest response and stripping off the Proxy-Authorization header.
REGISTER sip:server.nortel.com SIP/2.0
...
Authorization:...
F6: The 200 OK to the REGISTER arrives at the Proxy. The Proxy
inserts the Authentication-Info header in the 200 OK for
authenticating the message to the UAC [Note: this assumes that the
authentication of the REGISTER message at the Proxy in step F5 is
successful].
SIP/2.0 200 OK
Authentication-Info: nextnonce=<anyvalue>, qop=auth-extd-int,
rspauth=<message-digest>, nc=1
F7: A subsequent INVITE request to a user Bob, must also be
integrity protected - the UA pre-emptively adds the Proxy-
Authorization header.
INVITE sip: bob@server.nortel.com SIP/2.0
...
Proxy-Authorization: Digest username=<user>, realm=MOBILEUSR,
nonce=<anyvalue>, uri=<SIP-URI>, response=<message-digest>,
cnonce=<value>, nc=2, qop= auth-extd-int
F8: The 200 OK response is forwarded to the UA by the Proxy after
inserting the Authentication-Info header.
SIP/2.0 200 OK
Authentication-Info: qop=auth-extd-int, rspauth=<message-
digest>, nc=2
F9: UA sends an ACK message complete the INVITE transaction
ACK sip: bob@server.nortel.com SIP/2.0
...
Proxy-Authorization: Digest username=<user>, realm=MOBILEUSR,
nonce=<anyvalue>, uri=<SIP-URI>, response=<message-digest>,
cnonce=<value>, nc=3, qop= auth-extd-int
Sen Expires May 2002 [Page 7]
Internet Draft Single Hop Message Authentication in SIP Nov 2001
CASE 2: UA receives an incoming INVITE through the outbound Proxy.
The UA and the outbound Proxy has mutually authenticated as
described in CASE 1.
UA Outbound Proxy
| |
| | INVITE
| INVITE F1 |<-------------
|<----------------|
| |
|---------------->|
| 200 OK F2 |------------->
| | 200 OK
| |
| |<-------------
|<----------------| ACK
| ACK F3 |
| |
F1: The Outbound Proxy receives an incoming INVITE. The Proxy
modifies the branch parameter in the top-most Via header, inserts
the Proxy-Authorization header containing the Digest credentials and
"re-submits" the request to the UAS.
INVITE sip: tom@host.nortel.com SIP/2.0
Via: SIP/2.0/UDP server.nortel.com;branch=23ade45.1
...
Proxy-Authorization: Digest username=<user>, realm=MOBILEUSR,
nonce=<anyvalue>, uri=<SIP-URI>, response=<message-digest>,
cnonce=<value>, nc=1, qop= auth-extd-int
F2: If the authentication is successful, the UAS sends a 200 OK with
the Authentication-Info header.
SIP/2.0 200 OK
Authentication-Info: qop=auth-extd-int, rspauth=<message-
digest>, nc=1
F3: The Proxy inserts the Proxy-Authorization in the incoming ACK
message and again "resubmits" the request
Sen Expires May 2002 [Page 8]
Internet Draft Single Hop Message Authentication in SIP Nov 2001
ACK sip: tom@host.nortel.com SIP/2.0
Via: SIP/2.0/UDP server.nortel.com;branch=23ade45.1
...
Proxy-Authorization: Digest username=<user>, realm=MOBILEUSR,
nonce=<anyvalue>, uri=<SIP-URI>, response=<message-digest>,
cnonce=<value>, nc=2, qop= auth-extd-int
5 Security Considerations
Most of the security considerations in Section 4 of [RFC2617] still
apply except that now we can provide a better level of integrity
protection with consequent reduction in risk for MITM attacks.
However, since the authentication mechanisms are carried in the
challenges in clear-text, bidding-down type of attack is still
possible.
6 References
[SIPbis05] Session Initiation Protocol, draft-ietf-sip-rfc2543bis-
05.txt
[RFC2617] HTTP Authentication: Basic and Digest Access
Authentication, RFC 2617
[3gpp-req] 3GPP requirements on SIP, draft-garcia-sipping-3gpp-reqs-
00.txt
7 Acknowledgments
The authors would like to thank Scott Orton of Nortel Networks and
Tao Haukka of Nokia for their useful comments and suggestions
related to this draft.
8 Author's Address
Sanjoy Sen
Nortel Networks
sanjoy@nortelnetworks.com
Lee Valerius
Nortel Networks
valerius@nortelnetworks.com
Vesa Torvinen
Oy LM Ericsson Ab
Sen Expires May 2002 [Page 9]
Internet Draft Single Hop Message Authentication in SIP Nov 2001
vesa.torvinen@ericsson.fi
9 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
Sen Expires May 2002 [Page 10]