[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: comments on the latest GSSAPI draft changes

of course our numbers are protected by vendor ids.  that doesn't mean we
don't care what those numbers are.  we still want interop as easy as
possible, which means a concensus on the numbers as much as possible.  it
would be nice to have good interim numbers specified in the drafts.  it is
clearly the best place for that specification, assuming that those numbers
are well chosen, and as constant as possible.

bs

-----Original Message-----
From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca]
Sent: Friday, October 15, 1999 11:15 AM
To: ipsec@lists.tislabs.com
Subject: Re: comments on the latest GSSAPI draft changes 


-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Exchange" == Exchange  <Brian> writes:
    Exchange> Agreed.  But, shipping based on internet drafts is a necessary
    Exchange> evil.  Given that some vendors find this necessary, the

  No, it is just evil. XAUTH/GSSAPI/etc. should not have specified numbers
at *ALL*

  The ISAKMP protocol provides for ways for vendors to use the private
address space in a nice fashion. It is called the Vendor ID payload.

    Exchange> So the question still remains: will the arbitrary ID changes
be
    Exchange> put back to their original values, or will we have a large
    Exchange> divergence from the IDs in the draft, and IDs in the
    Exchange> marketplace?

  If you ship with VendorID you won't care.
  If you ship with bare IDs from the private address range you will get
toasted at every single bakeoff, and your product will likely fail to
be certified.

] Train travel features AC outlets with no take-off restrictions|  firewalls
[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");
[

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface

iQB1AwUBOAdvMI5hrHmwwFrtAQFJJwL9E5/nU5UiuDAgpK0dAcLPJQV0QH5BOEN4
THXkqN/gfmTnWp11m7BBHRvIoK/ZI5kGMWDQfMqC1QfnzJ+saZxwn6iAx20lkzcT
utlTWN5KVfsixmVPYZjgFrAteUGbS11O
=2L65
-----END PGP SIGNATURE-----
Follow-Ups: