Re: Security for various IETF services

Hector Santos <hsantos@isdg.net> Fri, 04 April 2014 17:44 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063911A02A5 for <ietf@ietfa.amsl.com>; Fri, 4 Apr 2014 10:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.002
X-Spam-Level:
X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFACRVAOijGZ for <ietf@ietfa.amsl.com>; Fri, 4 Apr 2014 10:44:06 -0700 (PDT)
Received: from listserv.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id F21D31A03A7 for <ietf@ietf.org>; Fri, 4 Apr 2014 10:43:31 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3132; t=1396633397; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=/uUlbdGCrM+e/8f9FnCLU+bipw8=; b=qbEk2+ZZdn3ldxyMA7tz cJD6UUKRNti4grMF0Cim5sHRchQVsZqItkAPVC/13r5HVgjPAJUSOkztD6BlZkPy /qHDfouHzUMyu+954r9ab1eIViGJTs+iAibUT/Wd3nj0QZO4PBHnOmtLpUeIRfxy w0B5t1DJXdSaq/pM/6b+LX0=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Fri, 04 Apr 2014 12:43:17 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1620853330.3926.4536; Fri, 04 Apr 2014 12:43:16 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3132; t=1396633347; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=uRIB5/m 9QEG5WjsPqBZOR7pxdMFCCtr7zyZ5K1QlWPQ=; b=Qj2TtwVuKYGC9LsXII5gaGG V+e+W4Jjwr95idLmf60NB2SZlcOJ6qfs4gnXv3ERm5vyLJl6+L2nv0YnPf3fr4Se Vpu0KFs4PvbKckdhFc8retScuw+x0/BK48Tbg8Z15ezTGZbFQHG1gs9PtC7Z+c8l Kjdo8TpESAyXnQv7pOnA=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Fri, 04 Apr 2014 13:42:27 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1067103100.9.18440; Fri, 04 Apr 2014 13:42:26 -0400
Message-ID: <533EEF35.7070901@isdg.net>
Date: Fri, 04 Apr 2014 13:43:17 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, IETF-Discussion <ietf@ietf.org>
Subject: Re: Security for various IETF services
References: <533D8A90.60309@cs.tcd.ie>
In-Reply-To: <533D8A90.60309@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/wvJlyyyM0FUZH9_mOrPcOaOm6kE
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Apr 2014 17:44:11 -0000

I would add and be specific with the last sentence, for example, the 
IETF site
"new services" might need to be PCI/DSS compliant. This is especially 
the case if the IETF site is collecting credit card information for 
IETF meeting registrations or other purposes.  For logging in 
purposes, it may also need to be PCI/DSS compliant depending on the 
AUTH method. For DIGEST AUTH, it may require SSL and NONCE support. 
BASIC AUTH requires SSL, and it may not be sufficient for PCI/DSS 
unless there is other methods wrapping the BASIC AUTH process, i.e. a 
cookie method method. A form-based cookie login methods, where there 
is no standard protocol method, may require other conditions. 
Overall, there are areas at the IETF site that require updated, modern 
security-aware connection client access software to be used as 
required by industry standards such as PCI/DSS.  (I note, that this is 
probably USA, not sure how that applies in Europe, Asia, etc)

If fact, the IETF may not be running proper software that complies 
with PCI/DSS.

Maybe visiting one of the PCI/DSS resource/compliance sites can tell 
you what compliancy level the IETF site may fit.  Depending on what 
software is used, it may suffice or it may not, thus perhaps even 
adding new functional requirements to the IETF Web Site revamping project.

Hope this helps

--
HLS

On 4/3/2014 12:21 PM, Stephen Farrell wrote:
>
> Hi all,
>
>>From time to time the issue of how to secure IETF services
> comes up e.g. whether to turn on TLS for some IETF web server
> or jabber or mail etc.
>
> The most recent such was a request to turn on HSTS [1] for
> the IETF web site, which I don't think we can do without
> breaking old tools etc. Nonetheless we would like to turn
> on things like TLS more often going forward as seemed to
> me to be the outcome of a long thread on here late last
> year.
>
> So, the IESG are considering the following as an IESG
> statement to offer some guidance about this:
>
> "The IETF are committed to providing secure and privacy
> friendly access to information via the web, mail, jabber
> and other services. While most (but not all) data on IETF
> services is public, nonetheless access to that data
> should use best practices for security and privacy.
> However, as there are numerous legacy tools that have been
> built that require access via cleartext, the IETF will
> continue to allow such access so as not to break such
> tooling. New services will however generally only be made
> available in ways that use security protocols such as
> TLS."
>
> If you have wordsmithing changes to suggest please just send
> those to me or the iesg. More substantive comments should go
> here I guess. I hope the only bit worth discussing (except
> for the few folks who would rather we do none of this;-)
> might be the last sentence.
>
> A few weeks after any discussion here dies down I'll put the
> resulting text on an IESG telechat for approval if that seems
> like the right thing to do.
>
> Thanks,
> S
>
> [1] https://tools.ietf.org/html/rfc6797
>
>
>
>

-- 
HLS