[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(IPng) Modifications to the ESP I-D (long)
- To: ipng@sunroof
- Subject: (IPng) Modifications to the ESP I-D (long)
I propose the following changes to the current version of the IPv6
Encapsulating Security Payload I-D [draft-ietf-ipngwg-esp-0a.txt]. I
acknowledge that the exact phrasing of the change is a matter for the editor
to decide. I provide suggested wording only to make clear the substantive
changes I am suggesting. In addition, I am open to other proposals, such as
the one suggested by Russ Housley, that would allow the use of in-band
keying with IPv6. I am sending this out now so that we have at least one
concrete proposal to discuss in Danvers.
page 4, para. 2, section 3.1 - change to read :
A 32-bit pseudo-random value identifying the security association
for this datagram. If no security association has been established,
the value of this field shall be 0x00000000. If in-band keying is
employed, this field shall be 0x00000001. The set of SAID values
in the range 0x00000002 through 0x000000FF are reserved for future
use. A security association is normally one-way. An authenticated
communications session between two hosts will normally have two SAIDs
in use (one in each direction).
Reason for this change - To indicate in-band keying requires an SAID that is
not a legal pre-established value. I chose the value 1 arbitrarily and would
be open to some other value that is now reserved.
page 4, para. 4, section 3.1 - change to read :
Senders to a multicast group may share a common SAID for all
communications if all communications are authenticated using the same
security configuration parameters (e.g. algorithm, key, security
classification level, etc.). In this case, the receiver only knows
that the message came from a host knowing the security association
data for the group and cannot authenticate which member of the group
sent the datagram. Multicast groups may also use a separate SAID for
each sender. In any event, the combination of Destination Address,
optional fields within the synchronization data and the
SAID is used to determine the correct security association data. If
each sender is keyed separately and asymmetric algorithms are used,
data origin authentication is also a provided service.
Reason for this change - The presence of the optional in-band keying fields
within the synchronization data would be additional information necessary to
determine the correct security association data.
page 5, para. 5, section 3.1 - change to read :
Each SAID value, optional fields within the synchronization data and
the destination address imply the key(s) used to encrypt and decrypt the
encrypted portion of the ESP payload, the sensitivity level (e.g.
Secret, Unclassified) of the user data in the ESP payload, the
encryption algorithm being used, the block size (if any) of the
encryption algorithm, the authentication algorithm being used (if
separate from the encryption algorithm), the block size (if any) of
the authentication algorithm, and the presence/absence and size of a
cryptographic synchronisation or initialisation vector field at the
start of the encrypted portion of the ESP (if no such field is
present, then the size is of course zero).
Reason for this change - same as those given in the previous callout.
page 5, para. 5, section 3.1 - change to read :
The sending host uses the sending userid and destination host to
select an appropriate Security Association (and hence SAID value).
The receiving host uses the combination of SAID value, optional fields
within the synchronization data, and originating address to distinguish
the correct association.
Reason for this change - same as those givin in the previous two callouts.
Also, the last sentence is removed since it is redundant.
page 5, para. 6, section 3.1 - change to read :
This field is present only for algorithms which require a
cryptographic synchronisation field for each packet and for
carrying in-band keying information, if present. The value of
this field is arbitrary. The length of this field is variable, though
for any given algorithm it has a particular known length. It is
considered to be plaintext in this document, though most users will
not be able to make sense of its contents. Its presence or absence
are constant for all secure datagrams of any given SAID
value. The ESP specification includes this field so that the payload
specification will be independent of the cryptographic algorithm that
is being used by the communicating systems. If present, the field
contains cryptographic synchronisation data, such as a DES
Initialisation Vector, for whichever algorithm is in use [ISO92b]
or it contains in-band keying data. An ESP implementation will normally
use the Security Association Identifier value for the payload being
processed to determine whether this field is present and to determine
the field's size and use if present.
Reason for this change - The text indicates that the synchronization data
may carry in-band keying data.
page 5, after para. 6, section 3.1 - add the following text :
When the SAID value indicates in-band keying, the synchronization data
field carries Key Management method specific information, In that
case the format of the Encapsulating Security Payload is as follows :
+--------------+---------------+----------------+--------------+
| Security Association Identifier (=0x00...1) |
+--------------+---------------+----------------+--------------+
|Key Management| Key Management Info |
| ID | |
+--------------+-----------------+----------------+------------+
| Key Management Info (variable length) |
+--------------+---------------+----------------+--------------+
| Encrypted Data |
+--------------+---------------+----------------+--------------+
The key management ID specifies the format of the remaining data in the
Encapsulating Security Payload. Key management IDs are allocated by the
Internet Assigned Numbers Authority (IANA). The remaining information in the
synchronization data is formated according to rules specific to
the indicated Key Management protocol. Each Key Management protocol
is defined in a separate RFC.
Reason for the change - This additional format information is necessary
to support in-band keying within the ESP. It allows the specification of
new in-band key management protocols as they are developed by only
specifying a Key Management ID and leaving the format of the remaining
information to be specified in a separate RFC.
page 7, para. 2, section 4.1 - change to read :
The receiver strips off the cleartext IPv6 header and cleartext
optional IPv6 payloads (if any) and discards them. It then uses the
combination of Destination Address, optional information within the
synchronization data and SAID value to obtain the correct decryption
key to use for this packet. Then, it decrypts the ESP using the
session key that has been established for this traffic.
Reason for this change - The presence of the optional in-band keying fields
within the synchronization data would be additional information necessary to
determine the correct decryption key.
page 8, para. 2, section 4.2 - change to read :
The receiver processes the cleartext IPv6 header and cleartext
optional IPv6 headers (if any) and temporarily stores pertinent
information (e.g. source and destination addresses, Flow ID, Routing
Header). It then decrypts the ESP using the session key that has been
established for this traffic, using the combination of the destination
address, optional information within the synchronzation data and the
packet's Security Association Identifier (SAID) to locate the correct key.
Reasons for this change - same as those given in the previous callout.
page 10, para. 4, section 7 - change to read :
If user-to-user keying is not in use, then the algorithm in use
should not be vulnerable to any kind of Chosen Plaintext attack.
A Chosen Plaintext attack on DES is described in [BS93]. Use of
user-to-user keying is one way to preclude any sort of
Chosen Plaintext attack and to generally make cryptanalysis more
difficult. Another is to change the session key with sufficient
frequency that deprives the cryptoanalyst of enough plaintext/
ciphertext pairs to carry out an effective attack.
Reasons for this change - Since user-to-user keying is only one way to
address problems arising from cryptoanalytic attacks, alternative
methods should be mentioned.
Dan Nessett
------------------------------------------------------------------------------
IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng
Unsubscribe: unsubscribe ipng (as message body, not subject)
Direct all administrative requests to majordomo@sunroof.eng.sun.com
----- End Included Message -----