[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(IPng) Suggested modifications to the AH I-D (long)
- To: ipng@sunroof
- Subject: (IPng) Suggested modifications to the AH I-D (long)
I propose the following changes to the current version of the IPv6
Authentication Header I-D [draft-ietf-ipngwg-sec-00.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 3, 1st para., section 2 - modify to read -
'Key management is an important part of the IPv6 security
architecture. IPv6 tries to decouple the key management mechanisms
from the security protocol mechanisms. The only coupling between
the key management protocol and the security protocol is with the
Security Association Identifier (SAID) and with optional fields within
the authentication data, which are described in more detail below.
This decoupling permits several different key management mechanisms
to be used. More importantly, it permits the key management protocol
to be changed or corrected without unduly impacting the security
protocol implementations.'
Reasons for this change - to support in-band keying, the coupling between
the security protocol and the key management protocol could also depend
on data carried by the packet in the authentication field.
page 4, para. 1, section titled "Security Association Identifier (SAID) -
modify 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). The combination of SAID value, optional
fields within the authentication data, and destination address uniquely
identifies the security association. The destination address may, of
course, be a multicast group address.
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 6, para. 1, section 4 - modify the first sentence to read :
When not carrying in-band data, the authentication data is usually
calculated using a message digest algorithm (e.g. MD5) either encrypting
that message digest or keying the message digest directly.
Reason for this change - the conditional at the beginning of the sentence
clarifies that the authentication data field may carry additional key
management specific information.
page 7, after para. 6, section 4 - insert the following text.
'When the SAID value indicates in-band keying, the format of the
authentication header is as follows :
+--------------+-----------------+----------------+------------+
| Next Payload | Length | RESERVED |
+--------------+-----------------+----------------+------------+
| Security Association Identifier (=0x00...1) |
+--------------+---------------+----------------+--------------+
|Key Management| Key Management Info |
| ID | |
+--------------+-----------------+----------------+------------+
| Key Management Info (variable length) |
+--------------+---------------+----------------+--------------+
The key management ID specifies the format of the remaining data in the
Authentication Header. Key management IDs are allocated by the Internet
Assigned Numbers Authority (IANA). The remaining information in the
authentication data field 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 AH. 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. 1, section 5 - modify to read
Implementations that claim conformance or compliance with this
specification MUST fully implement the option described here,
and MUST support the use of keyed MD5 as described in Appendix A of
this document. Either host-to-host manual key distribution or user-
to-user manual key distribution MAY be used with this option.
Support for other authentication algorithms is not mandatory to
comply or conform with this specification. Implementors
should consult the most recent version of the IAB Official Standards
document for further guidance on the status of this document.
Reason for the change - Requiring all implementations to support user-to-user
key distribution is onerous and unnecessary. Threats against encrypted
communications based on widely know cryptanalytic techniques, such as
differential or linear cryptanalysis can be thwarted by judicious rekeying
of the communications key variables. User-to-user key distribution is
another way to achieve protection in this regard, but is difficult to
implement for some key management schemes.
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 -----