From julien.ietf@gmail.com Thu Jul 5 17:37:24 2012 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 B877121F8478 for ; Thu, 5 Jul 2012 17:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 8Uc59lDPrmgF for ; Thu, 5 Jul 2012 17:37:23 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD8521F842D for ; Thu, 5 Jul 2012 17:37:23 -0700 (PDT) Received: by ghbg16 with SMTP id g16so8895742ghb.31 for ; Thu, 05 Jul 2012 17:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eG5bQx+7Zqa9LTpgyKmOt1LBq7Xw3mBEsi4viuzjc/4=; b=fgS7XWpKT//5fLKbZha70HOl7y+jgOH8Nvle4o3LCX0ctg7UZdXz38rZb/jsI5iGH4 W2HHV648Uwm46Okgtdq/jFDhwq5ilCbrKuNutqoDazRDnh95T+GexNfeEMFkxdkv9VDT bvpL9iWx6/K8s/A4SoKDS2cwWCFNwS/vB6fUwG5s7N4KURtdQah2MqgeHpi8M+UZUdVs 0pq1iuiYlMCxFKNKd1Qqz0kl6Af38o5H375Gl2V0RJhbOj3w5aLK9azsG9gkuRVqhjw7 o2jH8QAR01/9FHYmvnCg9BfhIaOzB+J3PR1ejU4uYMnyCCErXiioymlhXZ0yugPuExFa jsHA== MIME-Version: 1.0 Received: by 10.66.81.106 with SMTP id z10mr40946375pax.26.1341535054751; Thu, 05 Jul 2012 17:37:34 -0700 (PDT) Received: by 10.68.138.137 with HTTP; Thu, 5 Jul 2012 17:37:34 -0700 (PDT) In-Reply-To: <4FEA1876.900@cs.rwth-aachen.de> References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> Date: Thu, 5 Jul 2012 17:37:34 -0700 Message-ID: From: Julien Laganier To: Tobias Heer Content-Type: text/plain; charset=ISO-8859-1 Cc: hipsec@ietf.org, Julien Laganier Subject: Re: [Hipsec] Status of WG items 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: Fri, 06 Jul 2012 00:37:25 -0000 Hi everyone, Sorry for the delay. Here's an update from my side: - 4843bis (ORCHIDv2) is ready for WGLC as soon as I incorporate the update ORCHIDv2 generation algorithm. I will do this ASAP - 5203bis (registration) can IMHO be republished as is as I haven't seen any issue with the original version. If people agree I could republish it and we could WGLC it... - 5204bis (rendezvous) needs one more subsection regarding relaying of the UPDATE packet to support double jump of mobile nodes. As this isn't really useful without the mobility support my proposal is to tackle this one together with the 5206bis. -5205bis (DNS support) lacks a DNS RR format for ECC support as per 5201bis, and we also need to make sure the new ORCHIDv2 support has no implications on the DNS RR format. Work in progress... Comments? --julien On Tue, Jun 26, 2012 at 1:15 PM, Tobias Heer wrote: > Hi, > > Am 26.06.2012 20:06, schrieb Henderson, Thomas R: > >> Gonzalo, >> >> I'm the editor of 5206-bis (mobility), which recently expired. There are >> 13 issues in the tracker, and I've been letting them sit for now in an >> effort to get the first batch of WG documents ready for WGLC (namely, 4423, >> 4843, 5201, and 5202). I'll turn my attention back to 5206-bis open issues >> once we get at least 4843, 5201, and 5202 done. >> >> I'm also a co-author on 5201-bis. We have only three open issues on that >> draft, one of which is to align 4843-bis with 5201-bis, and the other two >> pertaining to some cryptography issues that seem close to being resolved. I >> will post some suggested text to the list for these two items. >> > I agree with Tom. Only few issues remain for 5201-bis. All comments from the > reviewers have been adressed and we are really close to finalizing the > document. > > What remains open are the changes to the ORCHID document. Without these > changes, 5201-bis is incomplete. However, these are minor changes and Julien > already suggested text on the list. Therefore, I believe he can do these > changes quickly. > > Tobias > > >> I believe that we are close now to being able to request a WGLC on 4843, >> 5201, and 5202 bis documents, and I'd like to see that happen before the >> Vancouver meeting. >> >> - Tom >> >>> -----Original Message----- >>> From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On >>> Behalf Of Gonzalo Camarillo >>> Sent: Tuesday, June 26, 2012 1:15 AM >>> To: HIP >>> Subject: [Hipsec] Status of WG items >>> >>> Folks, >>> >>> the list has been relatively quiet lately and the energy within this WG >>> has also been quite low in general in the last months. Could the >>> editors of all our WG items please let this mailing list know what the >>> status of each document is and what the next steps are? >>> >>> Thanks, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/hipsec >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From thomas.r.henderson@boeing.com Mon Jul 9 09:10:17 2012 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 2FB0D21F85CD for ; Mon, 9 Jul 2012 09:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 JMYhSirJaXst for ; Mon, 9 Jul 2012 09:10:16 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 903C721F85C7 for ; Mon, 9 Jul 2012 09:10:16 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q69GAesQ028159 for ; Mon, 9 Jul 2012 09:10:40 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q69GAdPD028153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Jul 2012 09:10:39 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q69GAeLZ032597; Mon, 9 Jul 2012 09:10:40 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q69GAdRB032564 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 9 Jul 2012 09:10:40 -0700 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 9 Jul 2012 09:10:39 -0700 From: "Henderson, Thomas R" To: "'Julien Laganier'" , Tobias Heer Date: Mon, 9 Jul 2012 09:10:39 -0700 Thread-Topic: [Hipsec] Status of WG items Thread-Index: Ac1bD47vRms7PXPLRqCsjzNuEVfLRQC3K5iA Message-ID: <758141CC3D829043A8C3164DD3D593EA1BD324E170@XCH-NW-16V.nw.nos.boeing.com> References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "hipsec@ietf.org" , Julien Laganier Subject: Re: [Hipsec] Status of WG items 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, 09 Jul 2012 16:10:17 -0000 > -----Original Message----- > From: hipsec-bounces@ietf.org [mailto:hipsec-bounces@ietf.org] On > Behalf Of Julien Laganier > Sent: Thursday, July 05, 2012 5:38 PM > To: Tobias Heer > Cc: hipsec@ietf.org; Julien Laganier > Subject: Re: [Hipsec] Status of WG items >=20 > Hi everyone, >=20 > Sorry for the delay. >=20 > Here's an update from my side: >=20 > - 4843bis (ORCHIDv2) is ready for WGLC as soon as I incorporate the > update ORCHIDv2 generation algorithm. I will do this ASAP > - 5203bis (registration) can IMHO be republished as is as I haven't > seen any issue with the original version. If people agree I could > republish it and we could WGLC it... I had a read of this document and agree with your suggestion to move it for= ward with this initial set (as it provides no technical changes from RFC 52= 03). > - 5204bis (rendezvous) needs one more subsection regarding relaying of > the UPDATE packet to support double jump of mobile nodes. As this isn't > really useful without the mobility support my proposal is to tackle > this one together with the 5206bis. +1. I'll post a refresh of 5206bis before the meeting cutoff. A refresh o= f 5204bis (as well as 5205bis) would also be appropriate. - Tom From thomas.r.henderson@boeing.com Mon Jul 9 09:53:23 2012 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 A2CF521F87FD for ; Mon, 9 Jul 2012 09:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 j-27Bh8TLjnl for ; Mon, 9 Jul 2012 09:53:23 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id E1FAA21F87D3 for ; Mon, 9 Jul 2012 09:53:20 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q69GrnN8032204 for ; Mon, 9 Jul 2012 09:53:49 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q69GrmA3032191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Jul 2012 09:53:48 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q69Grit6017016; Mon, 9 Jul 2012 11:53:44 -0500 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q69Gr4k1015293 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 9 Jul 2012 11:53:44 -0500 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.238]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Mon, 9 Jul 2012 09:53:33 -0700 From: "Henderson, Thomas R" To: =?iso-8859-1?Q?=27Ren=E9_Hummen=27?= Date: Mon, 9 Jul 2012 09:53:32 -0700 Thread-Topic: [Hipsec] rfc5201-bis issue 29: Use different RSA mode OAEP/PSS Thread-Index: Ac1V1du+zNwjkQ8KRS2F4z95srTDmAIGdZqgAAAD5oA= Message-ID: <758141CC3D829043A8C3164DD3D593EA1BD324E175@XCH-NW-16V.nw.nos.boeing.com> References: <758141CC3D829043A8C3164DD3D593EA1BD324E174@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA1BD324E174@XCH-NW-16V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] rfc5201-bis issue 29: Use different RSA mode OAEP/PSS 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, 09 Jul 2012 16:53:24 -0000 Ren=E9, a few replies are inline below: > From: Ren=E9 Hummen [mailto:rene.hummen@cs.rwth-aachen.de] > Sent: Friday, June 29, 2012 2:02 AM > To: HIP WG > Cc: Henderson, Thomas R > Subject: Re: [Hipsec] rfc5201-bis issue 29: Use different RSA mode > OAEP/PSS >=20 > A few comments from my side in line. >=20 > On 27.06.2012, at 06:10, Henderson, Thomas R wrote: > Regarding this open issue, which I posted about on June 18 [*], I > propose the following changes to the RFC 5201-bis text: >=20 > 1) Section 3 >=20 > OLD TEXT: >=20 > =A0=A0HIP implementations MUST support the Rivest Shamir Adelman (RSA) > =A0=A0[RFC3110] public key algorithm, and SHOULD support the Digital > =A0=A0Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve > =A0=A0Digital Signature Algorithm (ECDSA) for generating the HI as define= d > =A0=A0in Section 5.2.9. =A0Additional algorithms MAY be supported. >=20 > NEW TEXT: >=20 > =A0=A0HIP implementations MUST support the Rivest Shamir Adelman (RSA) > =A0=A0[RFC3110] public key algorithm and Elliptic Curve > =A0=A0Digital Signature Algorithm (ECDSA) for generating the HI as define= d > =A0=A0in Section 5.2.9. =A0Additional algorithms MAY be supported. >=20 > ECC libraries are available for most consumer-targeting platforms > nowadays. Examples are the relic-toolkit [1] and OpenSSL. Hence, I > don't see requiring both algorithms as a major concern. However: > 1) What exactly are the practical implications of requiring both RSA > and ECDSA? I don't see much of an implementation burden in requiring both (at least fo= r implementations like OpenHIP). I anticipate that HIP DEX will likely be = the spec used for resource constrained devices, so this shouldn't impact th= at use case. > 2) Resource-constrained devices may only support ECC crypto. Would it > make sense to move away from RSA as REQUIRED (seeing that ECC for PC- > grade platforms is widely available) or is this perceived as too > drastical of a measure? >=20 > [1]=A0http://code.google.com/p/relic-toolkit/ I don't have a strong opinion on this, but it was the suggestion offered by= Uri Blumenthal on the cfrg list to move away from RSA, although he also al= luded to the large RSA installed base; hence the suggestion to make both RS= A and ECDSA required to facilitate the migration:=20 http://www.ietf.org/mail-archive/web/cfrg/current/msg03151.html >=20 > Note, I decided not to bother with adding OEAP or ECIES to the cipher > list, since we already have symmetric keys available and the ENCRYPTED > parameter is lightly used. =A0If someone would like to support it in > addition to AES-CBC, please propose a specific text proposal. >=20 > The only use case for OEAP that I can see is if the I1 or R1 should > contain confidential information for some reason. Further ahead in the > handshake, I also don't see the need to use PK crypto for the ENCRYPTED > parameter as symmetric keys are already available at this point. > However, if an extension of HIP should need confidential information in > I1 or R1, it can specify this CIPHER_ID itself. >=20 I came to a similar conclusion. Thanks for the feedback, Tom From rene.hummen@informatik.rwth-aachen.de Mon Jul 9 11:36:20 2012 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 A49BF11E81AB for ; Mon, 9 Jul 2012 11:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 7PMHMC+Jjg29 for ; Mon, 9 Jul 2012 11:36:19 -0700 (PDT) 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 8A93611E80EE for ; Mon, 9 Jul 2012 11:36:13 -0700 (PDT) MIME-version: 1.0 Received: from mx-out-2.rwth-aachen.de ([134.130.5.187]) 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 <0M6W000OAP1198B0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Mon, 09 Jul 2012 20:36:37 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.77,553,1336341600"; d="p7s'?scan'208,217";a="95944867" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by mx-2.rz.rwth-aachen.de with ESMTP; Mon, 09 Jul 2012 20:36:37 +0200 Received: from [192.168.2.11] ([unknown] [93.129.21.193]) 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 <0M6W008VLP113C00@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Mon, 09 Jul 2012 20:36:37 +0200 (CEST) Content-type: multipart/signed; boundary="Apple-Mail=_505F3AB7-4DEF-4E21-984E-0B1046E077B5"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Ren=E9_Hummen?= In-reply-to: <758141CC3D829043A8C3164DD3D593EA1BD324E175@XCH-NW-16V.nw.nos.boeing.com> Date: Mon, 09 Jul 2012 20:36:36 +0200 Message-id: References: <758141CC3D829043A8C3164DD3D593EA1BD324E174@XCH-NW-16V.nw.nos.boeing.com> <758141CC3D829043A8C3164DD3D593EA1BD324E175@XCH-NW-16V.nw.nos.boeing.com> To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.1278) Cc: HIP WG Subject: Re: [Hipsec] rfc5201-bis issue 29: Use different RSA mode OAEP/PSS 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, 09 Jul 2012 18:36:20 -0000 --Apple-Mail=_505F3AB7-4DEF-4E21-984E-0B1046E077B5 Content-Type: multipart/alternative; boundary="Apple-Mail=_7ED2F5F6-F301-43B5-8CD3-A118BC1CF5E3" --Apple-Mail=_7ED2F5F6-F301-43B5-8CD3-A118BC1CF5E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 09.07.2012, at 18:53, Henderson, Thomas R wrote: > Ren=E9, a few replies are inline below: >=20 >> From: Ren=E9 Hummen [mailto:rene.hummen@cs.rwth-aachen.de] >> Sent: Friday, June 29, 2012 2:02 AM >> To: HIP WG >> Cc: Henderson, Thomas R >> Subject: Re: [Hipsec] rfc5201-bis issue 29: Use different RSA mode >> OAEP/PSS >> 2) Resource-constrained devices may only support ECC crypto. Would it >> make sense to move away from RSA as REQUIRED (seeing that ECC for PC- >> grade platforms is widely available) or is this perceived as too >> drastical of a measure? >>=20 >> [1] http://code.google.com/p/relic-toolkit/ >=20 > I don't have a strong opinion on this, but it was the suggestion = offered by Uri Blumenthal on the cfrg list to move away from RSA, = although he also alluded to the large RSA installed base; hence the = suggestion to make both RSA and ECDSA required to facilitate the = migration:=20 >=20 > http://www.ietf.org/mail-archive/web/cfrg/current/msg03151.html He makes a very good point when mentioning RSA-based certificates. To = me, that sounds like a good reason to require RSA. BR Ren=E9 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21429 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ --Apple-Mail=_7ED2F5F6-F301-43B5-8CD3-A118BC1CF5E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Ren=E9, a few replies are = inline below:

From: Ren=E9 Hummen = [mailto:rene.hummen@cs.rwth-aachen.de]
Sent: Friday, June 29, 2012 2:02 = AM
To: HIP = WG
Cc: Henderson, Thomas = R
Subject: Re: [Hipsec] = rfc5201-bis issue 29: Use different RSA mode
OAEP/PSS

2) Resource-constrained = devices may only support ECC crypto. Would = it
make sense to move away = from RSA as REQUIRED (seeing that ECC for = PC-
grade platforms is widely = available) or is this perceived as too
drastical of a measure?

[1] http://code.google.com/p/= relic-toolkit/

I don't have a strong opinion on = this, but it was the suggestion offered by Uri Blumenthal on the cfrg = list to move away from RSA, although he also alluded to the large RSA = installed base; hence the suggestion to make both RSA and ECDSA required = to facilitate the migration:

h= ttp://www.ietf.org/mail-archive/web/cfrg/current/msg03151.html

He makes a very good point when = mentioning RSA-based certificates. To me, that sounds like a good reason = to require RSA.

BR
Ren=E9


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

= --Apple-Mail=_7ED2F5F6-F301-43B5-8CD3-A118BC1CF5E3-- --Apple-Mail=_505F3AB7-4DEF-4E21-984E-0B1046E077B5 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 MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNzA5MTgzNjM3WjAjBgkqhkiG9w0BCQQx FgQU1FMCLoJjvwm29TMMO01hgkzL3twwdQYJKwYBBAGCNxAEMWgwZjBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIEDuQh4zB3BgsqhkiG9w0BCRACCzFooGYwXjELMAkGA1UE BhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcwFQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4G CSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUCBA7kIeMwDQYJKoZIhvcNAQEBBQAEggEAKD+c dXYMUVKuK3GNbR4IR06XLfADTgx3j/i0C5EpKcfUcrq1lE+5/J1dUlK5MuOgR5A1qN4jDyE29UwO VfmiVJrJQXoki6pLtvBZKFc6AAgAWwLFgRCQ9cGq2ZsnMdBs+UpExb8eBUE/elzi5Xq46iGyIJrT W+hxQzvC5u8akxxpS+ObR+U3tuFqcdTP3TQ1DGd68+EP+WJAV6rXNEgJ4sMHVIxpHVKnqHzSVsz9 b1HtMJPfWSqkhzzgT33avzVQXzaOjeeWEZeLcuHWi/1j/z7vKYZZC0HIPMSyrsmrUswArvCnuDpn 7NHTVKI3HyCkkpzJFoXlT4z0xkGpZfTz8gAAAAAAAA== --Apple-Mail=_505F3AB7-4DEF-4E21-984E-0B1046E077B5-- From rene.hummen@informatik.rwth-aachen.de Tue Jul 10 00:59:19 2012 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 987E511E80B7 for ; Tue, 10 Jul 2012 00:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 fiXtQLFURTAs for ; Tue, 10 Jul 2012 00:59:18 -0700 (PDT) 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 3C2A111E808E for ; Tue, 10 Jul 2012 00:59:17 -0700 (PDT) MIME-version: 1.0 Received: from mx-out-2.rwth-aachen.de ([134.130.5.187]) 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 <0M6X006XOQ7KVF50@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Tue, 10 Jul 2012 09:59:44 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.77,558,1336341600"; d="p7s'?scan'208,217";a="96005005" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by mx-2.rz.rwth-aachen.de with ESMTP; Tue, 10 Jul 2012 09:59:44 +0200 Received: from i4-mbp.informatik.rwth-aachen.de ([unknown] [137.226.12.102]) 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 <0M6X00HGUQ7JF970@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Tue, 10 Jul 2012 09:59:44 +0200 (CEST) From: =?iso-8859-1?Q?Ren=E9_Hummen?= Content-type: multipart/signed; boundary="Apple-Mail=_2B2421CD-DB0F-4519-9273-D7204B50C04A"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 10 Jul 2012 09:59:43 +0200 References: <20120709153305.18580.40198.idtracker@ietfa.amsl.com> To: HIP WG , hiprg@irtf.org Message-id: <152C43C6-BCF4-4EF8-8653-4CB5E3F18683@cs.rwth-aachen.de> X-Mailer: Apple Mail (2.1278) Subject: [Hipsec] Fwd: New Version Notification for draft-hummen-hip-middle-puzzle-00.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: Tue, 10 Jul 2012 07:59:19 -0000 --Apple-Mail=_2B2421CD-DB0F-4519-9273-D7204B50C04A Content-Type: multipart/alternative; boundary="Apple-Mail=_3EA2CAB7-0486-4750-B8F4-8370777AAAEC" --Apple-Mail=_3EA2CAB7-0486-4750-B8F4-8370777AAAEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi all, I just submitted the new I-D below. It tackles issues with the HIP = puzzle mechanism that arise from the high resource diversity when = resource-constrained devices communicate with today's = desktop/server-class devices. Your comments are very welcome. BR Ren=E9 Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-hummen-hip-middle-puzzle-00.txt > Date: 9. Juli 2012 17:33:05 MESZ > To: hummen@cs.rwth-aachen.de > Cc: henze@comsys.rwth-aachen.de >=20 >=20 > A new version of I-D, draft-hummen-hip-middle-puzzle-00.txt > has been successfully submitted by Rene Hummen and posted to the > IETF repository. >=20 > Filename: draft-hummen-hip-middle-puzzle > Revision: 00 > Title: HIP Middlebox Puzzle Offloading and End-host = Notification > Creation date: 2012-07-09 > WG ID: Individual Submission > Number of pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-hummen-hip-middle-puzzle-00.txt > Status: = http://datatracker.ietf.org/doc/draft-hummen-hip-middle-puzzle > Htmlized: = http://tools.ietf.org/html/draft-hummen-hip-middle-puzzle-00 >=20 >=20 > Abstract: > The Host Identity Protocol [RFC5201] is a secure signaling protocol > with a cryptographic namespace. It provides the communicating peers > with a cryptographic puzzle mechanism to protect against Denial of > Service (DoS) attacks targeting its computation and memory overhead. > This document specifies an extension that enables middleboxes to > assist in the choice of the puzzle difficulty as well as in solving > the puzzle on behalf of the host. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21429 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ --Apple-Mail=_3EA2CAB7-0486-4750-B8F4-8370777AAAEC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Subject: New Version Notification for = draft-hummen-hip-middle-puzzle-00.txt
Date: 9. Juli 2012 = 17:33:05 MESZ


A new version of I-D, = draft-hummen-hip-middle-puzzle-00.txt
has been successfully submitted = by Rene Hummen and posted to the
IETF = repository.

Filename: = draft-hummen-hip-middle-puzzle
Revision: 00
Title: HIP = Middlebox Puzzle Offloading and End-host Notification
Creation = date: = 2012-07-09
WG ID: Individual Submission
Number = of pages: 13
URL: =             http://www.ietf.org/internet-drafts/draft-hummen-hip-middle-puzzl= e-00.txt
Status: =          ht= tp://datatracker.ietf.org/doc/draft-hummen-hip-middle-puzzle
Htmliz= ed:        http= ://tools.ietf.org/html/draft-hummen-hip-middle-puzzle-00


Ab= stract:
  The Host Identity Protocol [RFC5201] is a secure = signaling protocol
  with a cryptographic namespace. =  It provides the communicating peers
  with a = cryptographic puzzle mechanism to protect against Denial of
=   Service (DoS) attacks targeting its computation and memory = overhead.
  This document specifies an extension that = enables middleboxes to
  assist in the choice of the = puzzle difficulty as well as in solving
  the puzzle on = behalf of the host.





The IETF = Secretariat



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

= --Apple-Mail=_3EA2CAB7-0486-4750-B8F4-8370777AAAEC-- --Apple-Mail=_2B2421CD-DB0F-4519-9273-D7204B50C04A 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 MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNzEwMDc1OTQ0WjAjBgkqhkiG9w0BCQQx FgQUhu0rQYCRJwhfmdi1bCzlBe/Qez8wdQYJKwYBBAGCNxAEMWgwZjBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIEDuQh4zB3BgsqhkiG9w0BCRACCzFooGYwXjELMAkGA1UE BhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcwFQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4G CSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUCBA7kIeMwDQYJKoZIhvcNAQEBBQAEggEAkN99 OVy2asaDwnsjFsth3/CCGDE63ZLB4v330rr1Yi7gHr5bANQV0bErhsT9+uGrUn+oD0MxY7/cq4vD KzMA7AMILH67WciuS3LbNw87Uy2g2ogw/tcNRZ9cOFJHOM09fzaA1I8Q0Iqgck8YNdnKvCZZrr3s GEhMv8ndbi3vP9lcnat+hNQJTfaBSYTFIXcr0Edfjx017SKJsgNQN+/u8+w1TlGnNoatgfbacQYn CWj0t105yI/D1yAnwFeT1ic49AdpZqCWd0EzcDLMg/XwP+NXf/tMiT2eME2uqMYDFliebimHde/X A4Ek9MtY7/MRmEzhI2i0NHGpt3NjikK5dgAAAAAAAA== --Apple-Mail=_2B2421CD-DB0F-4519-9273-D7204B50C04A-- From rgm@htt-consult.com Wed Jul 11 11:28:50 2012 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 E74A411E8128 for ; Wed, 11 Jul 2012 11:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 f00aoC+Z+lLR for ; Wed, 11 Jul 2012 11:28:50 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id F306811E8100 for ; Wed, 11 Jul 2012 11:28:49 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id B410F62A62; Wed, 11 Jul 2012 18:28:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiW5tC1O72JZ; Wed, 11 Jul 2012 14:28:49 -0400 (EDT) Received: from lx120e.htt-consult.com (157.67.83.208.client.htt-consult.com [208.83.67.157]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 3ACE262A7C; Wed, 11 Jul 2012 14:28:45 -0400 (EDT) Message-ID: <4FFDC5DC.4060800@htt-consult.com> Date: Wed, 11 Jul 2012 14:28:44 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <758141CC3D829043A8C3164DD3D593EA1BD324E11D@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA1BD324E11D@XCH-NW-16V.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] rfc5201-bis issue 35: limiting ECC cofactor to 1 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, 11 Jul 2012 18:28:51 -0000 I agree. This is pretty much all we need to say about this. On 06/27/2012 01:19 AM, Henderson, Thomas R wrote: > This was already proposed to the list a while back: > http://www.ietf.org/mail-archive/web/hipsec/current/msg03462.html > > so I'd like to close this issue by adopting the proposed text; specifically: > > 1) Section 5.2.7 (Diffie Hellman) > > OLD TEXT: > > The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH > groups 8 - 10 are defined in [RFC5903] and [RFC6090]. ECDH group 7 > is covered in Appendix D. > > NEW TEXT: > > The MODP Diffie-Hellman groups are defined in [RFC3526]. The ECDH > groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH group 10 > is covered in Appendix D. Any ECDH used with HIP MUST have a > co-factor of 1. > > 2) Section 5.2.9 (HOST ID) > > OLD TEXT: > > ... For ECC we distinguish two different profiles: > ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and > defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with > low computational capabilities and uses shorter curves from SECG > [SECG]. > > ... For ECC we distinguish two different profiles: > ECDSA and ECDSA_LOW. ECC contains curves approved by NIST and > defined in RFC 4754 [RFC4754]. ECDSA_LOW is defined for devices with > low computational capabilities and uses shorter curves from SECG > [SECG]. Any ECDSA used with HIP MUST have a co-factor of 1. > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From rgm@htt-consult.com Fri Jul 13 08:13:30 2012 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 BB0EB21F85EF for ; Fri, 13 Jul 2012 08:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 qSfnEhWZh2E1 for ; Fri, 13 Jul 2012 08:13:29 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 4064821F85E1 for ; Fri, 13 Jul 2012 08:13:28 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id EA50662AA4; Fri, 13 Jul 2012 15:13:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92aTgztg2wvd; Fri, 13 Jul 2012 11:13:32 -0400 (EDT) Received: from lx120e.htt-consult.com (157.67.83.208.client.htt-consult.com [208.83.67.157]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 822BB62AA3; Fri, 13 Jul 2012 11:13:31 -0400 (EDT) Message-ID: <50003B16.1020106@htt-consult.com> Date: Fri, 13 Jul 2012 11:13:26 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ren=E9_Hummen?= References: <758141CC3D829043A8C3164DD3D593EA1BCC77C4D3@XCH-NW-16V.nw.nos.boeing.com> <758141CC3D829043A8C3164DD3D593EA1BD24C86A9@XCH-NW-16V.nw.nos.boeing.com> <758141CC3D829043A8C3164DD3D593EA1BD324E0A6@XCH-NW-16V.nw.nos.boeing.com> <758141CC3D829043A8C3164DD3D593EA1BD324E11C@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010401040103040503090006" Cc: HIP WG Subject: Re: [Hipsec] rfc5201-bis issue 29: Use different RSA mode OAEP/PSS 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: Fri, 13 Jul 2012 15:13:31 -0000 This is a multi-part message in MIME format. --------------010401040103040503090006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 06/29/2012 05:02 AM, René Hummen wrote: > A few comments from my side in line. > > On 27.06.2012, at 06:10, Henderson, Thomas R wrote: >> Regarding this open issue, which I posted about on June 18 [*], I >> propose the following changes to the RFC 5201-bis text: >> >> 1) Section 3 >> >> OLD TEXT: >> >> HIP implementations MUST support the Rivest Shamir Adelman (RSA) >> [RFC3110] public key algorithm, and SHOULD support the Digital >> Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve >> Digital Signature Algorithm (ECDSA) for generating the HI as defined >> in Section 5.2.9. Additional algorithms MAY be supported. >> >> NEW TEXT: >> >> HIP implementations MUST support the Rivest Shamir Adelman (RSA) >> [RFC3110] public key algorithm and Elliptic Curve >> Digital Signature Algorithm (ECDSA) for generating the HI as defined >> in Section 5.2.9. Additional algorithms MAY be supported. > > ECC libraries are available for most consumer-targeting platforms > nowadays. Examples are the relic-toolkit [1] and OpenSSL. Hence, I > don't see requiring both algorithms as a major concern. However: > 1) What exactly are the practical implications of requiring both RSA > and ECDSA? > 2) Resource-constrained devices may only support ECC crypto. Would it > make sense to move away from RSA as REQUIRED (seeing that ECC for > PC-grade platforms is widely available) or is this perceived as too > drastical of a measure? > > [1] http://code.google.com/p/relic-toolkit/ > >> 2) Section 5.2.8, HIP cipher >> >> OLD TEXT: >> >> The following Cipher IDs are defined: >> >> Suite ID Value >> >> RESERVED 0 >> NULL-ENCRYPT 1 ([RFC2410]) >> AES-128-CBC 2 ([RFC3602]) >> 3DES-CBC 3 ([RFC2451]) >> AES-256-CBC 4 ([RFC3602]) >> >> NEW TEXT: >> >> The following Cipher IDs are defined: >> >> Suite ID Value >> >> RESERVED 0 >> NULL-ENCRYPT 1 ([RFC2410]) >> AES-128-CBC 2 ([RFC3602]) >> DEPRECATED 3 >> AES-256-CBC 4 ([RFC3602]) > > I agree. > >> 3) Section 5.2.9, Host Id: >> >> OLD TEXT: >> >> The following HI Algorithms have been defined: >> >> Algorithm >> profiles Values >> >> RESERVED 0 >> DSA 3 [RFC2536] (RECOMMENDED) >> RSA 5 [RFC3110] (REQUIRED) >> ECDSA 7 [RFC4754] (RECOMMENDED) >> ECDSA_LOW 9 [SECG] (RECOMMENDED) >> >> NEW TEXT: >> >> The following HI Algorithms have been defined: >> >> Algorithm >> profiles Values >> >> RESERVED 0 >> DSA 3 [FIPS 186-3] (OPTIONAL) >> RSA 5 [RFC3447] (REQUIRED) >> ECDSA 7 [RFC4754] (REQUIRED) >> ECDSA_LOW 9 [SECG] (RECOMMENDED) >> >> For DSA, RSA, and ECDSA key types, profiles containing at least 112 >> bits of security strength (as defined by [NIST SP 800-131A]) should >> be used. For RSA signature padding, the PSS method of padding >> [RFC3447] MUST be used. >> >> ------------ >> >> Note, I decided not to bother with adding OEAP or ECIES to the cipher >> list, since we already have symmetric keys available and the >> ENCRYPTED parameter is lightly used. If someone would like to >> support it in addition to AES-CBC, please propose a specific text >> proposal. > > The only use case for OEAP that I can see is if the I1 or R1 should > contain confidential information for some reason. Crypto in I1 is a clear resource attack. That is in large measure why there IS an I1 packet. I have had to deal with proposals to put signed objects into 802.11 BEACONs and PROBEs. But thinking. R1 confidental information is an interesting thought. It would take a bit to expand on it, but as you note in the end, if someone were to propose this, then they can specify this cipher itself. > Further ahead in the handshake, I also don't see the need to use PK > crypto for the ENCRYPTED parameter as symmetric keys are already > available at this point. However, if an extension of HIP should need > confidential information in I1 or R1, it can specify this CIPHER_ID > itself. --------------010401040103040503090006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/29/2012 05:02 AM, René Hummen wrote:
A few comments from my side in line.

On 27.06.2012, at 06:10, Henderson, Thomas R wrote:
Regarding this open issue, which I posted about on June 18 [*], I propose the following changes to the RFC 5201-bis text:

1) Section 3

OLD TEXT:

  HIP implementations MUST support the Rivest Shamir Adelman (RSA)
  [RFC3110] public key algorithm, and SHOULD support the Digital
  Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve
  Digital Signature Algorithm (ECDSA) for generating the HI as defined
  in Section 5.2.9.  Additional algorithms MAY be supported.

NEW TEXT:

  HIP implementations MUST support the Rivest Shamir Adelman (RSA)
  [RFC3110] public key algorithm and Elliptic Curve
  Digital Signature Algorithm (ECDSA) for generating the HI as defined
  in Section 5.2.9.  Additional algorithms MAY be supported.

ECC libraries are available for most consumer-targeting platforms nowadays. Examples are the relic-toolkit [1] and OpenSSL. Hence, I don't see requiring both algorithms as a major concern. However:
1) What exactly are the practical implications of requiring both RSA and ECDSA?
2) Resource-constrained devices may only support ECC crypto. Would it make sense to move away from RSA as REQUIRED (seeing that ECC for PC-grade platforms is widely available) or is this perceived as too drastical of a measure?


2) Section 5.2.8, HIP cipher

OLD TEXT:

  The following Cipher IDs are defined:

       Suite ID           Value

       RESERVED           0
       NULL-ENCRYPT       1     ([RFC2410])
       AES-128-CBC        2     ([RFC3602])
       3DES-CBC           3     ([RFC2451])
       AES-256-CBC        4     ([RFC3602])

NEW TEXT:

  The following Cipher IDs are defined:

       Suite ID           Value

       RESERVED           0
       NULL-ENCRYPT       1     ([RFC2410])
       AES-128-CBC        2     ([RFC3602])
       DEPRECATED         3     
       AES-256-CBC        4     ([RFC3602])

I agree.

3) Section 5.2.9, Host Id:

OLD TEXT:  

  The following HI Algorithms have been defined:

       Algorithm
       profiles         Values

       RESERVED         0
       DSA              3 [RFC2536] (RECOMMENDED)
       RSA              5 [RFC3110] (REQUIRED)
       ECDSA            7 [RFC4754] (RECOMMENDED)
       ECDSA_LOW        9 [SECG]    (RECOMMENDED)

NEW TEXT:

  The following HI Algorithms have been defined:

       Algorithm
       profiles         Values

       RESERVED         0
       DSA              3 [FIPS 186-3] (OPTIONAL)
       RSA              5 [RFC3447]    (REQUIRED)
       ECDSA            7 [RFC4754]    (REQUIRED)
       ECDSA_LOW        9 [SECG]       (RECOMMENDED)

 For DSA, RSA, and ECDSA key types, profiles containing at least 112
 bits of security strength (as defined by [NIST SP 800-131A]) should
 be used.  For RSA signature padding, the PSS method of padding
 [RFC3447] MUST be used.

------------

Note, I decided not to bother with adding OEAP or ECIES to the cipher list, since we already have symmetric keys available and the ENCRYPTED parameter is lightly used.  If someone would like to support it in addition to AES-CBC, please propose a specific text proposal.

The only use case for OEAP that I can see is if the I1 or R1 should contain confidential information for some reason.

Crypto in I1 is a clear resource attack.  That is in large measure why there IS an I1 packet.  I have had to deal with proposals to put signed objects into 802.11 BEACONs and PROBEs.  But thinking.

R1 confidental information is an interesting thought.  It would take a bit to expand on it, but as you note in the end, if someone were to propose this, then they can specify this cipher itself.

Further ahead in the handshake, I also don't see the need to use PK crypto for the ENCRYPTED parameter as symmetric keys are already available at this point. However, if an extension of HIP should need confidential information in I1 or R1, it can specify this CIPHER_ID itself.


--------------010401040103040503090006-- From rgm@htt-consult.com Fri Jul 13 08:25:49 2012 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 DD86721F8780 for ; Fri, 13 Jul 2012 08:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 7Za+zo56SIN4 for ; Fri, 13 Jul 2012 08:25:48 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id B1D7521F8787 for ; Fri, 13 Jul 2012 08:25:47 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id EEDBD62A8C; Fri, 13 Jul 2012 15:26:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQGrPiOU2grk; Fri, 13 Jul 2012 11:25:52 -0400 (EDT) Received: from lx120e.htt-consult.com (157.67.83.208.client.htt-consult.com [208.83.67.157]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1230462A7A; Fri, 13 Jul 2012 11:25:51 -0400 (EDT) Message-ID: <50003DFE.60805@htt-consult.com> Date: Fri, 13 Jul 2012 11:25:50 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: "Henderson, Thomas R" References: <758141CC3D829043A8C3164DD3D593EA1BCC77C4D3@XCH-NW-16V.nw.nos.boeing.com> <758141CC3D829043A8C3164DD3D593EA1BD24C86A9@XCH-NW-16V.nw.nos.boeing.com> <758141CC3D829043A8C3164DD3D593EA1BD324E0A6@XCH-NW-16V.nw.nos.boeing.com> <758141CC3D829043A8C3164DD3D593EA1BD324E11C@XCH-NW-16V.nw.nos.boeing.com> In-Reply-To: <758141CC3D829043A8C3164DD3D593EA1BD324E11C@XCH-NW-16V.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: HIP Subject: Re: [Hipsec] rfc5201-bis issue 29: Use different RSA mode OAEP/PSS 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: Fri, 13 Jul 2012 15:25:49 -0000 On 06/27/2012 01:10 AM, Henderson, Thomas R wrote: > Regarding this open issue, which I posted about on June 18 [*], I propose the following changes to the RFC 5201-bis text: > > 1) Section 3 > > OLD TEXT: > > HIP implementations MUST support the Rivest Shamir Adelman (RSA) > [RFC3110] public key algorithm, and SHOULD support the Digital > Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve > Digital Signature Algorithm (ECDSA) for generating the HI as defined > in Section 5.2.9. Additional algorithms MAY be supported. > > NEW TEXT: > > HIP implementations MUST support the Rivest Shamir Adelman (RSA) > [RFC3110] public key algorithm and Elliptic Curve > Digital Signature Algorithm (ECDSA) for generating the HI as defined > in Section 5.2.9. Additional algorithms MAY be supported. This is a REALLY important shift for a crypto system. I feel we should take it. Even with the ever increasing power in processors today, there are many reasons of perfer ECDSA keys over RSA. And even with DEX, there are 'mid size' systems plus constained communication links where ECDSA will seriously outperform RSA. > > 2) Section 5.2.8, HIP cipher > > OLD TEXT: > > The following Cipher IDs are defined: > > Suite ID Value > > RESERVED 0 > NULL-ENCRYPT 1 ([RFC2410]) > AES-128-CBC 2 ([RFC3602]) > 3DES-CBC 3 ([RFC2451]) > AES-256-CBC 4 ([RFC3602]) > > NEW TEXT: > > The following Cipher IDs are defined: > > Suite ID Value > > RESERVED 0 > NULL-ENCRYPT 1 ([RFC2410]) > AES-128-CBC 2 ([RFC3602]) > DEPRECATED 3 > AES-256-CBC 4 ([RFC3602]) DES is dead. Long live the new king. I have spoken to a number of serious cryptographers, and I am not overly concerned in only having one block cipher here. > 3) Section 5.2.9, Host Id: > > OLD TEXT: > > The following HI Algorithms have been defined: > > Algorithm > profiles Values > > RESERVED 0 > DSA 3 [RFC2536] (RECOMMENDED) > RSA 5 [RFC3110] (REQUIRED) > ECDSA 7 [RFC4754] (RECOMMENDED) > ECDSA_LOW 9 [SECG] (RECOMMENDED) > > NEW TEXT: > > The following HI Algorithms have been defined: > > Algorithm > profiles Values > > RESERVED 0 > DSA 3 [FIPS 186-3] (OPTIONAL) > RSA 5 [RFC3447] (REQUIRED) > ECDSA 7 [RFC4754] (REQUIRED) > ECDSA_LOW 9 [SECG] (RECOMMENDED) > > For DSA, RSA, and ECDSA key types, profiles containing at least 112 > bits of security strength (as defined by [NIST SP 800-131A]) should > be used. For RSA signature padding, the PSS method of padding > [RFC3447] MUST be used. > > ------------ > > Note, I decided not to bother with adding OEAP or ECIES to the cipher list, since we already have symmetric keys available and the ENCRYPTED parameter is lightly used. If someone would like to support it in addition to AES-CBC, please propose a specific text proposal. I agree with this. There is ONE case and that is to have the ENCRYPT content to have security context outside of the HIP flow. Say to an authentication server. But as indicated, we can let the authors of the ID that proposes such a use case to add the cipher. Oh, I do see use cases where the ENCRYPTED parameter gets more use, but it will be in NOTIFYs. Think of HIP as a secure messaging channel itself without needing the overhead of a full transport protocol. Sort of like secure UDP on the cheap. Tom, thank you for your effort on this. From internet-drafts@ietf.org Fri Jul 13 14:13:22 2012 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 D4B7221F8468; Fri, 13 Jul 2012 14:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 zj6oRjGqm6uj; Fri, 13 Jul 2012 14:13:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395D421F8454; Fri, 13 Jul 2012 14:13:18 -0700 (PDT) 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: 4.30p3 Message-ID: <20120713211318.24795.1783.idtracker@ietfa.amsl.com> Date: Fri, 13 Jul 2012 14:13:18 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc4423-bis-04.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: Fri, 13 Jul 2012 21:13:22 -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 t= he IETF. Title : Host Identity Protocol Architecture Author(s) : Robert Moskowitz Filename : draft-ietf-hip-rfc4423-bis-04.txt Pages : 27 Date : 2012-07-13 Abstract: This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signalling channel. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc4423-bis-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc4423-bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From petri.jokela@nomadiclab.com Sun Jul 15 12:52:18 2012 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 89E1821F8522 for ; Sun, 15 Jul 2012 12:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 5D7aZnIbVAOU for ; Sun, 15 Jul 2012 12:52:18 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id A39F021F84FE for ; Sun, 15 Jul 2012 12:52:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 85A2C4E6EE for ; Sun, 15 Jul 2012 22:52:58 +0300 (EEST) 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 d_aKI3NocUN9 for ; Sun, 15 Jul 2012 22:52:57 +0300 (EEST) Received: from [IPv6:::1] (inside.nomadiclab.com [10.0.0.2]) by gw.nomadiclab.com (Postfix) with ESMTP id F144F4E6D4 for ; Sun, 15 Jul 2012 22:52:56 +0300 (EEST) From: Petri Jokela Content-Type: multipart/alternative; boundary="Apple-Mail=_6FFB06E5-4A5D-4613-A4D4-306D7C5E0318" Date: Sun, 15 Jul 2012 22:52:56 +0300 References: <20120715194123.28132.39720.idtracker@ietfa.amsl.com> To: hipsec@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Hipsec] Fwd: New Version Notification for draft-jokela-hip-rfc5202-bis-03.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: Sun, 15 Jul 2012 19:52:18 -0000 --Apple-Mail=_6FFB06E5-4A5D-4613-A4D4-306D7C5E0318 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi,=20 I just submitted HIP ESP draft, v. -03.=20 I'm on vacation and not reading my e-mails during the next week. So, if = there is a panic with this draft, you can always try to reach me using = my private e-mail (petri@jokela.org) or call me (number at the end of = this mail :) Petri Begin forwarded message: > Subject: New Version Notification for = draft-jokela-hip-rfc5202-bis-03.txt > Filename: draft-jokela-hip-rfc5202-bis > Title: Using the Encapsulating Security Payload (ESP) = Transport Format with the Host Identity Protocol (HIP) > Creation date: 2012-07-15 > URL: = http://www.ietf.org/internet-drafts/draft-jokela-hip-rfc5202-bis-03.txt --=20 Petri Jokela Senior Researcher NomadicLab, Ericsson Research Oy L M Ericsson Ab =20 E-mail: petri.jokela@ericsson.com Mobile: +358 44 299 2413 --Apple-Mail=_6FFB06E5-4A5D-4613-A4D4-306D7C5E0318 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii petri@jokela.org) or call me = (number at the end of this mail = :)

Petri

Begin = forwarded message:

Subject: = New Version Notification for = draft-jokela-hip-rfc5202-bis-03.txt
Filename: = draft-jokela-hip-rfc5202-bis
Title: Using = the Encapsulating Security Payload (ESP) Transport Format with the Host = Identity Protocol (HIP)
Creation date: 2012-07-15
URL: =             http://www.ietf.org/internet-drafts/draft-jokela-hip-rfc5202-bis-03= .txt


-- 
Petri = Jokela
Senior Researcher
NomadicLab, Ericsson Research
Oy L M = Ericsson Ab                 =  

E-mail: petri.jokela@ericsson.comMobile: +358 44 299 2413

= --Apple-Mail=_6FFB06E5-4A5D-4613-A4D4-306D7C5E0318-- From internet-drafts@ietf.org Mon Jul 16 10:43:23 2012 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 5BBF311E825A; Mon, 16 Jul 2012 10:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, 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 022y4UZzOC71; Mon, 16 Jul 2012 10:43:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB3911E8142; Mon, 16 Jul 2012 10:43:22 -0700 (PDT) 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: 4.30p3 Message-ID: <20120716174322.7206.16332.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 10:43:22 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5201-bis-09.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: Mon, 16 Jul 2012 17:43:23 -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 t= he IETF. Title : Host Identity Protocol Version 2 (HIPv2) Author(s) : Robert Moskowitz Tobias Heer Petri Jokela Thomas R. Henderson Filename : draft-ietf-hip-rfc5201-bis-09.txt Pages : 124 Date : 2012-07-16 Abstract: This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-09 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc5201-bis-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 16 16:20:01 2012 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 8FA1B11E80B7; Mon, 16 Jul 2012 16:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 z9+QOFZtZe5S; Mon, 16 Jul 2012 16:19:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A041811E8085; Mon, 16 Jul 2012 16:19:57 -0700 (PDT) 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: 4.30p3 Message-ID: <20120716231957.11662.31430.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 16:19:57 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5206-bis-04.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: Mon, 16 Jul 2012 23:20:02 -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 t= he IETF. Title : Host Mobility with the Host Identity Protocol Author(s) : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-rfc5206-bis-04.txt Pages : 33 Date : 2012-07-16 Abstract: This document defines mobility extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR_SET parameter can also be used to support end-host multihoming, detailed procedures are out of scope for this document. This document obsoletes RFC 5206. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5206-bis-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-rfc5206-bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 16 16:20:11 2012 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 3CB6211E8141; Mon, 16 Jul 2012 16:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 j-3SPieIvLYU; Mon, 16 Jul 2012 16:20:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E33411E80BE; Mon, 16 Jul 2012 16:20:08 -0700 (PDT) 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: 4.30p3 Message-ID: <20120716232008.13858.68346.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 16:20:08 -0700 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-multihoming-01.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: Mon, 16 Jul 2012 23:20:11 -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 t= he IETF. Title : Host Multihoming with the Host Identity Protocol Author(s) : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-multihoming-01.txt Pages : 22 Date : 2012-07-16 Abstract: This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-multihoming-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-multihoming-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ari.keranen@nomadiclab.com Fri Jul 27 09:23:32 2012 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 4A6C321F87C4 for ; Fri, 27 Jul 2012 09:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 TA1mjPzR2bwL for ; Fri, 27 Jul 2012 09:23:31 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id E2E6021F85F0 for ; Fri, 27 Jul 2012 09:23:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 0F2904E6E9; Fri, 27 Jul 2012 19:23:22 +0300 (EEST) 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 aonm3dRB8mJf; Fri, 27 Jul 2012 19:23:21 +0300 (EEST) Received: from tri59.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 3790A4E679; Fri, 27 Jul 2012 19:23:21 +0300 (EEST) Message-ID: <5012C05B.6080203@nomadiclab.com> Date: Fri, 27 Jul 2012 19:22:51 +0300 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Julien Laganier References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Julien Laganier Subject: Re: [Hipsec] Status of WG items 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: Fri, 27 Jul 2012 16:23:32 -0000 Hi Julien, On 7/6/12 3:37 AM, Julien Laganier wrote: > - 5203bis (registration) can IMHO be republished as is as I haven't > seen any issue with the original version. If people agree I could > republish it and we could WGLC it... I posted some comments about 5203bis earlier this year but back then there was no discussion regarding them. So, here goes again. Some of these have been discussed also earlier on this list (these relate to requirements discovered with the native NAT traversal draft [1]), but I'll have them all here for easier reference. Currently, the registrar has no way of indicating that it would otherwise accept the registration, but it's currently running low on resources. For this purpose, a failure type "Insufficient resources" could be added to the "registration failure types". Registration using authentication with certificates could be part of the registration RFC. Currently, only authentication with HI is defined, but knowing all HIs beforehand is not practical in many cases. Text in section 3.2. of [1] could be used as a basis for this (just replace "HIP' data relay" with "registrar"). Also, if this authentication mode is added to the draft, failure type "Invalid certificate" should be added for the failure case. Should we have these in the registration draft? Cheers, Ari [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal From rgm@htt-consult.com Fri Jul 27 12:04:50 2012 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 297E011E80E6 for ; Fri, 27 Jul 2012 12:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 kSUXLE72yUqg for ; Fri, 27 Jul 2012 12:04:49 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAEE11E80D6 for ; Fri, 27 Jul 2012 12:04:49 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id E5F8562AC3; Fri, 27 Jul 2012 19:04:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L74bCX4t56Gg; Fri, 27 Jul 2012 15:04:17 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 422616333F; Fri, 27 Jul 2012 15:04:02 -0400 (EDT) Message-ID: <5012E621.908@htt-consult.com> Date: Fri, 27 Jul 2012 15:04:01 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ari Keranen References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> In-Reply-To: <5012C05B.6080203@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Julien Laganier , Julien Laganier , hipsec@ietf.org Subject: Re: [Hipsec] Status of WG items 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: Fri, 27 Jul 2012 19:04:50 -0000 On 07/27/2012 12:22 PM, Ari Keranen wrote: > Hi Julien, > > On 7/6/12 3:37 AM, Julien Laganier wrote: >> - 5203bis (registration) can IMHO be republished as is as I haven't >> seen any issue with the original version. If people agree I could >> republish it and we could WGLC it... > > I posted some comments about 5203bis earlier this year but back then > there was no discussion regarding them. So, here goes again. > > Some of these have been discussed also earlier on this list (these > relate to requirements discovered with the native NAT traversal draft > [1]), but I'll have them all here for easier reference. > > Currently, the registrar has no way of indicating that it would > otherwise accept the registration, but it's currently running low on > resources. For this purpose, a failure type "Insufficient resources" > could be added to the "registration failure types". > > Registration using authentication with certificates could be part of > the registration RFC. Currently, only authentication with HI is > defined, but knowing all HIs beforehand is not practical in many cases. > > Text in section 3.2. of [1] could be used as a basis for this (just > replace "HIP' data relay" with "registrar"). Also, if this > authentication mode is added to the draft, failure type "Invalid > certificate" should be added for the failure case. > > Should we have these in the registration draft? These are all reasonable. I am more and more looking at HIT authentication services, but I know the value of certificates in processes like this, though I keep taking a look at things like ECQV certs as an alternative to X.509 certs... From william.atwood@concordia.ca Sun Jul 29 16:31:44 2012 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 B0CFB11E8072 for ; Sun, 29 Jul 2012 16:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.043 X-Spam-Level: X-Spam-Status: No, score=-6.043 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, 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 2ek9ren5bmev for ; Sun, 29 Jul 2012 16:31:44 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.94]) by ietfa.amsl.com (Postfix) with ESMTP id DEC0921F8625 for ; Sun, 29 Jul 2012 16:31:43 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id q6TNVf4h002086; Sun, 29 Jul 2012 19:31:41 -0400 Message-ID: <5015C7E1.7080601@concordia.ca> Date: Sun, 29 Jul 2012 19:31:45 -0400 From: John William Atwood Organization: Concordia University, Montreal User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: HIP WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2012/07/29 19:31:42 EDT Cc: Xueyong Zhu Subject: [Hipsec] Multicast for HIP 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: Sun, 29 Jul 2012 23:31:44 -0000 Hello, My name is Bill Atwood. My area of interest is Multicast Security. I have a colleague who is a professor at a university in China. His name is Xueyong Zhu. He visited me for a year as a PostDoctoral fellow, and we worked together on the application of HIP in the area of multicasting; specifically on the use of HIP to securely identify the end users, and therefore allow the Network Service Provider to extract a revenue stream from them. Since then Xueyong has been working on various aspects of this problem with other colleagues at his university. He recently sent me a preliminary Internet Draft with the title "Protocol Independent Multicast-Host Identity Mode (PIM-HIM): Protocol Specification". There appears to be no HIP working group meeting at the Vancouver IETF. I would like to have a face-to-face discussion with anyone interested in the topic of multicast in HIP. This message is to ask that you contact me (off list or on list) to determine a mutually convenient time. I will be free: During the Sunday reception Monday afternoon (11:30 to 15:30) Tuesday morning (until 1030) Tuesday afternoon (after 1500, until the social event) most of Wednesday (until the plenary). Subject, of course, to any changes in the WG meeting times. I have put the draft that Xueyong sent me on my web page at http://users.encs.concordia.ca/~bill/internet-drafts/draft-zhu-hip-pim-him-00-1.doc. Note that this is a Word .doc file, and represents a very preliminary version of the draft. (It would not pass IDnits.) Please confirm whether there could be an opportunity to meet with someone from the active HIP participants. If so, then hopefully we can work out a mutually convenient time to have a face-to-face discussion. For a photo, see my main web page (URL below). Bill Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From ari.keranen@nomadiclab.com Tue Jul 31 09:13:46 2012 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 7A9FB21F86C9 for ; Tue, 31 Jul 2012 09:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 os3Y0n-1lSd2 for ; Tue, 31 Jul 2012 09:13:46 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id C9DED21F86B0 for ; Tue, 31 Jul 2012 09:13:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 9D4904E6E9; Tue, 31 Jul 2012 19:13:43 +0300 (EEST) 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 y7uUAeQgWDpb; Tue, 31 Jul 2012 19:13:43 +0300 (EEST) Received: from dhcp-6227.meeting.ietf.org (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 2719B4E6E6; Tue, 31 Jul 2012 19:13:41 +0300 (EEST) Message-ID: <50180434.8010907@nomadiclab.com> Date: Tue, 31 Jul 2012 09:13:40 -0700 From: Ari Keranen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Robert Moskowitz References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <5012C05B.6080203@nomadiclab.com> <5012E621.908@htt-consult.com> In-Reply-To: <5012E621.908@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julien Laganier , Julien Laganier , hipsec@ietf.org Subject: Re: [Hipsec] Status of WG items 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: Tue, 31 Jul 2012 16:13:46 -0000 On 7/27/12 12:04 PM, Robert Moskowitz wrote: > > On 07/27/2012 12:22 PM, Ari Keranen wrote: >> Hi Julien, >> >> On 7/6/12 3:37 AM, Julien Laganier wrote: >>> - 5203bis (registration) can IMHO be republished as is as I haven't >>> seen any issue with the original version. If people agree I could >>> republish it and we could WGLC it... >> >> I posted some comments about 5203bis earlier this year but back then >> there was no discussion regarding them. So, here goes again. >> >> Some of these have been discussed also earlier on this list (these >> relate to requirements discovered with the native NAT traversal draft >> [1]), but I'll have them all here for easier reference. >> >> Currently, the registrar has no way of indicating that it would >> otherwise accept the registration, but it's currently running low on >> resources. For this purpose, a failure type "Insufficient resources" >> could be added to the "registration failure types". >> >> Registration using authentication with certificates could be part of >> the registration RFC. Currently, only authentication with HI is >> defined, but knowing all HIs beforehand is not practical in many cases. >> >> Text in section 3.2. of [1] could be used as a basis for this (just >> replace "HIP' data relay" with "registrar"). Also, if this >> authentication mode is added to the draft, failure type "Invalid >> certificate" should be added for the failure case. >> >> Should we have these in the registration draft? > > These are all reasonable. I am more and more looking at HIT > authentication services, but I know the value of certificates in > processes like this, though I keep taking a look at things like ECQV > certs as an alternative to X.509 certs... Thanks Bob. Frankly, I'm not a big fan of X.509 certs either, so something else would work for me too. Anyway, something more than "just knowing HIs" would be useful. Cheers, Ari