Subject: [anonsec] Fwd: [openikev2-announce] New versions released !!!

From: ynir at checkpoint.com (Yoav Nir)
Date: Fri, 27 Jul 2007 06:50:46 -0500

Hi.

Thought this would be of interest to the list.

Apparently they have BTNS support.

Begin forwarded message:

> From: Alejandro Perez Mendez <alejandro_perez at dif.um.es>
> Date: July 27, 2007 4:16:36 AM CDT
> To: OpenIKEv2 announces <openikev2-announce at dif.um.es>
> Subject: [openikev2-announce] New versions released !!!
>
> New versions released !!!
>       * libopenikev2 0.4:
>               * Huge code refactoring, including:
>                       * Intensive use of the RAII programming idiom
>                         (autopointers, autolocks, autovectors...),
>                         avoiding the use of the "delete".
>                       * Use of references when there was no need for
>                         more.
>                       * Name classes changes, to avoid the "_" at most
>                         as possible.
>                       * Code factorization, reusing the code for the
>                         CHILD SA negotiation from the IKE_AUTH and the
>                         CREATE_CHILD_SA exchanges. Also the code  
> for the
>                         IKE_SA negotiation from the IKE_SA_INIT and
>                         CREATE_CHILD_SA exchanges has been factorized.
>               * BTNS support added (that's is, no authentication at  
> all
>                 at IKEv2 level)
>               * Lot of bug fixes.
>       * libopenikev2_impl 0.4:
>               * Huge code refactoring, including:
>                       * Intensive use of the RAII programming idiom
>                         (autopointers, autolocks, autovectors...),
>                         avoiding the use of the "delete".
>                       * Use of references when there was no need for
>                         more.
>                       * Name classes changes, to avoid the "_" at most
>                         as possible.
>               * Disabled PFKEYv2 IPsec management interface. It may be
>                 available in future versions.
>               * Certificate support has been improved:
>                       * Alternate name is now consulted to match with
>                         the ID payload.
>                       * Improved DN management (subject name and  
> issuer
>                         name). Now they are shown propertly.
>               * Lot of bug fixes.
>       * openikev2 0.94:
>               * Addded support for BTNS in the configuration file.
>               * PFKEYv2 is not available in this version, so if you  
> want
>                 to use it ,keep using 0.93 version (and 0.3 library
>                 versions).
>               * Addapted to the new libopenikev2 an libopenikev2_impl
>                 API (0.4 version).
>       * tests 0.4
>               * Changed in order to be compatible to libopenikev2 and
>                 libopenikev2_impl 0.4 version.
> See the libopenikev2 ChangeLog, the libopenikev2_impl ChangeLog,
> openikev2 ChangeLog and test ChangeLog to see a more complete change
> list. Remember to make backups of the configuration files before  
> install
> the new release. They will be overwritten.
>
>
> You can download it here
>
>
> _______________________________________________
> openikev2-announce mailing list
> openikev2-announce at dif.um.es
> https://correo.dif.um.es/cgi-bin/mailman/listinfo/openikev2-announce
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/anonsec/attachments/20070727/523da547/attachment-0001.html

---

From: gregorio at dif.um.es (Gregorio Martinez)
Date: Fri, 27 Jul 2007 18:28:49 +0200

Hi Yoav, hi all,

thanks for forwarding this message to the Anonsec/BTNS mailing list ... and you are right; we are currently supporting BTNS as part of our 
implementation of the IKEv2 protocol (http://openikev2.sourceforge.net/); it is working well with SAB mode and we are finishing now the coding of the 
Channel Binding (CBB) mode.

Thanks, regards, Gregorio

Gregorio Martinez, PhD
University of Murcia (UMU), Spain

Yoav Nir wrote:
>> *From: * Alejandro Perez Mendez <alejandro_perez at dif.um.es 
>> <mailto:alejandro_perez at dif.um.es>>
>> *Date: * July 27, 2007 4:16:36 AM CDT
>> *To: * OpenIKEv2 announces <openikev2-announce at dif.um.es 
>> <mailto:openikev2-announce at dif.um.es>>
>> *Subject: * *[openikev2-announce] New versions released !!!*
>>
>>                         CREATE_CHILD_SA exchanges. Also the code for the
>>               * BTNS support added (that's is, no authentication at all
>>                 at IKEv2 level)
>>               * Lot of bug fixes.
>>       * libopenikev2_impl 0.4:
>>                       * Improved DN management (subject name and issuer
>>               * PFKEYv2 is not available in this version, so if you want
>> list. Remember to make backups of the configuration files before install
>> openikev2-announce at dif.um.es <mailto:openikev2-announce at dif.um.es>
> ------------------------------------------------------------------------
>

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 27 Jul 2007 14:18:49 -0400

>Apparently they have BTNS support.

Since no BTNS documents are final yet, the above statement seems a 
bit premature  :-).

Steve

---

From: ynir at checkpoint.com (Yoav Nir)
Date: Fri, 27 Jul 2007 16:55:15 -0500

As long as it's running code...

We've had IKEv2 interoperability workshops months before RFC 4306.

There are also lots of implementations of SCEP and that hasn't made  
it to historic yet.

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 30 Jul 2007 10:58:54 -0400

>As long as it's running code...

Windows is running code too, but it's not an IETF standard :-).

If CheckPoint wants to declare something it implemented as being 
BTNS, despite the lack of an IESG-approved document, and in light of 
the ongoing changes to the document, I guess it's a good marketing 
ploy, if not good IETF behavior.

>We've had IKEv2 interoperability workshops months before RFC 4306.

Before the RFC was issued (after several months in the RFC Editor's 
queue), or before the document was approved by the IESG?

>There are also lots of implementations of SCEP and that hasn't made 

That's an irrelevant example, i.e., a protocol developed outside the 
IETF which may be published as historic, as a compromise.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 30 Jul 2007 10:24:49 -0500

> Since no BTNS documents are final yet, the above statement seems a 

Maybe.  There were SSHv2 implementations long before there were SSHv2
RFCs.  C'est la vie.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 30 Jul 2007 11:00:10 -0500

> Windows is running code too, but it's not an IETF standard :-).

Implementations aren't, though they might be standards compliant, but
since the IETF doesn't have any sort of compliance testing, compliance
is up to the vendors to test for and up to the customers to test for and
insist on.

> ploy, if not good IETF behavior.

It happens a lot in the IETF.  For at least some Internet protocols
vendors have shipped long before the RFCs issued.

In any case, the latest release of the particular implementation that
we're talking about is labelled as version 0.4, which might well be, for
all we know, an acknowledgement of the potential for backwards
incompatible changes as Internet-Drafts change backwards incompatibly.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 30 Jul 2007 12:09:13 -0400

>Maybe.  There were SSHv2 implementations long before there were SSHv2

SSH (v1?) was another example of a protocol developed outside the 
IETF, and later brought into the IETF.  At least in this case, there 
were no directly competing IETF WGs.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 30 Jul 2007 12:30:02 -0400

>is up to the vendors to test for and up to the customers to test for and

or to have third-party labs validate.

>vendors have shipped long before the RFCs issued.

note my distinction between RFC issuance vs. IESG approval. Once the 
IESG approves a document is may take many months (it used to be as 
long as a year) for the RFC to be issued, but the substance of the 
standard is fixed.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 30 Jul 2007 12:00:42 -0500

> long as a year) for the RFC to be issued, but the substance of the 

Yeah, but with SSHv2 the implementations existed and shipped long before
the I-Ds even passed WGLC.

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 30 Jul 2007 13:06:41 -0400

>the I-Ds even passed WGLC.

Then the vendors jumped the gun.

Steve