SIPPING C. Jennings
Internet-Draft Cisco Systems
Expires: January 9, 2005 July 11, 2004
SIP Computational Puzzles
draft-jennings-sip-hashcash-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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.
This Internet-Draft will expire on January 9, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
SPAM has been a frustrating problem in communications and also in
SIP. Forcing the client requesting the service to perform a
calculation that limits the rate and increases the cost of requests
is one of the techniques that may help manage this problem. This
draft defines a way to allow a UAS to ask the UAC to compute a
computationally expensive hash based function and present the result
to the UAS.
This draft is a very incomplete and more of a sketch of a solution
than a final draft.
Jennings Expires January 9, 2005 [Page 1]
Internet-Draft SIP Puzzles July 2004
1. Introduction
This draft defines a mechanism for a proxy or UAS to request that a
UAC compute the solution to a puzzle. The puzzle is based on finding
a value called the pre-image that when hashed with SHA 1 results in a
specific value referred to as the image. The puzzle provides a
number, k, that indicates how how many bit of the pre-image have not
been provided, the pre-image with some of the bits replaced with 0,
and the image. The proxy or UAS can send a 419 response to a SIP
request and include a puzzle header that provides the puzzle to
compute. The UAC can compute a solution to this puzzle and resubmit
the request with the solution in the puzzle header.
2. Requirements
Allow a UAS to request a variable amount of work from a UAC.
Make sure this work cannot be used for attacking other systems.
3. Puzzles
The following is a non-normative way for a UAS or proxy to construct
a puzzle. The following strings are concatenated: 1) a secret that
only this device knows and would typically be a crypto random string
of bits; 2) the current time, rounded to the nearest minute; 3) the
URI of the request, the Call-ID, the From tags, and the branch tag
for a proxy or the To tag for a UAS. The string is hashed with SHA1
to form the pre-image. The pre-image is appended to the string
"z9hG4bK" and the SHA1 hash of this is computed to get the value of
the image. This concatenation is done so that this mechanism cannot
be used as a distributed computation to reverse arbitrary hashed
values. A value k indicates how many bits of the pre-image are to be
removed. The value k could be a configurable parameter or could be
dynamically discovered by the software based on how long a hash
should take and the speed of the computer it was running on. In the
latter case, the resulting software would automatically choose larger
values of k as the computer got faster. The low order k bits of the
pre-image are set to zero. The puzzle consists of k, the pre-image
(with the low order bits set to zero), and the image.
The normative definition of a puzzle is as follows. A puzzle is
three values, k, pre-image, and image. There MUST exist a value X
such that all but the k low order bits of X match the pre-image, and
the SHA 1 hash of the concatenation of "z9hG4bK" and X results in a
value that MUST be equal to the image. The value X is the solution
to the puzzle.
Jennings Expires January 9, 2005 [Page 2]
Internet-Draft SIP Puzzles July 2004
4. Semantics
A proxy or UAS MAY reject a request with a 419 status code and
request that a particular computation be performed. The puzzle is
constructed as described in section X.
A UAC that receives a 419 request must compute the result that
satisfies the challenge and resubmit the request with the computed
answer. If the UAC knows that it is routing the request through a
proxy that will compute the answer for the UAC, it MAY leave the
answer blank. A proxy that receives a request that contains a puzzle
but does not have a solution to the puzzle MAY compute the solution
and modify the header.
5. Example
6. Syntax
A new header called Puzzle carries the puzzle and solution
information. It has a parameter k that has the number of bits as a
text encoded number, a parameter p that carries the pre image base 64
encoded, and a parameter i that carries the image value base 64
encoded. The solution is put in the same header but the value of k
is 0 when it is a solution.
Example puzzle
Puzzle: k=10;p="XPokF1n0+NG6iwRcYzeXuETrtDo=";
i="XPokF1n0+NG6iwRcYzeXuETrtDo="
Example solution
Puzzle: k=0;p="XPokF1n0+NG6iwRcYzeXuETrtDo=";
i="XPokF1n0+NG6iwRcYzeXuETrtDo="
7. Security Considerations
TODO - many things left to do here.
E wants to send spam to A. Calls A, get challenge. Encourages
others to call E. When B calls E, E passes on the puzzle to B. B
solves it and sends result to E who sends it to A.
Jennings Expires January 9, 2005 [Page 3]
Internet-Draft SIP Puzzles July 2004
8. IANA
TODO - Define new header.
TODO - Define 419 status code.
9. Open Issues
Put puzzle in header or body?
10. References
10.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001.
10.2 Informational References
[4] Black, A., "http://www.hashcash.org/", June 2004.
Author's Address
Cullen Jennings
Cisco Systems
170 West Tasman Drive
MS: SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 902-3341
EMail: fluffy@cisco.com
Jennings Expires January 9, 2005 [Page 4]
Internet-Draft SIP Puzzles July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jennings Expires January 9, 2005 [Page 5]