Bill, Why you are dwelling on the past: >I just went back and re-read the messages from March 20, >1995, where I proposed the term Security Parameters Index ... So ... >For good or ill, I proposed the term, wrote the list text, >and the first internet-drafts. It's a matter of record. Perhaps ... As best I remember, SPI was invented because SAID was already the common terminology for this mechanism and inventing a new term allowed the creation of a new definition without having to harmonize the usage with existing conventions. If we are looking for historical attribution, all of the concepts for SPIs or SAIDs were invented in the late 80's. I'd like to think that I was the first to propose the use of a recipient unique index for SAIDs/SPIs in 1987 (or was it 88), but who cares about attribution. I vaguely remember the meeting where the term Security Association was coined, I suspect it was by Mike White or Tom Markham. SAs were defined in exceeding fine detail by the SILS working group in IEEE. SWIPE and Photuris both stole many concepts from the ISO specification for NLSP. Much of the early groundwork was defined in the "dual versus single catenet" paper (Dave Golber) in 1983. Later work by Ruth Nelson (and others at GTE) helped replace the catenet models . >Once upon a time, we called all the KMPs "Security Association >Management Protocols" (SAMP). No ... in ipsec, we first called our placeholder for a key management specification the Internet Key Management Protocol (IKMP). SAMP was a specific complete proposal that was distributed to the working group. SAMP was rejected because it was written in an ISO style and used ASN.1. ISAKMP was partly derived from SAMP by replacing the ASN.1. SAMP was derived from the SDNS Key Management Protocol (KMP). What's that old adage about "building on the shoulders of others...". >But there you have it, a little bit of history.... Bill your retelling of history reminds me of the movie "Rashomon" (Akira Kurosawa, 1950). For those on the list that have not seen it, there is a detailed review at http://www.voyagerco.com/criterion/indepth.cgi?rashomon). We all have our own subjective view of history. The bandwidth of this mailing list would be better spend on constructive discussions that move us forward. Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- BEGIN included message
- To: ipsec@tis.com
- Subject: Security Association vis a vis Security Parameters Index
- From: "William Allen Simpson <wsimpson@greendragon.com>" <owner-ipsec@portal.ex.tis.com>
- Date: 10 Jul 97 17:20:49
- Sender: owner-ipsec@ex.tis.com
I was starting to send a nice private thank you to Atkinson for his well written earlier message, but then I read this one: > From: Randall Atkinson <atkinson@itd.nrl.navy.mil> > My answer is (and the historical intent has been): > > Let an IP session exist between nodes A and B. > Let that session use both AH and ESP for protection. > > Then one has two separate IPsec Security Associations; > one for AH and a different one for ESP. The > combination of (SPI, Destination Address, {AH XOR ESP}) > uniquely identifies an IPsec Security Association. > Historical intent, my foot! I just went back and re-read the messages from March 20, 1995, where I proposed the term Security Parameters Index in a direct response to a Bellovin note. I also have a private message indicating that I spoke to Atkinson on the phone before proposing the term. I think that his memory of the historical intent is different from the historical record. The historical intent was to separate the "index" which is unidirectional and different per protocol, from the "association" which has the overall party trust relationship. According to more than one person, this was needed for MLS compartmentalization, where under a single "security association", the underlying parameters could "modulate", requiring multiple SPIs per SA (to paraphrase Andy Bayerl). As Perry wrote, "the index is not the map which is not the territory." > Note that this does NOT preclude the operational > practice of creating the AH and ESP SAs at the > same time using a single KM process. It also does > not mean that a particular implementation cannot choose > to _internally_ handle those SAs as a pair. However, > it also does not require that an implementation handle > them as a pair or create them at the same time using > a single KM process. > Yes, but only if you substitute SPI where you have written SA. > Bill's terminology for "SA" and "SPI" as used in recent > messages to this list appears to be unique to him. His > terminology is not identical to the historical intent > of the IPsec document author or with the formal definition > of an IPsec Security Association in the existing RFCs > (whose clarity is admittedly suboptimal due to historical > factors). > > I beg to differ with Bill's assertion that he defined > the semantics for the "SPI". For good or ill, the > semantics were defined in the RFCs (1825-1827) -- > Bill was neither author nor editor for those RFCs. > For good or ill, I proposed the term, wrote the list text, and the first internet-drafts. It's a matter of record. As noted by Atkinson, the final RFCs were suboptimal, but we all agreed to let them be published -- because the editor promised to clean up all the non-technical errors that we let slide, within the 6 month wait before going to Draft Standard. Well, that didn't happen in 6 months, and it didn't happen in a year, or even two years. Now we have another editor, and only one internet-draft in 6 months. Do we have to wait for another 2 years? So, to recapitulate, the intent of the Working Group (in 1994-1995) was that there exist two levels of information: Security Association A collection of parameters describing the security relationship between two nodes. These parameters include the identities of the parties, the transform (including algorithm and algorithm mode), the key(s) (such as a session-key, secret-key, or appropriate public/private key-pair), and possibly other infor- mation such as sensitivity labelling. Security Parameters Index A number that indicates a particular set of attributes in a Security Association. That number is relative to the IP Destination and Protocol. The term "attributes" was used by several folks (Hughes, Bayerl), on both the IPng and IPSec lists. If there is a number that identifies a Security Association between communicating parties, it is the pair of Cookies, not any single SPI. Once upon a time, we called all the KMPs "Security Association Management Protocols" (SAMP). Someone objected that the "Security Association" was too much of a meta-concept, that the "association" has to already exist before you execute the KMP, that you are really managing the particular attributes to be used for particular sessions. Nowadays, I've settled on "Session-Key Management Protocols". But there you have it, a little bit of history.... Oh, yeah, I'm reminded that Atkinson promised to buy me a dinner if he didn't deploy a Kerberos variant of Photuris within two years, after the changes I made at his request.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
-- END included message