From heer@informatik.rwth-aachen.de Tue Dec 6 20:28:48 2011 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E999811E80A0 for ; Tue, 6 Dec 2011 20:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3hMGONG09IJ for ; Tue, 6 Dec 2011 20:28:47 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id B63BB21F87D9 for ; Tue, 6 Dec 2011 20:28:33 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LVT005ICGFJZR30@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Wed, 07 Dec 2011 05:28:31 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.71,311,1320620400"; d="scan'208";a="71465211" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 07 Dec 2011 05:28:31 +0100 Received: from [192.168.11.4] ([unknown] [91.179.52.114]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LVT00GFCGFH2N60@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Wed, 07 Dec 2011 05:28:31 +0100 (CET) From: Tobias Heer In-reply-to: <4EC6BE2A.8050101@htt-consult.com> Date: Wed, 07 Dec 2011 05:28:29 +0100 Content-transfer-encoding: quoted-printable Message-id: <8DB61154-CBE4-48C0-B5B5-D1AB3FD2442A@cs.rwth-aachen.de> References: <4EC6BE2A.8050101@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1084) Cc: HIP Subject: Re: [Hipsec] HIP CIpher -- AES-CTR X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 04:28:49 -0000 Hi Bob, Am 18.11.2011 um 21:20 schrieb Robert Moskowitz: > What is HIP_CIPHER? >=20 > This is the cipher used to encrypt a HIP parameter (that calls for = encrypting). No HIP Parameter authentication is used, encrypted = parameters are protected with any of the various HIP_MAC parameters. >=20 > HIP_CIPHER AES-CBC >=20 > This is quite a reasonable cipher to use. The IV is defined = variously. However... >=20 > 802.11 and 802.15 interfaces have AES-CCM built into them. It was = pointed out to me, that for HIP-DEX, I had added the need for the AES = decrypt in software because I was using AES_CBC for the HIP_CIPHER. So = I am changing HIP-DEX to specify AES-CTR. >=20 > I am bringing this to everyone's attention so we can get agreement on = the construct of the counter >=20 > AND >=20 > Perhaps it should be added to 5201-bis as well... >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > No on to defining the counter. We will reference RFC 3686 for the = counter block format. We need a 32 bit nonce and a 64 bit IV and then = there will be a 32 bit block counter (quite an overkill for the size and = number of encrypted parameter blocks, but stay consistant). >=20 > It is my proposal that R1_Counter be used for the IV and the puzzle I = and J be used for the nonce (low order 32 bits as they are larger than = 32bits). Or 'just' use I and J, their lower 96bits. >=20 > This brings into focus that we need to specify that I and J can never = be equal (it just could happen, it can work if k=3D0). We use I and J = as nonces in few areas. They need to be unique. I think we missed = being explicit on this test. I and J must definitely be unique when you do static diffie Hellman. For = ephemeral DH, they need to be unique if you intend to use R1 = pre-creation. I think this is mentioned explicitly in RFC5201-bis but = I'll check it out. For DEX with static DH it should be noted clearly in = the text. There may also be a note that otherwise security is at stake = because you can just wait for a IV and nonce collision with the same DH = pairs to derive the cleartext messages. >=20 > Using R1_Counter turns it from a SHOULD to a MUST if HIP_CIPHER =3D = AES-CTR. In RFC5201-bis we already changed the Responder behavior for responding = to a R1_COUNTER with a R1_COUNTER to a must. I guess it is enough to = define in DEX that the Initiator MUST use a R1_COUNTER that was = (pseudo)randomly selected. >=20 > But does the update frequency of the puzzle and its potential reuse = introduce a potential weakness. The puzzle is rather cheap, and it is intended to be outside the = pre-created part of the R1. The I and J Values take care that the puzzle = can be made unique for each Initiator (e.g., by constructing the I value = from sender HIT and sender IP addresses plus counter). However with the = CTR mode, attacks against the Initiator must be considered as well. What = happens when an attacker sends the Initiator a replayed R1 packet and = the Initiator for some reason replies with a I2 with the same IV, same = nonce, but different cleartext? The attacker could retrieve an xor of = both cleartexts. For chosen cleartext attacks, this may compromise = security. That's why RFC3686 says: "The same IV and key combination MUST = NOT be used more than once.". Hence, the Initiator must either keep = track of already used IVs or must add its own random value to the IV. = Using the puzzle solution does not really seem to be good enough for the = purpose here because depending on the puzzle solution implementation one = may re-use solutions (or arrive at the same solution) for two identical = I values and host pairs. I guess having some real (pseudo) randomness = from the Initiator would make your life much easier, although it may = scream for some more space for signaling this value (as you suggest = below). Even this might not be enough, depending on the space for the random = part of the IV. That's why RFC3686 says: "For this reason, it is = inappropriate to use this mode of operation with static keys. = Extraordinary measures would be needed to prevent reuse of an IV value = with the static key across power cycles. To be safe, implementations = MUST use fresh keys with AES-CTR." Concluding, I guess you have the choice of either tightly restricting = how the puzzle must work and what exactly can be sent in the encrypted = part (to avoid chosen plaintext issues) or to make the key or IV = _unique_. Good keys and/or IVs sound more useful to me. > The responder would be using the same counter space in different HIP = exchanges. As long as these are with different initiators, this is not = a problem as the DH derived keys would be different. In HIP-BEX with = ephemeral DH, we are still 'safe'? But HIP-DEX with static ECDH, we = could never use the same puzzle between two HP-DEX peers. Exactly. >=20 > An alternative would be to still use I and J for the IV, but to = include a 32bit nonce with the encrypt block that MUST be fresh with = each block. >=20 Sounds better. Is 32 bit still sufficient here if the key would be = static? RFC3686 assumes fresh and unique keys which you seem not to = have.=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Two questions: >=20 > For HIP-DEX: how to construct the Counter Block. Good question. I tried to give some input/thoughts above. However, we = should definitely have people from the crypto community onboard when = doing such an adventure. I can't do much more than educated guessing = when it comes to these matters. >=20 > For HIP-BEX: is AES-CTR worth adding? I think there is no real demand at this time. If you can work it out, I = would rather define it as a requirement in the BEX-DEX compatibility = section in the DEX document. However, there is now a mechanism to make = the ciphers exchangeable in BEX (5201-bis) so we can easily extend the = existing values in the future when needed. I hope this helps. Tobias =20 >=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --=20 Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://www.comsys.rwth-aachen.de/team/tobias-heer/ blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi pgp id: AEECA5BF=20 From rstruik.ext@gmail.com Mon Dec 19 07:52:09 2011 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E90521F848C; Mon, 19 Dec 2011 07:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jxg+Bgkh4k23; Mon, 19 Dec 2011 07:52:08 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 851A421F8495; Mon, 19 Dec 2011 07:52:07 -0800 (PST) Received: by laah2 with SMTP id h2so2480225laa.31 for ; Mon, 19 Dec 2011 07:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=wlOrjcn5UmfGFtGqQ9ahgZ0AU/4YT6M0sDheTWfaQyI=; b=NO1W+L0EnWgVbKSaFSxNnG6fDmTMC0hTSQYjBW0CHxorrWDVELOA5D4a2KHSsTkJmA +4pNSIytteSgRj49uZZ63JSzhP+mJKy1+djlh75cNuj9ahrcvgX7JvFC9PyZjnM0MuNY 8KkEElKvvZ+LvX+dyEFqlgO2Y3eK/jRFK3CgI= Received: by 10.152.111.1 with SMTP id ie1mr17123004lab.7.1324309919782; Mon, 19 Dec 2011 07:51:59 -0800 (PST) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [173.34.96.176]) by mx.google.com with ESMTPS id lr3sm17189610lab.17.2011.12.19.07.51.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Dec 2011 07:51:57 -0800 (PST) Message-ID: <4EEF5D92.5020503@gmail.com> Date: Mon, 19 Dec 2011 10:51:46 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ren=E9_Hummen?= , core , hipsec@ietf.org References: <04D43087-E2BF-464F-BE5E-D57FC3FFA746@cs.rwth-aachen.de> <4EC15495.3000700@gmail.com> <4EC5B600.1040700@gmail.com> In-Reply-To: <4EC5B600.1040700@gmail.com> X-Enigmail-Version: 1.3.4 Content-Type: multipart/alternative; boundary="------------000205090008030802040707" Subject: Re: [Hipsec] [hiprg] Research topics discussion - meeting suggestion: Wednesday 7:30pm X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 15:52:09 -0000 This is a multi-part message in MIME format. --------------000205090008030802040707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Perhaps, worth some thoughts under the Christmas tree and then getting back on this one after New Year. On 17/11/2011 8:33 PM, Rene Struik wrote: > Hi fellow-Rene: > > If you have some papers, I would appreciate. Distributing those would > also help removing hurdles to more wide-scale use of HIP (I saw the > slides on lack of adoption of HIP). > > Best regards, Rene > > > On 14/11/2011 12:49 PM, Rene Struik wrote: >> Hi fellow-Rene: >> >> Just curious: is there any research paper outside IETF/IRTF realm >> that delves into HIP-related matter? On a tangent: same question, but >> now re cryptographically generated addresses? This may help people to >> appreciate this effort better, without having to delve into hundreds >> of pages of specification text that sometimes seems to obscure seeing >> the forest for the trees (if I translate this properly). I, for one, >> would love to see 2-3 academic papers that make this subject matter >> clearer, including security properties, ease-of-use considerations. >> >> Best regards, Rene >> >> On 14/11/2011 12:38 PM, René Hummen wrote: >>> Hello everyone, >>> >>> we already had a few discussions on this list about new topics and research directions that would foster collaboration within the context of the hiprg. Hierarchical HITs, IoT-related protocol variants, and middlebox awareness have been mentioned there among others. In my opinion, an informal meeting before the hiprg meeting on Thursdays would be a great opportunity to further discuss about these topics. Furthermore, such a meeting would enable us see who is interested in which field and which are the pros and cons of the different topics as perceived by people in a more comfortable and less hurried way than in an RG meeting. >>> >>> As most of us will probably be at the social event tomorrow evening, I suggest to meet for dinner/a drink on Wednesday evening at 7:30pm in order to get some discussion going. Due to the lack of knowledge about a better place, let's meet up at the entrance of the convention center (TICC). Please email me if you are interested. >>> >>> BR >>> René >>> >>> >>> >>> -- >>> Dipl.-Inform. Rene Hummen, Ph.D. Student >>> Chair of Communication and Distributed Systems >>> RWTH Aachen University, Germany >>> tel: +49 241 80 20772 >>> web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ >>> >>> >>> >>> _______________________________________________ >>> hiprg mailing list >>> hiprg@irtf.org >>> https://www.irtf.org/mailman/listinfo/hiprg >> >> >> -- >> email: rstruik.ext@gmail.com >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 > > > -- > email: rstruik.ext@gmail.com > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 --------------000205090008030802040707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Perhaps, worth some thoughts under the Christmas tree and then getting back on this one after New Year.

On 17/11/2011 8:33 PM, Rene Struik wrote:
Hi fellow-Rene:

If you have some papers, I would appreciate. Distributing those would also help removing hurdles to more wide-scale use of HIP (I saw the slides on lack of adoption of HIP).

Best regards, Rene


On 14/11/2011 12:49 PM, Rene Struik wrote:
Hi fellow-Rene:

Just curious: is there any research paper outside IETF/IRTF realm that delves into HIP-related matter? On a tangent: same question, but now re cryptographically generated addresses? This may help people to appreciate this effort better, without having to delve into hundreds of pages of specification text that sometimes seems to obscure seeing the forest for the trees (if I translate this properly). I, for one, would love to see 2-3 academic papers that make this subject matter clearer, including security properties, ease-of-use considerations.

Best regards, Rene

On 14/11/2011 12:38 PM, René Hummen wrote: 
Hello everyone,

we already had a few discussions on this list about new topics and research directions that would foster collaboration within the context of the hiprg. Hierarchical HITs, IoT-related protocol variants, and middlebox awareness have been mentioned there among others. In my opinion, an informal meeting before the hiprg meeting on Thursdays would be a great opportunity to further discuss about these topics. Furthermore, such a meeting would enable us see who is interested in which field and which are the pros and cons of the different topics as perceived by people in a more comfortable and less hurried way than in an RG meeting.

As most of us will probably be at the social event tomorrow evening, I suggest to meet for dinner/a drink on Wednesday evening at 7:30pm in order to get some discussion going. Due to the lack of knowledge about a better place, let's meet up at the entrance of the convention center (TICC). Please email me if you are interested.

BR
René



--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/




_______________________________________________
hiprg mailing list
hiprg@irtf.org
https://www.irtf.org/mailman/listinfo/hiprg



-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
--------------000205090008030802040707-- From internet-drafts@ietf.org Thu Dec 22 09:01:37 2011 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8E321F8876; Thu, 22 Dec 2011 09:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe4llA7e3Wvf; Thu, 22 Dec 2011 09:01:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED4121F85B9; Thu, 22 Dec 2011 09:01:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111222170137.16726.13235.idtracker@ietfa.amsl.com> Date: Thu, 22 Dec 2011 09:01:37 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 17:01:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Host Identity Protocol Working Group = of the IETF. Title : Native NAT Traversal Mode for the Host Identity Protocol Author(s) : Ari Keranen Jan Melen Filename : draft-ietf-hip-native-nat-traversal-02.txt Pages : 15 Date : 2011-12-22 This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-nat-traversal-02.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-hip-native-nat-traversal-02.t= xt From ari.keranen@nomadiclab.com Thu Dec 22 09:03:47 2011 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085C221F8AE6 for ; Thu, 22 Dec 2011 09:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shBXuey67Ie8 for ; Thu, 22 Dec 2011 09:03:46 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7069221F86B3 for ; Thu, 22 Dec 2011 09:03:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 307F04E6E9 for ; Thu, 22 Dec 2011 19:03:45 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztldy81vH7P6 for ; Thu, 22 Dec 2011 19:03:44 +0200 (EET) Received: from n212.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 7697D4E6DF for ; Thu, 22 Dec 2011 19:03:44 +0200 (EET) Message-ID: <4EF362EF.1000609@nomadiclab.com> Date: Thu, 22 Dec 2011 19:03:43 +0200 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <20111222170137.16726.13235.idtracker@ietfa.amsl.com> In-Reply-To: <20111222170137.16726.13235.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 17:03:47 -0000 Just a keep-alive re-submission (with updated references) to have a non-expired reference for the Experiment Report. Cheers, Ari On 12/22/11 7:01 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > Title : Native NAT Traversal Mode for the Host Identity Protocol > Author(s) : Ari Keranen > Jan Melen > Filename : draft-ietf-hip-native-nat-traversal-02.txt > Pages : 15 > Date : 2011-12-22 > > This document specifies a new Network Address Translator (NAT) > traversal mode for the Host Identity Protocol (HIP). The new mode is > based on the Interactive Connectivity Establishment (ICE) methodology > and UDP encapsulation of data and signaling traffic. The main > difference from the previously specified modes is the use of HIP > messages for all NAT traversal procedures. From rene.hummen@informatik.rwth-aachen.de Sat Dec 31 09:04:21 2011 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C952021F8483; Sat, 31 Dec 2011 09:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBBF6DseIaBA; Sat, 31 Dec 2011 09:04:21 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id AB2B121F8482; Sat, 31 Dec 2011 09:04:19 -0800 (PST) MIME-version: 1.0 Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LX200I5HVF6TJ70@mta-1.ms.rz.RWTH-Aachen.de>; Sat, 31 Dec 2011 18:04:18 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.71,437,1320620400"; d="p7s'?scan'208";a="73704190" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Sat, 31 Dec 2011 18:04:19 +0100 Received: from [10.0.2.2] ([unknown] [2.192.237.31]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LX200K3QVF4WF70@relay-auth-1.ms.rz.rwth-aachen.de>; Sat, 31 Dec 2011 18:04:18 +0100 (CET) Content-type: multipart/signed; boundary=Apple-Mail-133--848491416; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ren=E9_Hummen?= In-reply-to: <4EEF5D92.5020503@gmail.com> Date: Sat, 31 Dec 2011 18:04:19 +0100 Message-id: <02E1CC7E-A9A4-4051-A0FA-7D12E9EF371C@cs.rwth-aachen.de> References: <04D43087-E2BF-464F-BE5E-D57FC3FFA746@cs.rwth-aachen.de> <4EC15495.3000700@gmail.com> <4EC5B600.1040700@gmail.com> <4EEF5D92.5020503@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1084) Cc: hipsec@ietf.org, core Subject: Re: [Hipsec] [hiprg] Research topics discussion - meeting suggestion: Wednesday 7:30pm X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 17:04:21 -0000 --Apple-Mail-133--848491416 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Ren=E9, this email contains a few references to papers regarding the security = properties and embedding of HIP in today's network environments. First of all, HIP is a SIGMA-compliant key exchange protocol [1]. To be = exact, it is a derivate of the basic protocol described in Section 5.1, = as the HIP BEX is triggered by a separate (empty) message that is not = included in the SIGMA protocol family. This allows HIP to perform DoS = protection against exhaustive public key-based operations by the = responder by means of cryptographic puzzles. Furthermore, the public key = (A) of the responder is already sent in the first response message. = However, this does not impact the security properties, but rather the = anonymity of the responder. Regarding the usage of HIP, there is a rather comprehensive journal = article [2] that describes the architecture as well as the operation = system and infrastructure requirements of HIP. It also provides some = pointers to further papers that may be worth reading for you. = Additionally, Samu Varjonen recently published a paper on the "Secure = Resolution of End-Host Identifiers for Mobile Clients" [3]. However, it = seems to be inaccessible at the moment. Still, you may want to refer to = it at later point in time, as it describes an approach to resolve HITs = to IP addresses. I hope that this small selection is helping you in understanding the = properties of HIP. I would also like to invite other people to = contribute to this discussion, e.g., by providing further references = relevant for the CoRE WG. Regards, Ren=E9 [1] Krawczyk, H.; SIGMA: The =91SIGn-and-MAc=92 Approach to = Authenticated Diffie-Hellman and Its Use in the IKE Protocols, ADVANCES = IN CRYPTOLOGY - CRYPTO 2003 Lecture Notes in Computer Science, 2003 [2] Nikander, P.; Gurtov, A.; Henderson, T.R.; Host Identity = Protocol (HIP): Connectivity, Mobility, Multi-Homing, Security, and = Privacy over IPv4 and IPv6 Networks, Communications Surveys & Tutorials, = IEEE, 2010 [3] Varjonen, S.; Heer, T.; Rimey, K.; and Gurtov, A.; Secure Resolution = of End-Host Identifiers for Mobile Clients, IEEE GLOBECOM, 2011 On 19.12.2011, at 16:51, Rene Struik wrote: > Perhaps, worth some thoughts under the Christmas tree and then getting = back on this one after New Year. >=20 > On 17/11/2011 8:33 PM, Rene Struik wrote: >> Hi fellow-Rene: >>=20 >> If you have some papers, I would appreciate. Distributing those would = also help removing hurdles to more wide-scale use of HIP (I saw the = slides on lack of adoption of HIP). >>=20 >> Best regards, Rene >>=20 >>=20 >> On 14/11/2011 12:49 PM, Rene Struik wrote: >>> Hi fellow-Rene: >>>=20 >>> Just curious: is there any research paper outside IETF/IRTF realm = that delves into HIP-related matter? On a tangent: same question, but = now re cryptographically generated addresses? This may help people to = appreciate this effort better, without having to delve into hundreds of = pages of specification text that sometimes seems to obscure seeing the = forest for the trees (if I translate this properly). I, for one, would = love to see 2-3 academic papers that make this subject matter clearer, = including security properties, ease-of-use considerations. >>>=20 >>> Best regards, Rene >>>=20 >>> On 14/11/2011 12:38 PM, Ren=E9 Hummen wrote: >>>> Hello everyone, >>>>=20 >>>> we already had a few discussions on this list about new topics and = research directions that would foster collaboration within the context = of the hiprg. Hierarchical HITs, IoT-related protocol variants, and = middlebox awareness have been mentioned there among others. In my = opinion, an informal meeting before the hiprg meeting on Thursdays would = be a great opportunity to further discuss about these topics. = Furthermore, such a meeting would enable us see who is interested in = which field and which are the pros and cons of the different topics as = perceived by people in a more comfortable and less hurried way than in = an RG meeting. >>>>=20 >>>> As most of us will probably be at the social event tomorrow = evening, I suggest to meet for dinner/a drink on Wednesday evening at = 7:30pm in order to get some discussion going. Due to the lack of = knowledge about a better place, let's meet up at the entrance of the = convention center (TICC). Please email me if you are interested. >>>>=20 >>>> BR >>>> Ren=E9 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Dipl.-Inform. Rene Hummen, Ph.D. Student >>>> Chair of Communication and Distributed Systems >>>> RWTH Aachen University, Germany >>>> tel: +49 241 80 20772 >>>> web:=20 >>>> http://www.comsys.rwth-aachen.de/team/rene-hummen/ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> hiprg mailing list >>>>=20 >>>> hiprg@irtf.org >>>> https://www.irtf.org/mailman/listinfo/hiprg >>>=20 >>>=20 >>> --=20 >>> email:=20 >>> rstruik.ext@gmail.com >>>=20 >>> Skype: rstruik >>> cell: +1 (647) 867-5658 >>> USA Google voice: +1 (415) 690-7363 >>>=20 >>=20 >>=20 >> --=20 >> email:=20 >> rstruik.ext@gmail.com >>=20 >> Skype: rstruik >> cell: +1 (647) 867-5658 >> USA Google voice: +1 (415) 690-7363 >>=20 >=20 >=20 > --=20 > email:=20 > rstruik.ext@gmail.com >=20 > Skype: rstruik > cell: +1 (647) 867-5658 > USA Google voice: +1 (415) 690-7363 >=20 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 20772 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ --Apple-Mail-133--848491416 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7zCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE2jCCA8KgAwIBAgIEDuQh4zANBgkqhkiG 9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJX VEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAeFw0wOTEwMDEx MjQ1MDdaFw0xMjA5MzAxMjQ1MDdaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtSV1RIIEFhY2hl bjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCw KpV77WtQa3ZIx+dWRTgR8wxSUsQoSEY2Do5wNPJ/m3hO3P7e8FfVKSaTimKHvRPiRvCX+HW2ldMA f33GWtJTrN6hbSHzQTpq84uQOp/R8ad094wdKbenITaOWISEAjymgA0gS1RpvxaOv5r9uw1Th2ci kjWEOA3tIXCFwFwfMzA/QllikzSkbmm8a6RryOUyQCqCpt9GGS0i1KC+NIa/GP883S4W4En9PxA+ VJ4hJFwjnIt0E+wUigPBQvLHxRqBT/sXSJxsSZO/uNR99dxKeQmdd4Uob5olMA94uZX/rbeZdgDu 49qSIlx/bEFzJTQzH7yDATed6nXGDojAVHeBAgMBAAGjggHDMIIBvzAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR0O BBYEFN+tg8k5s/o7Bjed1LmJouNUa4NUMB8GA1UdIwQYMBaAFG7VPsAcL3HJPL9JTu9qVUjs0fI4 MCgGA1UdEQQhMB+BHXJlbmUuaHVtbWVuQGNzLnJ3dGgtYWFjaGVuLmRlMHkGA1UdHwRyMHAwNqA0 oDKGMGh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvcnd0aC1jYS9wdWIvY3JsL2NhY3JsLmNybDA2oDSg MoYwaHR0cDovL2NkcDIucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGUBggr BgEFBQcBAQSBhzCBhDBABggrBgEFBQcwAoY0aHR0cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNh L3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBABggrBgEFBQcwAoY0aHR0cDovL2NkcDIucGNhLmRmbi5k ZS9yd3RoLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAmXPLNSHW Ze3V4Rq3P2pcaBIlY4Z/nJ1jH3u6yBD3gGZrthpu1o0g45hOWbcvkkcQwvEXKlnWeiVXJsQ2XElz ydNFQprK9GFRZvuOJUkMdR87uupqLESpoue7kmTVCFcqg8c/Q9D5KTbTTtrGDydcqKy+MWbrbtGb lg0R8ZJmnIlb+8RLCqa4MbYq2M2kiImYzDrczlPWvy3SHiPASNFf31XDLFP26QlO3USacm/E+CfM sgQFudf9BqE6yW8qoqx0x1xyMdo5tWyT1MUKsDA/cGADc+r2orBNBsZ7AjdPi85fJS3NE2PGhMEZ BCsvt/EC/yIQK7O3DwELk0VlVaE/uDCCBOgwggPQoAMCAQICBAnydOAwDQYJKoZIhvcNAQEFBQAw WjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAi BgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0wNzAyMTQxMTQ5MzhaFw0xOTAy MTMwMDAwMDBaMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtSV1RIIEFhY2hlbjEXMBUGA1UEAxMO UldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3dGgtYWFjaGVuLmRlMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuDAIZOPI3HpS3zVCOZLzL/gheeMSZy+Mf3CUJzdjSHeg id36rNLIjtnsSAAn83Y8TlKUOmRTp+aXU704u7LZ5PFgGj/3fSxXfJPRm8Y4e8Ydy/tGt2nPv7Ry XF+euJ7VMRrVRjLkoRKFGmVE+X8Pe0y9+lCfDqly66qXQCnBSmifqYEadoEy4+DDVDD4wOBpbLaY 6C50/vqhZu7f2UvdvxNzqjSVMBx+gt+b0q6FbHJoPmu18U+lOCTvfTGMTXEyDM4T0vWLaft9NsO4 udXWgY69IRRjytJy0leoL++8wUhSewFRiScQUlMw59MZAy2L2cKmnmJI/JAwdqEnkcnxowIDAQAB o4IBsDCCAawwDwYDVR0TAQH/BAUwAwEB/zALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFG7VPsAcL3HJ PL9JTu9qVUjs0fI4MB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOB EWNhQHJ3dGgtYWFjaGVuLmRlMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRm bi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIu cGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEE gZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRl L2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEA F4d+xiwLHCB61akGKxuT/3WFC8QLHlOsblyp0qVU5zFlRX9U7Tf6dg/vF0yrZfwOFpWGvZ6fjjW5 VnEtZybLmH+zfcKzuMwhHFQTSyABwmN2VxviKDR8IF6kmKlx86wEGY5Eia9UX2xROJ41MtJzYbQu dR19KJ4Fn6jg3Os+2hfcHttOteTIfCpPLqMeF4Iyy1f1Iz1ZcEQJ7mCHhdMMnL0Oo8/zyTLjq10o aano6WokV6isfKD1wJQnJ6KkS5UHNS9IsEBwZ9BJurQ5jB3GoW3/UgTlomfPjtGr+JcvAkPeaJM/ YbaPVBK11CMzXmtgEFwbZSMiyyoFbmD3+ItyMjGCAt4wggLaAgEBMGYwXjELMAkGA1UEBhMCREUx FDASBgNVBAoTC1JXVEggQWFjaGVuMRcwFQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3 DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUCBA7kIeMwCQYFKw4DAhoFAKCCAU0wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMjMxMTcwNDE5WjAjBgkqhkiG9w0BCQQx FgQUDKdeQlKdWWzNosCoDw1ZnME7XsAwdQYJKwYBBAGCNxAEMWgwZjBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIEDuQh4zB3BgsqhkiG9w0BCRACCzFooGYwXjELMAkGA1UE BhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcwFQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4G CSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUCBA7kIeMwDQYJKoZIhvcNAQEBBQAEggEAVBS0 3vXN6D2j2NMMRhrF9V8BA/VxBmiNYu9ptr2Uk1PDeY/bJuFlkFytpDMW83/iApcVZ4VV7M5+f8lg k+cnn9N/dAU5dcSuUxxjvxY9ERKISLu2t/551ZP94LpzOUmd8mPjsa2zTXzbf57EFx/c9Bw2mNE8 4Nwe+WRqwO4nIS0YorcyGEtyZnLjD42H5k34Mbm2aQlrdhjqUkAe5DzYuTmvbOmlZgBWnoe8BOuq D4ibPCieqJlVQ16wVYB84m94YBT2YU7FZunr7uF0tJcv5dZvqrMgSl/jMBSTXgniQvKKX8Y9Qlhc 27wF+uRouie+ssfp8h4//1YsV3bVsIT9HAAAAAAAAA== --Apple-Mail-133--848491416--