Csaba Kiraly | 3 Dec 13:40 2007
Picon

Re: Re: ESP's use of dummy packets?

Dear Stephan,

>> ...
>> I would also like to take the occasion to say that we have made some 
>> efforts to extend the Traffic Flow Confidentiality capabilities of 
>> IPsec. In our research we were trying to create a separate TFC 
>> security protocol, which goes beyond the limited TFC capabilities 
>> that were already included in ESPv3. We have included support for 
>> size modifications such as padding (with explicit payload size 
>> information), fragmentation and aggregation. It also supports packet 
>> re-timing, as well as dummy generation and discarding. Finally, the 
>> choice of the masking algorithm combining one or more of these basic 
>> tools is handled separately.
>
> Since 4303 already provides for arbitrary padding, and efficient dummy 
> packet generation and discarding, presumably the additional features 
> to which you refer are a management interface to control these extant 
> features, plus packet re-timing and the fragmentation and aggregation 
> features that help optimize channel bandwidth?
>
You have summarized it perfectly, but let me put some more detail behind 
some of these points.

In our experimental protocol, in order to to support padding, we have 
opted for having a header field containing explicitly the payload 
length. While  ESP do support arbitrary padding,  it does not support it 
in every situation. As it is discussed in your RFC, padding only works 
if the upper protocol layer knows what to do when it receives a larger 
PDU, i.e. the PDU should contain a length indicator, and processing 
should not throw an error when the received PDU is longer then expected. 
(Continue reading)

Hannes Tschofenig | 3 Dec 18:52 2007
Picon
Picon

iFARE Bar-BOF

Hi all,

I would like to invite you to join the iFARE Bar-BOF on Tuesday evening. 
We will meet in front on the IETF registration desk at 8pm.

More information about IPsec FAilover and REdundancy (iFare) can be 
found here: http://www.tschofenig.com/twiki/bin/view/IFare/WebHome

Ciao
Hannes

PS: I will put information about the meeting room to the above-listed 
webpage once we got it.
Hannes Tschofenig | 3 Dec 18:47 2007
Picon
Picon

iFARE Bar-BOF

Hi all,

I would like to invite you to join the iFARE Bar-BOF on Tuesday evening. 
We will meet in front on the IETF registration desk at 8pm.

More information about IPsec FAilover and REdundancy (iFare) can be 
found here: http://www.tschofenig.com/twiki/bin/view/IFare/WebHome

Ciao
Hannes

PS: I will put information about the meeting room to the above-listed 
webpage once we got it.
Snyder, Guy | 4 Dec 23:01 2007

ICSA Labs IKEv2 Bakeoff IV

Attendees from the last bakeoff and our IPSec Consortium have shown interest in ICSA Labs conducting another bakeoff in 2008.  I am sending this notice to this list to ensure that others in the IPsec community are aware of the plans for another IKEv2 Interoperability Workshop.  At the last bakeoff I promised to solicit interest in a bakeoff for 2008.  Plans currently are targeting the April/May 2008 timeframe.  This timeframe is from feedback from our IPSec Consortium and attendees from the last bakeoff.  Can you provide feedback to me as to your interest level, preferred timeframe, testing content and preferred location?  I expect the location to be centrally located in the US based on current feedback.

 

We also discussed different testing options such as normal (same as in the past with slightly different test suites), IPv6 only, MOBIKE, and carrier/mobile specific.  Oddly enough, after conducting three previous bakeoffs there are still requests to include “basic” IKEv2 tests.  Please provide your feedback on these testing options also.

 

-- Guy Snyder, VPN Programs Manager

-- ICSA Labs

 

 

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Pars Mutaf | 5 Dec 17:40 2007
Picon

Re: Dictionary-based key exchange (for mobile users)

Hello,
An implementation can be found below (using TCP transport
because future extension is possible for exchanging a large
dictionary). It supports GTK word completion with mouse and
keyboard.

http://code.google.com/p/vke/

Michael Richardson and Nicolas Williams suggested
changing the name to something like Verbal Key Exchange.

Thanks,
pars

On Nov 16, 2007 7:50 PM, Pars Mutaf <pars.mutaf <at> gmail.com> wrote:
> Hello,
> I would very much appreciate some feedback on the following
> draft (very short). Thanks in advance.
>
> Regards,
> pars
>
> --------cut here ---------
>
>
>
>
> Network Working Group                                           P. Mutaf
> Internet-Draft                                     Institut National des
>                                                       Telecommunications
> Expires: May 19, 2008                                  November 16, 2007
>
>
>                      Dictionary-based Key Exchange
>                          draft-mutaf-dke-00.txt
>
> Status of this Memo
>
>    By submitting this Internet-Draft, each author represents that any
>    applicable patent or other IPR claims of which he or she is aware
>    have been or will be disclosed, and any of which he or she becomes
>    aware will be disclosed, in accordance with Section 6 of BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
>
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
>    This Internet-Draft will expire on May 19, 2008.
>
> Copyright Notice
>
>    Copyright (C) The IETF Trust (2007).
>
> Abstract
>
>    A dictionary-based key exchange protocol is proposed.  Two mobile
>    host users that physically meet each other can use this protocol to
>    authenticate each other.  PKI nor certificates are not needed.
>
>
>
>
>
>
>
>
> Mutaf                     Expires May 19, 2008                  [Page 1]
>
> Internet-Draft        Dictionary-based Key Exchange        November 2007
>
>
> Table of Contents
>
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
>    2.  Protocol description  . . . . . . . . . . . . . . . . . . . . . 3
>    3.  Security considerations . . . . . . . . . . . . . . . . . . . . 3
>    4.  IANA considerations . . . . . . . . . . . . . . . . . . . . . . 4
>    5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
>    6.  Informative References  . . . . . . . . . . . . . . . . . . . . 4
>    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 4
>    Intellectual Property and Copyright Statements  . . . . . . . . . . 5
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Mutaf                     Expires May 19, 2008                  [Page 2]
>
> Internet-Draft        Dictionary-based Key Exchange        November 2007
>
>
> 1.  Introduction
>
>    A dictionary-based key exchange protocol is proposed.  Two mobile
>    host users that physically meet each other can use this protocol to
>    authenticate each other.  PKI nor certificates are not needed.
>
>
> 2.  Protocol description
>
>    The proposed protocol is briefly described below:
>
>
>           Initiator              MitM                 Responder
>
>                      Request RSA public key PK
>            ----------------------------------------------->
>                                   PK
>          | <--------------------------------------------
>       T  |
>          | <========== Read 40-bit fingerprint ============
>    human verification
>    of 40-bit fingerprint
>
>            -----------------{secret key}PK --------------->
>
>    where
>            PK: a one time RSA public key
>            ===: voice channel, i.e. responder user tells the fingerprint
>                 to initiator user through oral communication.
>            MitM: Man in the Middle
>
>                                  Figure 1
>
>    The octets of the fingerprint will typically be mapped to a
>    dictionary of easy to pronounce and type well-known words.  For
>    example, with a dictionary containing 256 words, each octet can be
>    represented with one word in the dictionary, and only 40/8=5 words
>    need to be checked.
>
>    In T time units, MitM has to find a PK' giving the same fingerprint
>    as PK, and returned it to the initiator before PK. 2^40 is large
>    enough to assume that the attacker cannot reasonably succeed.
>
>
> 3.  Security considerations
>
>    TBD.
>
>
>
>
> Mutaf                     Expires May 19, 2008                  [Page 3]
>
> Internet-Draft        Dictionary-based Key Exchange        November 2007
>
>
> 4.  IANA considerations
>
>    None.
>
>
> 5.  Conclusion
>
>    This document described a dictionary-based key exchange protocol.
>    The idea of human verification of a public key fingerprint is not
>    new.  A 40-bit fingerprint is normally too short and considered
>    insecure (See for example [SB].).  In the proposed protocol, however,
>    the fingerprint is used to authenticate a one-time public key that is
>    used to exchange a secret key and possibly other material.
>
>
> 6.  Informative References
>
>    [SB]  McCune, J. and J. McCune, "Seeing is Believing", Proceedings of
>          the IEEE Symposium on Security and Privacy, Oakland, CA. May
>          2005.
>
>
> Author's Address
>
>    Pars Mutaf
>    Institut National des Telecommunications
>
>    Email: pars.mutaf <at> gmail.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Mutaf                     Expires May 19, 2008                  [Page 4]
>
> Internet-Draft        Dictionary-based Key Exchange        November 2007
>
>
> Full Copyright Statement
>
>    Copyright (C) The IETF Trust (2007).
>
>    This document is subject to the rights, licenses and restrictions
>    contained in BCP 78, and except as set forth therein, the authors
>    retain all their rights.
>
>    This document and the information contained herein are provided on an
>    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
>    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
>    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
>    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
>    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
> Intellectual Property
>
>    The IETF takes no position regarding the validity or scope of any
>    Intellectual Property Rights or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; nor does it represent that it has
>    made any independent effort to identify any such rights.  Information
>    on the procedures with respect to rights in RFC documents can be
>    found in BCP 78 and BCP 79.
>
>    Copies of IPR disclosures made to the IETF Secretariat and any
>    assurances of licenses to be made available, or the result of an
>    attempt made to obtain a general license or permission for the use of
>    such proprietary rights by implementers or users of this
>    specification can be obtained from the IETF on-line IPR repository at
>    http://www.ietf.org/ipr.
>
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights that may cover technology that may be required to implement
>    this standard.  Please address the information to the IETF at
>    ietf-ipr <at> ietf.org.
>
>
> Acknowledgment
>
>    Funding for the RFC Editor function is provided by the IETF
>    Administrative Support Activity (IASA).
>
>
>
>
>
> Mutaf                     Expires May 19, 2008                  [Page 5]
>
>
Dan McDonald | 5 Dec 22:16 2007
Picon

Anyone in Vancouver have SHA-{256, 384, 512} for IKEv1 and AH/ESP handy?

I want to run some quick interoperability with IKEv1 + AH or ESP using the
SHA-2 algorithms.

Please unicast-reply if you can help.

Thanks,
Dan
Yoav Nir | 6 Dec 11:35 2007
Picon

Re: ICSA Labs IKEv2 Bakeoff IV

I don't think the requests for "basic" IKEv2 tests are so odd.  In the last bakeoff there were still problems getting the basic stuff to work. We had IKE sessions torn down because one peer did not understand the NAT-D payloads, to name but one example.

OTOH doing bakeoff after bakeoff with the same tests does mean that we get very little new relevant information.  I think we've moved beyond conflicting interpretations of the RFC text, and the problems we see now are simply bugs. That could be caused by the fact that most vendors still don't have IKEv2-enabled products on the market, so what we see in the bakeoffs are lab projects.  I don't know if this will change significantly by May.

What I would like to see is a greater focus on the remote access case, where products are either "clients" or "gateways" (I know these are not IPsec terms, but they're so useful), and they should be able to connect in difficult situations - behind NAT devices, for example, and should work with EAP servers (RADIUS) as well as PSK and certificates.

On Dec 5, 2007, at 12:01 AM, Snyder, Guy wrote:

Attendees from the last bakeoff and our IPSec Consortium have shown interest in ICSA Labs conducting another bakeoff in 2008.  I am sending this notice to this list to ensure that others in the IPsec community are aware of the plans for another IKEv2 Interoperability Workshop.  At the last bakeoff I promised to solicit interest in a bakeoff for 2008.  Plans currently are targeting the April/May 2008 timeframe.  This timeframe is from feedback from our IPSec Consortium and attendees from the last bakeoff.  Can you provide feedback to me as to your interest level, preferred timeframe, testing content and preferred location?  I expect the location to be centrally located in theUS based on current feedback.

 

We also discussed different testing options such as normal (same as in the past with slightly different test suites), IPv6 only, MOBIKE, and carrier/mobile specific.  Oddly enough, after conducting three previous bakeoffs there are still requests to include “basic” IKEv2 tests.  Please provide your feedback on these testing options also.

 

-- Guy Snyder, VPN Programs Manager

-- ICSA Labs

 

 



Scanned by Check Point Total Security Gateway. 

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Yoav Nir | 6 Dec 11:39 2007
Picon

Re: IKEv2 - possible attack from legitimate node(s)?

Hi.  This is for all the group.

Do you think there can be interest in a draft for implementing hash cookies as a means of making DDoS attacks against IKE harder? 

There are some patents and patent applications that describe similar mechanisms for different purposes (anti-spam), so we may not be able to go beyond "Experimental", but I think it's worth it.

What do you think?

On Nov 29, 2007, at 12:54 AM, Hisyam F. wrote:

Hi Yoav,
 
Thanks for the reply. Since the attack from legitimate node(s) is feasible, I agree on your statement that each individual (recepient) should implements defensive mechanism against such attack.
 
Nevertheless, I would like to ask your opinion regarding the IKEv2 message exchange. As stated in your previous reply, there were several works have been done in combating DoS i.e., HASH cookie mechanism etc. It seems that in order to defeat DoS attack, each technique in literature suggests the initiator to authenticate him/herself (prove the identity) to the respective responder by returning the correct cookie. However, I think that this verification method is efficient to certain degrees subject to the assumption that an attack is mounted from malicious attacker with spoofed ID. Since this is not applicable to DDoS  as each nodes can have legitimate ID, does it means it is impossible (I hope not) for us to propose a better approach for IKEv2?     

----- Original Message ----
From: Yoav Nir <ynir <at> checkpoint.com>
To: Hisyam F. <f_hisyam <at> yahoo.co.uk>; ipsec <at> ietf.org
Sent: Thursday, 29 November, 2007 12:53:14 AM
Subject: Re: [IPsec] IKEv2 - possible attack from legitimate node(s)?

Hi Hisyam.

An attack like this is very feasible, and the IKEv2 protocol does not have any protection against it. Individual implementations could have some protections, such as limiting the amount of half-open SAs from a particular IP address, or limiting the amount of IKE SAs from a particular peer.

Years ago, there were some proposals for securing against a DoS attack by, for example replacing the cookie with a hash of the cookie and a partial pre-image (say, all the cookie save the last 32 bits).  This would force the client to brute-force the cookie (taking on average 2^31 hash operations), by levying a 1-CPU-second "tax" on each connecting client.  This proposal died, I think because of all kinds of patents surrounding such technology.


On Nov 27, 2007, at 6:07 AM, Hisyam F. wrote:

Hi,
 
I'm relatively new to IPsec. I would like to ask regarding the DoS protection in IPsec. Based on the IKEv2 standard, there is an anti-clogging mechanism via "cookie" notification in Notify payload which prevent DoS attack on message echange (i.e.,phase 1). It seems that the DoS attack is assumed to have or mounted from spoof IP address.
 
In that sense, I would like to know whether IPsec (especially the IKEv2) contains any protection from legitimate node(s) (as an example DDoS)? In addition, is this type of attack feasible on IKEv2?
 
Thanks.

For ideas on reducing your carbon footprint visit Yahoo! For Good this month. 

Scanned by Check Point Total Security Gateway. 

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



For ideas on reducing your carbon footprint visit Yahoo! For Good this month. 

Scanned by Check Point Total Security Gateway. 


_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Tero Kivinen | 6 Dec 19:42 2007
Picon
Picon

About new PRF algorithms (comments to draft-kato-ipsec-camellia-cmac96and128-01)

I read the draft-kato-ipsec-camellia-cmac96and128-01.txt and found one
big issue in there. It copies the RFC4434 and RFC4615 mechanism of
mixed fixed / variable length keys. Those documents are like they are
because we messed up with them, I do not think we want to copy that
kind of broken behavior any further. The new
draft-hoffman-ikev2bis-02.txt actually removes the fixed length prf
text from the IKEv2, and only says that it is used as special case for
those two RFCs (RFC 4434, RFC 4615):

from draft-hoffman-ikev2bis-02.txt:
   ...
   modulus.  Ni and Nr are the nonces, stripped of any headers.  For
   historical backwards-compatibility reasons, there are two PRFs that
   are treated specially in this calculation.  If the negotiated PRF is
   AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the
   first 64 bits of Ni and the first 64 bits of Nr are used in the
   calculation.

So I think we should change:

>  The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use
>                                with IPsec
>                draft-kato-ipsec-camellia-cmac96and128-01
...
> 5.  Camellia-CMAC-PRF-128
>
>    The Camellia-CMAC-PRF-128 algorithm is identical to Camellia-CMAC
>    except that the 128-bit key length restriction is removed.
>
>    IKEv2 [5] uses PRFs for multiple purposes, most notably for
>    generating keying material and authentication of the IKE_SA.  The
>    IKEv2 specification differentiates between PRFs with fixed key sizes
>    and those with variable key sizes.
>
>    When using Camellia-CMAC-PRF-128 as the PRF described in IKEv2,
>    Camellia-CMAC-PRF-128 is considered to take fixed size (16 octets)
>    keys for generating keying material but it takes variable key sizes
>    for authentication.
>
>    That is, when generating keying material, "half the bits must come
>    from Ni and half from Nr, taking the first bits of each" as described
>    in IKEv2, section 2.14; but for authenticating with shared secrets
>    (IKEv2, section 2.16), the shared secret does not have to be 16
>    octets and the length may vary.

to:

----------------------------------------------------------------------
5.  Camellia-CMAC-PRF-128

   The Camellia-CMAC-PRF-128 algorithm is identical to Camellia-CMAC
   except that the 128-bit key length restriction is removed.

   IKEv2 [5] uses PRFs for multiple purposes, most notably for
   generating keying material and authentication of the IKE_SA.

   When using Camellia-CMAC-PRF-128 as the PRF described in IKEv2,
   Camellia-CMAC-PRF-128 is considered to take variable key lenght in
   all places, and the number of bits of keying material generated
   when new keys are generated is 128 bits (i.e. when generating
   keying material the length of SK_d, SK_pi, and SK_pr will be 128
   bits).

   When generating SKEYSEED the full Ni and Nr are used as key for the
   PRF.
----------------------------------------------------------------------

As I think we do want to start using standard variable length PRF code
and specification for all future PRFs. 

Here is also some small nits in the
draft-kato-ipsec-camellia-cmac96and128-01.txt:

> 1.  Introduction
...
>    Since optimized source code is provided by several open source
>    lisences [21], Camellia is also adopted by several open source
>    projects(Openssl, FreeBSD, Linux and Gran Paradiso).  Additional API
             ^
Missing space.

>    for Network Security Services (NSS) and IPsec stack of Linux and Free
>    BSD are prepared or working progress for release.

Free BSD should be FreeBSD.

> 10.  References
> 10.1.  Normative
>    [1]   National Institute of Standards and Technology, "Recommendation
>          for Block Cipher Modes of Operation:The CMAC Mode for
>          Autentication", Special Publication 800-38B, May 2005.
>
>    [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
>          Levels", BCP 14, RFC 2119, March 1997.
>
>    [3]   Kent, S., "IP Authentication Header", RFC 4302, December 2005.
>
>    [4]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
>          December 2005.
>
>    [5]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
>          RFC 4306, December 2005.
>
>    [6]   Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
>          Roadmap", RFC 2411, November 1998.

I do not think the roadmap document is really a normative reference.

Also I am not sure if the RFC 4302, 4303 or 4306 need to be normative
refence either, as you can implement Camellia-CMAC-96 and
Camellia-CMAC-PRF-128 without reading or understanding those documents
(you can most likely also use them in IPsec without reading those
documents :). I would move all of those [3]-[6] to the informative
refences.

>    [7]   Matsui, M., Nakajima, J., and S. Moriai, "A Description of the
>          Camellia Encryption Algorithm", RFC 3713, April 2004.
>
> 10.2.  Informative
>
>    [8]   Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
>          RFC 2409, November 1998.

I cannot find any references to this in the document.
--

-- 
kivinen <at> safenet-inc.com
vivek | 10 Dec 11:58 2007

Ikev1 and v2 pfkey

Hi,
 
I am trying to develop ikev2 component over an existing ikev1 component.
Can you please suggest me what kind of pfkeyv2 framework to have to support both v1 and v2, whether to have two separate pfkey sockets or any other method to make use of the existing pfkey socket.
 
Regards,
Vivek

***********************************************************************************************************************

            This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

Gmane