[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new draft-ietf-ipsec-isakmp?
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "W" == W Douglas Maughan <wdm@epoch.ncsc.mil> writes:
W> There was considerable discussion about the vendor ID payload. Is
W> there consensus that it should be included in the next ISAKMP draft?
W> If so, I'll use the text sent to IPSEC list by Michael Richardson on
W> 13 Oct 1997.
Thank you!
That message did not make it to the list... (At least, it isn't in the
archives.... )
Here is my original text. If anyone wants me to post the discussion
that ensued, I will do that, assuming that the parties involved don't
object. Word smithing welcome.
To: Daniel Harkins <dharkins@cisco.com>,
wdm@epoch.ncsc.mil (W. Douglas Maughan)
CC: ylo@ssh.fi, piper@cisco.com, mjs@terisa.com, mss@tycho.ncsc.mil,
tmo@ssh.fi, kivinen@ssh.fi
Subject: Re: vendor id in isakmp
In-reply-to: Your message of "Sun, 12 Oct 1997 14:37:42 PDT."
<199710122137.OAA24282@dharkins-ss20>
Date: Mon, 13 Oct 1997 15:47:05 -0400
From: "Michael C. Richardson" <mcr@istari.sandelman.ottawa.on.ca>
- -----BEGIN PGP SIGNED MESSAGE-----
My text: (the MD5 hash was produced with MD5File from the
NetBSD-current libc. I expect that it is compliant, but I haven't
checked it against our IPsec engine's version)
3.16 Vendor ID payload
The Vendor ID Payload contains a vendor defined constant. The constant is
used by vendors to identify and recognize remote instances of their
implementations. Figure 17 shows the format of the Vendor ID Payload.
The Vendor ID should be sent in the phase I negotiation. Reception of
a familiar Vendor ID payload in the phase I negotiation allows an
implementation to make use of payload numbers 128-255 for vendor
specific extensions during phase II.
If a private payload was sent without prior agreement to send it, a
compliant implementation may reject a proposal with a notify message
of type INVALID-PAYLOAD-TYPE.
This mechanism allows a vendor to experiment with new features while
maintaining backwards compatibility. This is not a general extension
facility: widely used extensions SHOULD be documented and standardized
in a future version of ISAKMP.
The vendor defined constant MUST be unique. Vendors SHOULD generate
their vendor id by taking a plain (non-keyed) hash of a string
containing the product name, and the version of the product. For
instance:
"Example Company IPsec. Version 97.1"
(not including the quotes) has MD5 hash: 48544f9b1fe662af98b9b39e50c01a5a,
and the vendor id could be taken to the first 96 bits:
48544f9b1fe662af98b9b39.
The vendor ID is opaque, so the choice of hash and text to hash is
left to the vendor to decide. Vendors SHOULD change their vendor ID
for major revisions of their product as this allows them to work
around problems in previous versions of their product.
A hash is used instead of a vendor registry to avoid local
cryptographic policy problems with having a list of "approved"
products, and to allow classified products to avoid having to appear
on any list.
The definition of "familiar" is left to implementations to
determine. Some vendors may wish to implement another vendor's
extension prior to standardization. This practice SHOULD not be
widespread: vendors should work towards standardization instead.
The Vendor ID payload is not an announcement from the sender that
it will send private payload types. A vendor sending the vendor ID
MUST not make any assumptions about private payloads that it may send
unless a Vendor ID is received as well.
Multiple Vendor ID payloads MAY be sent. An implementation is NOT
REQUIRED to understand any Vendor ID payloads. An implementation is
NOT REQUIRED to send any Vendor ID payload at all.
If Vendor ID(s) are sent, they MUST be sent during the Phase I
exchange. [comment please! MCR]
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! VENDOR ID: 96 bits !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Vendor ID payload
The Vendor ID Payload fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of the next
payload in the message. If the current payload is the last in the
message, then this field will be 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current payload,
including the generic payload header. This is always 16 bytes.
o Vendor ID (12 octets) - hash of vendor string plus version.
The payload type for the Vendor ID Payload is twelve (13).
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQB1AwUBNEJ6sKZpLyXYhL+BAQGciwL+PXyLWZJPWlrH0d/e6PV/WClq919DOQ07
Jrzcp+HAoonlBzChSzhQzZhe9bBfADHGmSKtyURYWoTAhh2yODdql6sYi+ffFIJU
WOyMJTmgHFudS0yPCYgZOcCnBVPl7hYE
=9ZDn
- -----END PGP SIGNATURE-----
:!mcr!: | Sandelman Software Works Corporation, Ottawa, ON
Michael Richardson |Network and security consulting and contract programming
Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca</A>.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQB1AwUBNPDx6NiXVu0RiA21AQFjZAL/bbwdLvPlJdD+61YxYxXa6AeihHslwyS2
NvaHyx0dlbMvWXJ+jYCeqbvL+WHkrEI+2K5vgaqxT4Tq7wKUL6uVbNEvCT99L57g
Dqw00jYOe7KRMHEURfGWTnR2iuiz+kWm
=EDIg
-----END PGP SIGNATURE-----
Follow-Ups:
References: