[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ISAKMP-09 Changes
I have submitted a revised version of the ISAKMP Internet-Draft
(ISAKMP-09) to the WG chairs and the Internet-Drafts folks. I expect it
will show up whenever they get around to it. I will send additional
e-mails to the IPSEC list containing the PostScript and ASCII Text
versions. In the meantime, the changes made are as follows:
ISAKMP - Changes made from 08 to 09
-----------------------------------
NOTE: All of the following changes were made with an attempt to not
cause significant changes to current ISAKMP implementations. If any of
these changes impact you adversely, please post your complaints to the
IPSEC list and let's get them cleared up as soon as possible.
Section 1
---------
1.1 Removed requirements terminology; Point to RFC 2119
1.5 Addition of clarifying text associated with passwords
Rationale: Result of IAB Security Architecture Workshop
(David Jablon - 22 Mar 97 e-mail)
1.7.1 Additional text to clarify denial of service protection
(Angelos Keromytis - 4 Mar 98 e-mail)
Section 2
---------
2.2 Addition of Key Exchange Definition to ISAKMP Relationships Diagram
Rationale: Clarity and completeness
2.2 Addition of API to ISAKMP Relationships Diagram
Rationale: Clarity and completeness
2.4 Clarification of location of SPI field
It's in the Proposal payload, not in the ISAKMP Header
(Eric Wong - 23 Jan 98 e-mail)
Section 3
---------
3.1 Addition of Vendor ID Payload Type
(More detail below under section 3.16)
3.1 Addition of text to Flags field description
Remaining bits MUST be set to zero
Rationale: Processing Efficiency; Clarity
(Richard Waterhouse - 27 Aug 97 e-mail)
3.1 Addition of Authentication Bit to Flags field of ISAKMP Header
Rationale: Use with Info Exch - Notify without encryption
(Discussed at Munich IETF)
3.1 Clarifying text to the Message-ID field in the event of collisions
(Robert Tashjian - 10 Oct 97 e-mail - raised issue)
(Roy Shamir - 12 Oct 97 e-mail)
(Dan Harkins - 13 Oct 97, 14 Oct 97 e-mails)
(Shin Yoshida - 14 Oct 97 e-mail)
3.1 Added pointer to IKE for discussion about encryption expansion
(Ben Rogers - 12 Sep 97 e-mail)
3.3 Clarification of Attribute Type field of Data Attributes
(Tero Kivinen - 3 Mar 98 e-mail)
3.3 Removal of requirement for byte alignment of Attribute Value field
(Matt Thomas - 18 Feb 98 e-mail)
(John Burke - 19 Feb 98 e-mail)
(Matt Thomas - 2 Mar 98 e-mail)
(Tero Kivinen - 3 Mar 98 e-mail)
3.4 Clarifying text about the presence of the DOI and Situation field
They MUST be present in all SA payloads.
Rationale: Processing efficiency; Clarity; Remove possible complexity
(Richard Waterhouse - 27 Aug 97 e-mail)
3.4 Additional text in DOI field description about IANA values
Rationale: Clarify who assigns value and how they do it
(Ran Atkinson - 17 Sep 97 e-mail)
3.4 Additional text in DOI field description for Generic ISAKMP SAs
DOI value of 0 = Generic ISAKMP SA, DOI value of 1 = IPSEC SA
Rationale: Provides for Generic and Specific ISAKMP SA and will
allow future inclusion of other protocol-specific SAs
(Ben Rogers - 14 Oct 97 e-mail)
(ISAKMP_IKE+DOI Reading Party comments - 11 Dec 97 e-mail)
(Dan Harkins - 23 Dec 97 e-mail)
(Dan Harkins - 18 Feb 98 e-mail)
3.5 Additional text to describe the Payload Length of Proposal Payload
Rationale: Clarity about what goes into this field
(Hugh Redelmeier - 23 Feb 98 e-mail)
3.5 Clarification of SPI Size field of Proposal payload
Rationale: Clarify the value of field in Phase 1 and Phase 2
(John Burke - 10 Sep 97 e-mail)
(Dan Harkins - 11 Sep 97 e-mail)
3.6 Clarification of Transform payload description
(Matt Thomas - 29 Sep 97 e-mail)
3.8 Changed RESERVED2 field to be DOI specific ID data
Rationale: Maps to IPSEC DOI and future DOIs
(Hugh Redelmeier - 23 Feb 98 e-mail)
3.9 Added X.509 Attribute Certificate Type for Certificate payload
(David Kemp - 8 Oct 97 e-mail - requesting change)
(Roy Pereira - 8 Oct 97 e-mail - agreed with addition)
(Greg Carter - 8 Oct 97 e-mail - also agreed with addition)
3.10 Clarifying text and change of payload format for the Certificate
Request payload.
Rationale: Improve parsing and clarity of payload use
(Discussed at Munich IETF)
(Tyler Allison - 14 Jan 98 e-mail)
(Tero Kivinen - 19 Feb 98 e-mail)
3.14 Clarification on alignment of SPI w/respect to Notification Data
SPI is not 4-octet boundary aligned.
(Matt Thomas - 29 Sep 97 e-mail)
3.14 Clarification of values for DOI field of Notify Payload
Rationale: Clarity and completeness
(Hugh Redelmeier - 23 Feb 98 e-mail)
3.14 Clarification of values for SPI Size field of Notify Payload
Rationale: Clarity
(John Burke - 19 Feb 98 e-mail)
3.14.1 Notify Message Types - Added NOTIFY-SA-LIFETIME notify message
Rationale: Used to inform peer of different SA lifetime value
(John Burke - 30 Sep 97 e-mail - agreed to adding Notify code)
(Derrell Piper - 30 Sep 97 e-mail)
(Dan Harkins - 11 Nov 97 e-mail)
3.14.1 Notify Message Type Codes
Changed to be consistent with DOI
(John Burke - 19 Feb 98 e-mail)
3.14.1 Notify Message Type Codes - Certificate Request related
Added (28) and changed (21) Notify message Type codes
(Tero Kivinen - 3 Mar 98 e-mail)
(Elfed Weaver - 5 Mar 98 e-mail)
(Michael Richardson - 4 Mar & 6 Mar 98 e-mails)
3.15 Clarification of values for DOI field of Delete Payload
Rationale: Clarity and completeness
(Hugh Redelmeier - 23 Feb 98 e-mail)
3.16 New Section - Vendor ID Payload
(Dan Harkins - 1 Oct 97 e-mail)
(Michael Richardson - 13 Oct 97 e-mail - THANKS for the text!)
(Dan Harkins - 18 Feb 98, 22 Feb 98 e-mails)
(Tero Kivinen - 19 Feb 98 e-mail)
(Derrell Piper - 20 Feb 98 e-mail)
Section 4
---------
4 Moved 4.3 to 4.1, 4.1 to 4.2, 4.2 to 4.3
(This was done to provide a better ordering of things)
4.1 Added clarifying text to the ordering of payloads
(new) (Ben Rogers - 11 Sep 97 e-mail - requested mandating)
(Dan Harkins - 11 Sep 97 e-mail - agreed with mandating)
(Tero Kivinen - 12 Sep 97 e-mail - won't make a difference)
(Greg Carter - 12 Sep 97 e-mail - doesn't matter)
(John Burke - 12 Sep 97 e-mail - think before acting)
(Ben Rogers - 12 Sep 97 e-mail - reduce processing/complexity)
(John Burke - 1 Oct 97 e-mail)
4.2 Added clarifying text to end of first paragraph about the
(new) relationship between the SA, Proposal, and Transform payloads.
ISAKMP will remain flexible in its expression of these payloads,
while IKE and other "users" of ISAKMP can constrain as desired.
Rationale: ISAKMP is the framework protocol and as such will
remain as flexible as possible for both phases of negotiation.
(Alexei Vopilov - 22 Dec 97 e-mail)
(John Burke - 23 Dec 97 e-mail)
(Dan Harkins - 30 Dec 97 e-mail)
4.3 Added clarifying text to Modification of a Protocol SA (phase 2)
(new) Rationale: Unclear wording on how to handle traffic on an old SA
(Scott Kelly - 8 Jan 98 e-mail)
4.7 Clarification of Proposal and Transform payloads sent in an
Aggressive Exchange
4.8 Added clarifying text for IVs w/respect to Info Exchange
Ensures independence of Info Exchange IV and other IVs
(Discussed at Munich IETF)
(Ruth Taylor{NSA} - personal communication)
(Greg Carter - 28 Sep 97 e-mail)
(Tylor Allison - 15 Jan 98 e-mail)
Section 5
---------
5 (all) Clarification of wording associated with logging events to the
appropriate system audit file, i.e. is logged --> MAY be logged
5 (all) Clarification of when a message is discarded and when only a
payload is discarded
(Tero Kivinen - 3 Mar 98 e-mail)
5.4 Moved 5.4.1 to 5.5 and 5.4.2 to 5.6; all other sections of 5
are increased by 2, i.e. 5.X = 5.X+2 for X > 4
5.6 Clarification of Transform Processing - Invalid vs. Unknown
(new) (Matt Thomas - 29 Sep 97 e-mail)
5.10 Changed payload processing wording to match new payload format
Added 1 and changed 1 Notify message
(Tero Kivinen - 3 Mar 98 e-mail)
(Elfed Weaver - 5 Mar 98 e-mail)
(Michael Richardson - 6 Mar 98 e-mail)
5.14 Clarification of transmission of Notify Payload in an
(new) Informational Exchange rather than appended to an existing exchange
(Tylor Allison - 15 Jan 98 e-mail)
5.14 Addition of text clarifying processing of Notify Payload when
(new) protected using the Authentication Only Bit
(Tom Markham - 2 Mar 98 e-mail)
Appendix A
----------
A Sections renumbered - A.2 deleted, A.2.1 -> A.2, A.2.2 -> A.3
and A.4 is new
Rationale: Separation of information into different sections
A.3 Clarification on security protocols values and IANA assignment
(new) Rationale: Correct number space assignment
(Ran Atkinson - 17 Sep 97 e-mail)
A.4 Inclusion of values for ID Types for a Generic ISAKMP SA
Taken from DOI section 4.6.2.* - Thanks Derrell
(See third 3.4 change section above for contributors)
IANA Considerations
-------------------
Added new section to conform to requirements of IESG
Bibliography
------------
Updated reference to DNSSEC
Added reference to IAB Security Architecture Workshop
Updated reference to IPSEC DOI
Changed IO-RES to IKE; Updated reference to IKE (throughout document)
Added reference to RFC-2119
Addresses of Authors
--------------------
Changed Jeff Turner's address information