draft-ietf-tcpm-tcp-auth-opt-06.txt   draft-ietf-tcpm-tcp-auth-opt-07.txt 
TCPM WG J. Touch TCPM WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Obsoletes: 2385 A. Mankin Obsoletes: 2385 A. Mankin
Intended status: Proposed Standard Johns Hopkins Univ. Intended status: Proposed Standard Johns Hopkins Univ.
Expires: April 2010 R. Bonica Expires: April 2010 R. Bonica
Juniper Networks Juniper Networks
October 26, 2009 October 26, 2009
The TCP Authentication Option The TCP Authentication Option
draft-ietf-tcpm-tcp-auth-opt-06.txt draft-ietf-tcpm-tcp-auth-opt-07.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 35 skipping to change at page 2, line 35
of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is of TCP MD5 on a given TCP connection. TCP-AO supports IPv6, and is
fully compatible with the requirements for the replacement of TCP fully compatible with the requirements for the replacement of TCP
MD5. MD5.
Table of Contents Table of Contents
1. Contributors...................................................3 1. Contributors...................................................3
2. Introduction...................................................4 2. Introduction...................................................4
2.1. Executive Summary.........................................4 2.1. Executive Summary.........................................4
2.2. Changes from Previous Version.............................6 2.2. Changes from Previous Version.............................6
2.2.1. New in draft-ietf-tcp-auth-opt-06....................6 2.2.1. New in draft-ietf-tcp-auth-opt-07....................6
3. Conventions used in this document..............................6 2.2.2. New in draft-ietf-tcp-auth-opt-06....................6
3. Conventions used in this document..............................7
4. The TCP Authentication Option..................................7 4. The TCP Authentication Option..................................7
4.1. Review of TCP MD5 Option..................................7 4.1. Review of TCP MD5 Option..................................7
4.2. The TCP-AO Option.........................................8 4.2. The TCP-AO Option.........................................8
5. TCP-AO Keys and Their Properties..............................10 5. TCP-AO Keys and Their Properties..............................10
5.1. Master Key Tuple.........................................10 5.1. Master Key Tuple.........................................10
5.2. Traffic Keys.............................................12 5.2. Traffic Keys.............................................12
5.3. MKT Properties...........................................13 5.3. MKT Properties...........................................13
6. Per-Connection TCP-AO Parameters..............................14 6. Per-Connection TCP-AO Parameters..............................14
7. Cryptographic Algorithms......................................15 7. Cryptographic Algorithms......................................15
7.1. MAC Algorithms...........................................15 7.1. MAC Algorithms...........................................15
skipping to change at page 6, line 20 skipping to change at page 6, line 20
o TCP-AO does not authenticate ICMP messages (some ICMP messages may o TCP-AO does not authenticate ICMP messages (some ICMP messages may
be authenticated when using IPsec, depending on the be authenticated when using IPsec, depending on the
configuration). configuration).
2.2. Changes from Previous Version 2.2. Changes from Previous Version
[NOTE: to be omitted upon final publication as RFC; full changelist [NOTE: to be omitted upon final publication as RFC; full changelist
available from the authors] available from the authors]
2.2.1. New in draft-ietf-tcp-auth-opt-06 2.2.1. New in draft-ietf-tcp-auth-opt-07
o Change PRF to KDF throughout to coordinate with ao-crypto
2.2.2. New in draft-ietf-tcp-auth-opt-06
o Items from Stockholm IETF meeting o Items from Stockholm IETF meeting
o Unify MAC and PRF function notation with ao-crypto. o Unify MAC and KDF function notation with ao-crypto.
o Clarify that options are not included in TCP's advertised MSS. o Clarify that options are not included in TCP's advertised MSS.
o Clarify that segments not matching MKTs should be silently o Clarify that segments not matching MKTs should be silently
accepted. See Section 9.5 for details. accepted. See Section 9.5 for details.
o Clarify that MKTs can be used to derive 4 traffic keys, not o Clarify that MKTs can be used to derive 4 traffic keys, not
that all are always actually derived. that all are always actually derived.
o Emphasize that the KeyIDs MAY be the same in both directions. o Emphasize that the KeyIDs MAY be the same in both directions.
skipping to change at page 15, line 37 skipping to change at page 15, line 37
interface: interface:
MAC = MAC_alg(traffic_key, data_block) MAC = MAC_alg(traffic_key, data_block)
INPUT: MAC_alg, traffic_key, data_block INPUT: MAC_alg, traffic_key, data_block
OUTPUT: MAC OUTPUT: MAC
where: where:
o MAC_alg - MAC algorithm used for this computation. The MAC o MAC_alg - the specific MAC algorithm used for this computation.
algorithm specifies the output length, so no separate output The MAC algorithm specifies the output length, so no separate
length parameter is required. output length parameter is required. This is specified as
described in [ao-crypto].
o Traffic_key - traffic key used for this computation. This is o Traffic_key - traffic key used for this computation. This is
computed from the connection's current MKT as described in Section computed from the connection's current MKT as described in Section
7.2. 7.2.
o Data_block - input data over which the MAC is computed. In TCP-AO, o Data_block - input data over which the MAC is computed. In TCP-AO,
this is the TCP segment prepended by the TCP pseudoheader and TCP this is the TCP segment prepended by the TCP pseudoheader and TCP
header options, as described in Section 7.1. header options, as described in Section 7.1.
o MAC - the fixed-length output of the MAC algorithm, given the o MAC - the fixed-length output of the MAC algorithm, given the
skipping to change at page 18, line 30 skipping to change at page 18, line 30
MAC algorithm indicates how to use the traffic key, e.g., as HMACs do MAC algorithm indicates how to use the traffic key, e.g., as HMACs do
[RFC2104][RFC2403]. The traffic key is derived from the current MKT [RFC2104][RFC2403]. The traffic key is derived from the current MKT
as described in Sections 7.2. as described in Sections 7.2.
7.2. Key Derivation Functions 7.2. Key Derivation Functions
TCP-AO's traffic keys are derived from the MKTs using Key Derivation TCP-AO's traffic keys are derived from the MKTs using Key Derivation
Functions (KDFs). The KDFs used in TCP-AO have the following Functions (KDFs). The KDFs used in TCP-AO have the following
interface: interface:
traffic_key = PRF_alg(master_key, data_block, output_length) traffic_key = KDF_alg(master_key, data_block, output_length)
INPUT: PRF_alg, master_key, data_block, output_length INPUT: KDF_alg, master_key, data_block, output_length
OUTPUT: traffic_key OUTPUT: traffic_key
where: where:
o PRF_alg - the specific pseudorandom function (PRF) that is the o KDF_alg - the specific key derivation function (KDF) that is the
basic building block used in constructing the given KDF, as basic building block used in constructing the traffic key, as
indicated in the MKT. This is specified by the KDF as described in indicated in the MKT. This is specified as described in [ao-
[ao-crypto]. crypto].
o Master_key - The master_key string, as will be stored into the o Master_key - The master_key string, as will be stored into the
associated MKT. associated MKT.
o Data_block - The data block used as input in constructing the KDF. o Data_block - The data block used as input in constructing the
The data block provided by TCP-AO is used as the "context" as traffic_key. The data block provided by TCP-AO is used as the
specified in [ao-crypto]. The specific way this context is used, "context" as specified in [ao-crypto]. The specific way this
in conjunction with other information, to create the raw input to context is used, in conjunction with other information, to create
the PRF is also explained further in [ao-crypto]. the raw input to the KDF is also explained further in [ao-crypto].
o Output_length - The desired output length of the KDF, i.e., the o Output_length - The desired output length of the KDF, i.e., the
length to which the KDF's output will be truncated. In TCP-AO, the length to which the KDF's output will be truncated. This is
output_length is the PRF_truncation value of the MKT. This is specified as described in [ao-crypto].
specified by the KDF as described in [ao-crypto].
o Traffic_key - The desired output of the KDF, of length o Traffic_key - The desired output of the KDF, of length
output_length, to be used as input to the MAC algorithm, as output_length, to be used as input to the MAC algorithm, as
described in Section 7.1. described in Section 7.1.
The data used as input to the KDF combines TCP socket pair with the The data used as input to the KDF combines TCP socket pair with the
endpoint initial sequence numbers (ISNs) of a connection. This endpoint initial sequence numbers (ISNs) of a connection. This
provides context unique to each TCP connection instance, which provides context unique to each TCP connection instance, which
enables TCP-AO to generate unique traffic keys for that connection, enables TCP-AO to generate unique traffic keys for that connection,
even from a MKT used across many different connections or across even from a MKT used across many different connections or across
skipping to change at page 37, line 20 skipping to change at page 37, line 20
TCP-AO uses a default required algorithm as specified in [ao- TCP-AO uses a default required algorithm as specified in [ao-
crypto], as noted in Section 7.1. crypto], as noted in Section 7.1.
b. Good algorithms. b. Good algorithms.
The option should use algorithms considered accepted by the The option should use algorithms considered accepted by the
security community, which are considered appropriately safe. security community, which are considered appropriately safe.
The use of non-standard or unpublished algorithms should be The use of non-standard or unpublished algorithms should be
avoided. avoided.
TCP-AO uses MACs as indicated in [ao-crypto]. The PRF is also TCP-AO uses MACs as indicated in [ao-crypto]. The KDF is also
specified in [ao-crypto]. The PRF input string follows the specified in [ao-crypto]. The KDF input string follows the
typical design (see [ao-crypto]). typical design (see [ao-crypto]).
c. Algorithm agility. c. Algorithm agility.
The option should support algorithms other than the default, The option should support algorithms other than the default,
to allow agility over time. to allow agility over time.
TCP-AO allows any desired algorithm, subject to TCP option TCP-AO allows any desired algorithm, subject to TCP option
space limitations, as noted in Section 4.2. The use of set of space limitations, as noted in Section 4.2. The use of set of
MKTs allows separate connections to use different algorithms, MKTs allows separate connections to use different algorithms,
both for the MAC and the PRF. both for the MAC and the KDF.
d. Order-independent processing. d. Order-independent processing.
The option should be processed independently of the proper The option should be processed independently of the proper
order, i.e., they should allow processing of TCP segments in order, i.e., they should allow processing of TCP segments in
the order received, without requiring reordering. This avoids the order received, without requiring reordering. This avoids
the need for reordering prior to processing, and avoids the the need for reordering prior to processing, and avoids the
impact of misordered segments on the option. impact of misordered segments on the option.
This is supported - see Sections 9.3, 9.4, and 9.5. Note that This is supported - see Sections 9.3, 9.4, and 9.5. Note that
skipping to change at page 42, line 46 skipping to change at page 42, line 46
14. IANA Considerations 14. IANA Considerations
[NOTE: This section be removed prior to publication as an RFC] [NOTE: This section be removed prior to publication as an RFC]
The TCP-AO option defines no new namespaces. The TCP-AO option defines no new namespaces.
The TCP-AO option requires that IANA allocate a value from the TCP The TCP-AO option requires that IANA allocate a value from the TCP
option Kind namespace, to be replaced for TCP-IANA-KIND throughout option Kind namespace, to be replaced for TCP-IANA-KIND throughout
this document. this document.
To specify MAC and PRF algorithms, TCP-AO refers to a separate To specify MAC and KDF algorithms, TCP-AO refers to a separate
document that may involve IANA actions [ao-crypto]. document that may involve IANA actions [ao-crypto].
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC793] Postel, J., "Transmission Control Protocol," STD-7, [RFC793] Postel, J., "Transmission Control Protocol," STD-7,
RFC-793, Standard, Sept. 1981. RFC-793, Standard, Sept. 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts -- [RFC1122] Braden, R., "Requirements for Internet Hosts --
 End of changes. 13 change blocks. 
26 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/