draft-ietf-tsvwg-sctp-auth-02.txt   draft-ietf-tsvwg-sctp-auth-03.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: September 7, 2006 R. Stewart Expires: December 2, 2006 R. Stewart
P. Lei P. Lei
Cisco Systems, Inc. Cisco Systems, Inc.
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
March 6, 2006 May 31, 2006
Authenticated Chunks for Stream Control Transmission Protocol (SCTP) Authenticated Chunks for Stream Control Transmission Protocol (SCTP)
draft-ietf-tsvwg-sctp-auth-02.txt draft-ietf-tsvwg-sctp-auth-03.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 September 7, 2006. This Internet-Draft will expire on December 2, 2006.
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 7, line 40 skipping to change at page 7, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Figure 4
Cause Code: 2 bytes (unsigned integer) Cause Code: 2 bytes (unsigned integer)
This value MUST be set to 0x0105. This value MUST be set to 0x0105.
Cause Length: 2 bytes (unsigned integer) Cause Length: 2 bytes (unsigned integer)
This value MUST be set to 6. This value MUST be set to 6.
HMAC Identifier: 4 bytes (unsigned integer) HMAC Identifier: 2 bytes (unsigned integer)
This value is the HMAC Identifier which is not supported. This value is the HMAC Identifier which is not supported.
5. New Chunk Type 5. New Chunk Type
This section defines the new chunk type that will be used to This section defines the new chunk type that will be used to
authenticate chunks. Table 4 illustrates the new chunk type. authenticate chunks. Table 4 illustrates the new chunk type.
+------------+-----------------------------+ +------------+-----------------------------+
| Chunk Type | Chunk Name | | Chunk Type | Chunk Name |
+------------+-----------------------------+ +------------+-----------------------------+
skipping to change at page 10, line 25 skipping to change at page 10, line 25
Endpoints MUST send all requested chunks authenticated where this has Endpoints MUST send all requested chunks authenticated where this has
been requested by the peer. The other chunks MAY be sent been requested by the peer. The other chunks MAY be sent
authenticated or not. If endpoint pair shared keys are used, one of authenticated or not. If endpoint pair shared keys are used, one of
them MUST be selected for authentication. them MUST be selected for authentication.
To send chunks in an authenticated way, the sender MUST include these To send chunks in an authenticated way, the sender MUST include these
chunks after an AUTH chunk. This means that a sender MUST bundle chunks after an AUTH chunk. This means that a sender MUST bundle
chunks in order to authenticate them. chunks in order to authenticate them.
If the endpoint has no endpoint shared key for the peer, it MUST use
Shared Key Identifier 0 with an empty endpoint pair shared key.
The sender MUST calculate the MAC using the hash function H as The sender MUST calculate the MAC using the hash function H as
described by the MAC Identifier and the shared association key K described by the MAC Identifier and the shared association key K
based on the endpoint pair shared key described by the shared key based on the endpoint pair shared key described by the shared key
identifier. The 'data' used for the computation of the AUTH-chunk is identifier. The 'data' used for the computation of the AUTH-chunk is
given by Figure 6 and all chunks that are placed after the AUTH chunk given by Figure 6 and all chunks that are placed after the AUTH chunk
in the SCTP packet. RFC2104 [2] can be used as a guideline for in the SCTP packet. RFC2104 [2] can be used as a guideline for
generating the MAC. generating the MAC.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0F | Flags=0 | Chunk Length | | Type = 0x0F | Flags=0 | Chunk Length |
skipping to change at page 11, line 19 skipping to change at page 11, line 22
peer during the association setup. It MUST silently discard these peer during the association setup. It MUST silently discard these
chunks if they are not placed after an AUTH chunk in the packet. chunks if they are not placed after an AUTH chunk in the packet.
The receiver MUST use the HMAC algorithm indicated in the HMAC The receiver MUST use the HMAC algorithm indicated in the HMAC
Identifier field. If this algorithm was not specified by the Identifier field. If this algorithm was not specified by the
receiver in the HMAC-ALGO parameter in the INIT or INIT-ACK chunk receiver in the HMAC-ALGO parameter in the INIT or INIT-ACK chunk
during association setup, the AUTH chunk and all chunks after it MUST during association setup, the AUTH chunk and all chunks after it MUST
be discarded and an ERROR chunk SHOULD be sent with the error cause be discarded and an ERROR chunk SHOULD be sent with the error cause
defined in Section 4.1. defined in Section 4.1.
If the endpoint has no endpoint pair shared key for the peer, it MUST If an endpoint with no shared key receives a Shared Key Identifier
use an empty endpoint pair shared key regardless which Shared Key other than 0, it MUST silently discard all authenticated chunks. If
Identifier is present in the AUTH chunk. If the endpoint has at the endpoint has at least one endpoint pair shared key for the peer,
least one endpoint pair shared key for the peer, it MUST use the key it MUST use the key specified by the Shared Key Identifier if a key
specified by the Shared Key Identifier if a key has been configured has been configured for that Shared Key Identifier. If no endpoint
for that Shared Key Identifier. If no endpoint pair shared key has pair shared key has been configured for that Shared Key Identifier,
been configured for that Shared Key Identifier, all authenticated all authenticated chunks MUST be silently discarded.
chunks MUST be silently discarded.
The receiver now performs the same calculation as described for the The receiver now performs the same calculation as described for the
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
skipping to change at page 13, line 10 skipping to change at page 13, line 10
above. above.
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 above.
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 above.
9. Security Considerations 9. Security Considerations
If no endpoint pair shared key is used an attacker which captures the Without using endpoint shared keys this extensions only provides a
association setup message exchange can later insert arbitrary packets way of making sure that chunks being authenticated are received from
in an authenticated way. However, if the attacker did not capture the same peer the association was established with. If an attacker
this initial message exchange he can not successfully inject chunks captures the association setup he can insert arbitrary packets in an
which are required to be authenticated. authenticated way. But if the attacker does not capture the
association setup he can not inject packets.
If an enpoint pair shared key is used even a true man in the middle If an endpoint pair shared key is used even a true man in the middle
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. he intercepts the initial message exchange. The endpoint also knows
that it is accepting authenticated chunks from a peer who knows the
endpoint pair shared key.
The establishment of endpoint pair shared keys is out of scope of
this document. Other mechanisms can be used like using TLS or manual
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
 End of changes. 10 change blocks. 
20 lines changed or deleted 29 lines changed or added

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