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

Re: new draft-ietf-ipsec-isakmp?



IPSEC'ers,

> Any idea when we can read a isakmp draft?

My apologies for not getting out another ISAKMP draft. This little
thing called a dissertation keeps getting in the way. I had hoped to
have it done by tomorrow, but it won't be ready. At the latest, I'll
have it by next Friday, Feb. 27.

> The last draft was submitted before Munich in July.  Considering
> the discussions on this list and the isakmp-oakley list, I would
> like to see a new draft before seeing it complete last call.

Bob/Ted: I suggest you consider waiting and sending this out with the
architecture and roadmap documents. Your call.

> Daniel Harkins writes:
> > > 	Jul 28  1997	draft-ietf-ipsec-isakmp-08.txt
> > So this means that the base ISAKMP draft wasn't rev'd? That means that
> > one of the issues from the document reading party wasn't addressed.

These are addressed in the next version.

> Tero Kivinen writes:
> How about the certificate request payload? There was some talk about
> simplifying it so that it would only contain one type / CA and in case
> of multiple types / CA's the negotiation would just have multiple
> certitificate request payloads. 

This is also in the next version.
 
> > Also, various vendors have in the past requested a Vendor ID payload
> > which would carry some opaque blob. This also hasn't been added.
> 
> I think that vendor ID payload is very important because otherwise
> there really isn't any use for private attributes in SA etc, because
> there is no way to know who's private extensions they unless you use
> some out of band configuration data to tell the other end's isakmp
> vendor. 

There was considerable discussion about the vendor ID payload. Is there
consensus that it should be included in the next ISAKMP draft? If so,
I'll use the text sent to IPSEC list by Michael Richardson on 13 Oct
1997.

There were other payloads requested, i.e. Pass Kerberos tickets, Pass
VRRP info, Pass Configuration information, and an Extension (blob)
payload. Which of these, if any, should be included in the next draft?

If there are any issues that are "hot" buttons that "MUST' be included
in the next ISAKMP draft, please send them to me (and the list) so I
can double check to make sure they've been addressed.

Thanks,

Doug Maughan


Follow-Ups: