draft-ietf-tsvwg-sctp-auth-03.txt   draft-ietf-tsvwg-sctp-auth-04.txt 
Network Working Group M. Tuexen Network Working Group M. Tuexen
Internet-Draft Muenster Univ. of Applied Sciences Internet-Draft Muenster Univ. of Applied Sciences
Expires: December 2, 2006 R. Stewart Intended status: Standards Track R. Stewart
P. Lei Expires: March 7, 2007 P. Lei
Cisco Systems, Inc. Cisco Systems, Inc.
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
May 31, 2006 September 3, 2006
Authenticated Chunks for Stream Control Transmission Protocol (SCTP) Authenticated Chunks for Stream Control Transmission Protocol (SCTP)
draft-ietf-tsvwg-sctp-auth-03.txt draft-ietf-tsvwg-sctp-auth-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 2, 2006. This Internet-Draft will expire on March 7, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes a new chunk type, several parameters and This document describes a new chunk type, several parameters and
procedures for SCTP. This new chunk type can be used to authenticate procedures for SCTP. This new chunk type can be used to authenticate
SCTP chunks by using shared keys between the sender and receiver. SCTP chunks by using shared keys between the sender and receiver.
skipping to change at page 2, line 22 skipping to change at page 2, line 22
3.3. Requested HMAC Algorithm Parameter (HMAC-ALGO) . . . . . . 5 3.3. Requested HMAC Algorithm Parameter (HMAC-ALGO) . . . . . . 5
4. New Error Cause . . . . . . . . . . . . . . . . . . . . . . . 7 4. New Error Cause . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Unsupported HMAC Identifier error cause . . . . . . . . . 7 4.1. Unsupported HMAC Identifier error cause . . . . . . . . . 7
5. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 7 5. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Authentication Chunk (AUTH) . . . . . . . . . . . . . . . 8 5.1. Authentication Chunk (AUTH) . . . . . . . . . . . . . . . 8
6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Establishment of an association shared key . . . . . . . . 9 6.1. Establishment of an association shared key . . . . . . . . 9
6.2. Sending authenticated chunks . . . . . . . . . . . . . . . 10 6.2. Sending authenticated chunks . . . . . . . . . . . . . . . 10
6.3. Receiving authenticated chunks . . . . . . . . . . . . . . 11 6.3. Receiving authenticated chunks . . . . . . . . . . . . . . 11
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. Three New Parameter Types . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . . 13 8.3. A New Error Cause . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 8.4. A New Table For HMAC Identifiers . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
SCTP uses 32 bit verification tags to protect itself against blind SCTP uses 32 bit verification tags to protect itself against blind
attackers. These values are not changed during the lifetime of an attackers. These values are not changed during the lifetime of an
SCTP association. SCTP association.
Looking at new SCTP extensions there is the need to have a method of Looking at new SCTP extensions there is the need to have a method of
proving that an SCTP chunk(s) was really sent by the original peer proving that an SCTP chunk(s) was really sent by the original peer
that started the association and not by a malicious attacker. that started the association and not by a malicious attacker.
skipping to change at page 3, line 30 skipping to change at page 3, line 30
sender and receiver. The receiver can then verify that the chunks sender and receiver. The receiver can then verify that the chunks
are sent from the sender and not from a malicious attacker. are sent from the sender and not from a malicious attacker.
This extension also provides a mechanism for deriving a shared key This extension also provides a mechanism for deriving a shared key
for each association. This association shared key is derived from for each association. This association shared key is derived from
endpoint pair shared keys, which are preconfigured and might be endpoint pair shared keys, which are preconfigured and might be
empty. empty.
2. Conventions 2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
they appear in this document, are to be interpreted as described in "OPTIONAL", when they appear in this document, are to be interpreted
RFC2119 [3]. as described in RFC2119 [3].
3. New Parameter Types 3. New Parameter Types
This section defines the new parameter types that will be used to This section defines the new parameter types that will be used to
negotiate the authentication during association setup. Table 1 negotiate the authentication during association setup. Table 1
illustrates the new parameter types. illustrates the new parameter types.
+----------------+------------------------------------------------+ +----------------+------------------------------------------------+
| Parameter Type | Parameter Name | | Parameter Type | Parameter Name |
+----------------+------------------------------------------------+ +----------------+------------------------------------------------+
skipping to change at page 11, line 41 skipping to change at page 11, line 41
sender based on Figure 6. If the result of the calculation is the sender based on Figure 6. If the result of the calculation is the
same as given in the HMAC field, all chunks following the AUTH chunk same as given in the HMAC field, all chunks following the AUTH chunk
are processed. If the field does not match the result of the are processed. If the field does not match the result of the
calculation, all the chunks following the AUTH chunk MUST be silently calculation, all the chunks following the AUTH chunk MUST be silently
discarded. discarded.
It should be noted that if the receiver wants to tear down an It should be noted that if the receiver wants to tear down an
association in an authenticated way only, the handling of malformed association in an authenticated way only, the handling of malformed
packets should be in tune with this. packets should be in tune with this.
If the receiver does not find a TCB for a packet containing an AUTH
chunk as a first chunk and a COOKIE-ECHO chunk as the second chunk
and possibly more chunks after them, the receiver MUST authenticate
the chunks by using the random numbers included in the COOKIE-ECHO,
and possibly the local shared secret. If authentication fails then
the packet discarded. If the authentication is successful the
COOKIE-ECHO and all chunks after the COOKIE-ECHO MUST be processed.
If the receiver has a TCB, it MUST process the AUTH chunk as
described above using the TCB from the existing association to
authenticate the COOKIE-ECHO chunk and all chunks after it.
If the receiver does not find an association for a packet containing
an AUTH chunk as the first chunk and not a COOKIE-ECHO chunk as the
second chunk, it MUST use the chunks after the AUTH chunk to look up
an existing association. If no association is found, the packet MUST
be considered as out of the blue. The out of the blue handling MUST
be based on the packet without taking the AUTH chunk into account.
If an association is found, it MUST process the AUTH chunk using the
TCB from the existing association as described earlier.
If the receiver of the packet does not have a TCB when it needs to If the receiver of the packet does not have a TCB when it needs to
process the AUTH chunk, it MUST ignore the AUTH chunk. This applies process the AUTH chunk, it MUST ignore the AUTH chunk. This applies
to a packet containing an AUTH chunk as a first chunk and an COOKIE- to a packet containing an AUTH chunk as a first chunk and an COOKIE-
ECHO chunk as the second chunk received in the CLOSED state. If the ECHO chunk as the second chunk received in the CLOSED state. If the
receiver has a TCB, it MUST process the AUTH chunk as described receiver has a TCB, it MUST process the AUTH chunk as described
above. above.
It should also be noted that if an endpoint accepts ABORT chunks only It should also be noted that if an endpoint accepts ABORT chunks only
in an authenticated way, it may take longer to detect that the peer in an authenticated way, it may take longer to detect that the peer
is no longer available. If an endpoint accepts COOKIE chunks only in is no longer available. If an endpoint accepts COOKIE chunks only in
an authenticated way, the restart procedure does not work. an authenticated way, the restart procedure does not work.
Furthermore it is important that the cookie contained in an INIT-ACK
chunk and in a COOKIE_ECHO chunk MUST NOT contain the end-point pair
shared key.
7. Examples 7. Examples
This section gives examples of message exchanges for association This section gives examples of message exchanges for association
setup. setup.
The simplest way of using the extension described in this document is The simplest way of using the extension described in this document is
given by the following message exchange. given by the following message exchange.
---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ----------> ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
<------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] --------- <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
skipping to change at page 12, line 43 skipping to change at page 13, line 20
notification followed by the presentation of the endpoint pair shared notification followed by the presentation of the endpoint pair shared
key by the upper layer to the SCTP stack) and the processing of the key by the upper layer to the SCTP stack) and the processing of the
AUTH and DATA chunk. If this intervention is not possible due to AUTH and DATA chunk. If this intervention is not possible due to
limitations of the API the server might discard the AUTH and DATA limitations of the API the server might discard the AUTH and DATA
chunk making a retransmission of the DATA chunk necessary. If the chunk making a retransmission of the DATA chunk necessary. If the
same endpoint pair shared key is used for multiple endpoints and does same endpoint pair shared key is used for multiple endpoints and does
not depend on the client this intervention might not be necessary. not depend on the client this intervention might not be necessary.
8. IANA Considerations 8. IANA Considerations
[NOTE to RFC-Editor:
"RFCXXXX" is to be replaced by the RFC number you assign this
document.
The reference to sctp-parameters [7] should be removed from the
"Normative References" section after the IANA section has been
removed.
]
This document (RFCXXX) is the reference for all registrations
described in this section. All registrations need to be listed in
the document available at sctp-parameters [7]. The suggested changes
are described below.
8.1. A New Chunk Type
A chunk type for the AUTH chunk has to be assigned by IANA. It is A chunk type for the AUTH chunk has to be assigned by IANA. It is
suggested to use the value given above. suggested to use the value given in Table 4. This requires an
additional line in the "CHUNK TYPES" table of sctp-parameters [7]:
CHUNK TYPES
ID Value Chunk Type Reference
----- ---------- ---------
15 Authentication Chunk (AUTH) [RFCXXXX]
8.2. Three New Parameter Types
Parameter types have to be assigned for the RANDOM, CHUNKS, and HMAC- Parameter types have to be assigned for the RANDOM, CHUNKS, and HMAC-
ALGO parameter by IANA. It is suggested to use the values given ALGO parameter by IANA. It is suggested to use the values given in
above. Table 1. This requires two modifications of the "CHUNK PARAMETER
TPYES" tables in sctp-parameters [7]: The first change is the
addition of three new lines to the "INIT Chunk Parameter Types"
table:
Chunk Parameter Type Value
-------------------- -----
Random 32770 (0x8002)
Chunk List 32771 (0x8003)
Requested HMAC Algorithm Parameter 32772 (0x8004)
The second required change is the addition of the same three lines to
the to the "INIT ACK Chunk Parameter Types" table.
8.3. A New Error Cause
An error cause for the Unsupported HMAC Identifier error cause has to An error cause for the Unsupported HMAC Identifier error cause has to
be assigned. It is suggested to use the value given above. be assigned. It is suggested to use the value given in Table 3.
This requires an additional line of the "CAUSE CODES" table in sctp-
parameters [7]:
VALUE CAUSE CODE REFERENCE
----- ---------------- ---------
261 (0x0105) Unsupported HMAC Identifier RFCXXXX
8.4. A New Table For HMAC Identifiers
HMAC Identifiers have to be maintained by IANA. Three initial values HMAC Identifiers have to be maintained by IANA. Three initial values
should be assigned by IANA as described above. should be assigned by IANA as described in Table 2. This requires a
new table "HMAC IDENTIFIERS" in sctp-parameters [7]:
HMAC Identifier Message Digest Algorithm REFERENCE
--------------- ------------------------ ---------
0 Reserved RFCXXXX
1 SHA-1 RFCXXXX
2 MD-5 RFCXXXX
9. Security Considerations 9. Security Considerations
Without using endpoint shared keys this extensions only provides a Without using endpoint shared keys this extensions only provides a
way of making sure that chunks being authenticated are received from way of making sure that chunks being authenticated are received from
the same peer the association was established with. If an attacker the same peer the association was established with. If an attacker
captures the association setup he can insert arbitrary packets in an captures the association setup he can insert arbitrary packets in an
authenticated way. But if the attacker does not capture the authenticated way. But if the attacker does not capture the
association setup he can not inject packets. association setup he can not inject packets.
skipping to change at page 13, line 28 skipping to change at page 15, line 18
can not inject chunks which are required to be authenticated even if can not inject chunks which are required to be authenticated even if
he intercepts the initial message exchange. The endpoint also knows he intercepts the initial message exchange. The endpoint also knows
that it is accepting authenticated chunks from a peer who knows the that it is accepting authenticated chunks from a peer who knows the
endpoint pair shared key. endpoint pair shared key.
The establishment of endpoint pair shared keys is out of scope of The establishment of endpoint pair shared keys is out of scope of
this document. Other mechanisms can be used like using TLS or manual this document. Other mechanisms can be used like using TLS or manual
configuration. configuration.
Because SCTP has already a mechanism built-in that handles the Because SCTP has already a mechanism built-in that handles the
reception of duplicated chunks the presented solution makes use of reception of duplicated chunks, the presented solution makes use of
this functionality and does not provide a method to avoid replay this functionality and does not provide a method to avoid replay
attacks by itself. Of course, this only works within each SCTP attacks by itself. Of course, this only works within each SCTP
association. Therefore a separate shared key is used for each SCTP association. Therefore a separate shared key is used for each SCTP
association to handle replay attacks covering multiple SCTP association to handle replay attacks covering multiple SCTP
associations. associations.
10. Acknowledgments 10. Acknowledgments
The authors wish to thank Sascha Grau, Ivan Arias Rodriguez, and The authors wish to thank Sascha Grau, Ivan Arias Rodriguez, and
Irene Ruengeler for their invaluable comments. Irene Ruengeler for their invaluable comments.
skipping to change at page 15, line 5 skipping to change at page 16, line 7
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[5] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer [5] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436, Security over Stream Control Transmission Protocol", RFC 3436,
December 2002. December 2002.
[6] National Institute of Standards and Technology, "Secure Hash [6] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995, Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>. <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[7] <http://www.iana.org/assignments/sctp-parameters>
Authors' Addresses Authors' Addresses
Michael Tuexen Michael Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
skipping to change at page 16, line 5 skipping to change at page 17, line 5
Eric Rescorla Eric Rescorla
RTFM, Inc. RTFM, Inc.
2064 Edgewood Drive 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Phone: +1 650-320-8549 Phone: +1 650-320-8549
Email: ekr@rtfm.com Email: ekr@rtfm.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 16, line 29 skipping to change at page 17, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 (2006). 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 18 change blocks. 
38 lines changed or deleted 124 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/