Re: [secdir] secdir review on draft-mcdonald-ipps-uri-scheme

Michael Sweet <msweet@apple.com> Fri, 05 December 2014 18:54 UTC

Return-Path: <msweet@apple.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB9E1AD56E for <secdir@ietfa.amsl.com>; Fri, 5 Dec 2014 10:54:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 NPKuqEpbFL7J for <secdir@ietfa.amsl.com>; Fri, 5 Dec 2014 10:54:22 -0800 (PST)
Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027B51AD56D for <secdir@ietf.org>; Fri, 5 Dec 2014 10:54:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417805655; x=2281719255; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6z8M42FqTDYnHObh4VHeO02KVV/zqzq9zHXev3SmcN4=; b=f+Cgqv0SzVMamF0EDyFvY9zYAq94TmGdbIKUSkn9pfj5KRzNF69RPLc48mQNLfdc RY2U8wJFqi7xwQ6Z6VivSWq8zY3nyrOraJaMJm7+c0dNjfHoGsZDqYcyIIqyWdSj I9+hnbvY6jdbqofZbjDmN0Ej6PcmSckvl8MHvtV+XPyANS96GcPQK6wIrixwM/vt wMXBg0gzqPC6sJsrM5wbndLOTO26stjhnCXL1UGvWWLaddWNVDNRD2ERmLniLJu6 ZHpwtWVCESNiGzGKrqcYELMqX2EE3WIyi9yHuxIvIKocmD37AUpRn7ElIjvKB07U aqN8vEYuOyV5TY6W3JrSWw==;
Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 0E.64.26546.75FF1845; Fri, 5 Dec 2014 10:54:15 -0800 (PST)
X-AuditID: 11973e11-f79af6d0000067b2-bc-5481ff57cb37
Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 1B.D6.05439.D5FF1845; Fri, 5 Dec 2014 10:54:21 -0800 (PST)
Received: from [17.153.39.20] by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG400JS8HUAOK30@marigold.apple.com> for secdir@ietf.org; Fri, 05 Dec 2014 10:54:14 -0800 (PST)
MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-type: multipart/signed; boundary="Apple-Mail=_2523CC1A-AB21-4C97-9F65-C0F15F489BB5"; protocol="application/pkcs7-signature"; micalg=sha1
From: Michael Sweet <msweet@apple.com>
In-reply-to: <9C3E7BDB-82F5-4A75-82E6-F8E1075A84CD@tislabs.com>
Date: Fri, 05 Dec 2014 13:54:10 -0500
Message-id: <1679DF62-2474-4A79-BA34-3DA722CFA398@apple.com>
References: <9C3E7BDB-82F5-4A75-82E6-F8E1075A84CD@tislabs.com>
To: Sandra Murphy <sandy@tislabs.com>
X-Mailer: Apple Mail (2.1993)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUi2FAYrBv+vzHEYN4qZYsPCx+yODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/jCp8wF1/0r1r7/zdrA+Neji5GTQ0LAROJS22JWCFtM4sK9 9WxdjFwcQgJ7GSVWbDrD3MXIAVa0sj0cIj6JSeLj6SfMEM4PRokvjw8wgnQLC9hINPw5wwRi 8wroSTQ9ecwEUsQsMIVRYunL1+wgCTYBNYnfk/pYQaZyCthLbJlqCxJmEVCVaOp/B9bLLBAh 8XnXN6g5NhJ3+haAlQsJ2EnM2qQPEhYBKj9xag3U0bIS/y6eYQdZJSGwhk3iRtNV9gmMQrOQ nDEL2RmzwHZoSyxb+Jp5FtBcZgEdickLGSHCphJP3m5ng7CtJX7OeQQVV5SY0v2QfQEj+ypG odzEzBzdzDwjvcSCgpxUveT83E2MoHiYbie4g/H4KqtDjAIcjEo8vCskGkOEWBPLiitzDzFK c7AoifO+4wUKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGyzE554RLerK+Tdj9Mny3qUvQs7 BT55OuY+5rqbIbPxuEDA1O5Vb6+4XLz6+fCyJoZdPU3bl//1+ywQsSdNzkT+AvcHd8NvdkHb BQJXilhz3ytL/nf1xbs5JxundMwUMl56ZOIH+6gsM3cB32rTGS3Lc4wm7frD9G3hXqVTQbPe uOiXnvZ5cU2JpTgj0VCLuag4EQAngCxMaAIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUi2FDcohv7vzHEYNEbEYsPCx+yODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/jCp8wF1/0r1r7/zdrA+Neji5GDQ0LARGJle3gXIyeQKSZx 4d56ti5GLg4hgUlMEh9PP2GGcH4wSnx5fIARpEpYwEai4c8ZJhCbV0BPounJYyaQImaBKYwS S1++ZgdJsAmoSfye1McKsoFTwF5iy1RbkDCLgKpEU/87sF5mgQiJz7u+Qc2xkbjTtwCsXEjA TmLWJn2QsAhQ+YlTa1ghjpOV+HfxDPsERv5ZSDbPQrZ5FthYbYllC18zzwIaxSygIzF5ISNE 2FTiydvtbBC2tcTPOY+g4ooSU7ofsi9gZF/FKFCUmpNYaayXWFCQk6qXnJ+7iREcvoXBOxj/ LLM6xCjAwajEw7tCojFEiDWxrLgy9xCjCtCIRxtWX2CUYsnLz0tVEuFNng2U5k1JrKxKLcqP LyrNSS0+xCjNwaIkzlvxDiglkJ5YkpqdmlqQWgSTZeLglGpgXHD3qOHhe0cOl/Hxe/zft3Bl 8jQBG8HvN+xviHyyaN/gbrnoUYFVz/Nfk6fu/v3IzWPXWXsGQUtp5xsNkYv8Z8Yova7NKvtk GtERwazA4JH56XaxFev7Y3xndCMC2PYqPP5tZNy9Jr/hb9qCKt4OIcU2v8q88/9Yl23ceLrt 7wPdpCmOjQV7lViKMxINtZiLihMBO6GuTmcCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xBbE9pudek1a3cTFPV1-jJKNn7M
X-Mailman-Approved-At: Sat, 06 Dec 2014 08:35:17 -0800
Cc: draft-mcdonald-ipps-uri-scheme@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review on draft-mcdonald-ipps-uri-scheme
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Dec 2014 18:54:26 -0000

Sandra,

Thanks for your comments!  A few responses inline below...

> On Dec 4, 2014, at 12:16 PM, Sandra Murphy <sandy@tislabs.com> wrote:
> ...
> RFC2911 section 4.1.6 lists some "Standard values for this syntax
> type" for the uriScheme attibute - is it intended that this document
> add ipps: to that list?  That would seem logical but is not explictly
> stated.

Yes, per the whole IANA registration thing... :)

> section 4.2
> 
>   The abstract protocol defined in IPP/1.1 Model and Semantics
>   [RFC2911] places a limit of 1023 octets (NOT characters) on the
>   length of a URI.  
> ...   
>   Per PWG IPP Everywhere [PWG5100.14], for compatibility with existing
>   IPP implementations, IPP Printers SHOULD NOT generate (or allow
>   administrators to configure) URI lengths above 255 octets, because
>   many older IPP Client implementations do not properly support these
>   lengths.  
> 
> Is this a concern for ipps in particular, or would it apply to ipp as
> well?  (Is this one of the updates to RFC2911/RFC2910?)

It is, and is documented in RFC 3510 (which formally defines and registers the "ipp" URI scheme...)

> section 6.2.4
> 
>   Either service discovery or directory protocols SHOULD be used first 
>   or an IPP Client SHOULD first establish an 'ipp' connection (without 
>   TLS [RFC5246] or any client authentication) to the target IPP Printer
>   and use a Get-Printer-Attributes operation to discover the required
>   IPP Client authentication mechanism(s) associated with a given 'ipps'
>   URI.
> 
> I am not sure what the client would do with the information of the
> Client Authentication types before it attempted the ipps connection,
> but retrieving that information with no protection seems dangerous.
> At least, should the unprotected request be limited to mention the
> ipps URI as the target and request only the
> uri-authentication-supported attribute?  To at least limit the
> possibility that the response will include all attributes and the
> client will accept them before attempting the ipps connection?

Actually, I think this needs to be updated.  We should instead focus on using the Get-Printer-Attributes request to query the authentication requirements - this might cause a reconnect (in the case of a TLS client certificate being needed for authentication) but we don't want to say "downgrade to ipp" to do it.

> The following is a discussion of the potential for a tiered network of Printer Objects.
> 
> 
> This document talks about "a downstream IPP printer" and "print
> gateway" and defines an IPP Printer as something that can receive
> operations from an "upstream" client or printer.
> 
> I was curious as to whether the protocol is intended to be used in a
> hierarchy.

The model we use allows for "fan-out" of print jobs, but how that fan-out is implemented is not part of IPP (although it naturally can be implemented that way...)

There is some work in the PWG for defining how to securely do fan-out...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair