Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 29 April 2015 19:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9F8631A00BE for <>; Wed, 29 Apr 2015 12:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rw8g4QDfEAGV for <>; Wed, 29 Apr 2015 12:43:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9880A1A00C2 for <>; Wed, 29 Apr 2015 12:43:05 -0700 (PDT)
X-AuditID: 1209190f-f79d16d000000d3d-aa-55413448d98a
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id A1.3D.03389.84431455; Wed, 29 Apr 2015 15:43:04 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t3TJh3qX022619; Wed, 29 Apr 2015 15:43:04 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t3TJh1S1023897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Apr 2015 15:43:02 -0400
Received: (from kaduk@localhost) by ( id t3TJh1K6021855; Wed, 29 Apr 2015 15:43:01 -0400 (EDT)
Date: Wed, 29 Apr 2015 15:43:01 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Stephen Farrell <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrOth4hhq8P6hnMXRzatYLKbvvcZu 8a3rOrMDs8fa7qtsHkuW/GTymDXrMFMAcxSXTUpqTmZZapG+XQJXRvf31ywF78Uq7r/byNTA uEWoi5GTQ0LAROL2pz9sELaYxIV768FsIYHFTBKvV4V0MXIB2RsZJf4vmMQCkTjEJLHyChNE ooFRYuKFBrAOFgFtidmHjjOD2GwCKhIz32wEi4sI6Evs3XyOHcRmFvCReHbxJdggYQEnietz rgEN4uDgFNCU2LZJCSTMK+AosXrTIqj5rYwS9zffZgRJiAroSKzeP4UFokhQ4uTMJywQM7Uk lk/fxjKBUXAWktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE30cjNL9FJTSjcxgoNX kn8H47eDSocYBTgYlXh4Nyg7hAqxJpYVV+YeYpTkYFIS5X2s4RgqxJeUn1KZkVicEV9UmpNa fIhRgoNZSYT3gB5QjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgnei MVCjYFFqempFWmZOCUKaiYMTZDgP0PDTIDW8xQWJucWZ6RD5U4yKUuK8cSAJAZBERmkeXC8s ubxiFAd6RZj3ghFQFQ8wMcF1vwIazAQ0+PwtB5DBJYkIKakGRgWD25YrS9c1FPLdCZ/cZbhR 5aT7YXmbG4/jIjKnsbIxqXyXP9f8JvxkTchcY6EVIjLndha23ZpXtaxQQUVXbiuXZ8M+b8/n 8+T7fsdK+7mb1zVG3+F7FR7GztZzaGPbqQn/rC2npW32O7dRyP3rXqZdvwyf7Hc4J9a3Z6ls V//6h5y/In46K7EUZyQaajEXFScCADi5smkJAwAA
Archived-At: <>
Cc: "" <>
Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Apr 2015 19:43:16 -0000

On Tue, 28 Apr 2015, Stephen Farrell wrote:

> On 28/04/15 16:48, Bill Mills wrote:
> > Again I disagree, this is *exactly* the same problem the HTTP host
> > header solves.
> The Host header field solves that problem for HTTP, but creates a
> problem for an authorization subsystem - if one piece of server
> side code checks an action the client wants to do vs. the Host
> header field and another makes that check vs. the new field that
> we're defining here then that opens a hole. And that error has
> been seen many times, so I don't believe you can just do a plug
> and play thing here safely, in general.
> > IMAP does not have anything that conveys hostname.
> > Port number might be known but hostname is not guaranteed. Added "The
> > server SHOULD validate that the host and port values match the
> > expected values for the service." to the end of the paragraph
> > discussing signature base strings where host and port are defined in
> > 3.
> I've no problem if you add the above but what I'm asking for is
> more like: "The server MUST validate that the host and port values
> defined here match any other application protocol data units or
> configured values that carry the same information. The details of
> how to do that match are application-specific and so cannot defined
> here, but implementers integrating these SASL mechanisms with
> applications need to ensure that such checks are made, where they
> are needed."

In any case, I think the text about validation should be in section 3.2,
not section 3.1 where "[t]he server SHOULD validate that the host and port
values match the expected values for the service" was added for the
version on github.  Section 3.2 is where server validation is discussed,
in the first sentence that Stephen thinks is incomplete.  I think we could
combine expanding that sentence with discussion of validating the supplied
hostname and port.

My strawman text:


The server fully validates the client response before generating a server
response; this will necessarily include the validation steps listed in the
specification for the OAuth Access Token Type used.  However, additional
validation steps may be needed, depending on the particular application
protocol making use of SASL.  In particular, values included as kvpairs in
the client response (such as host and port) which correspond to values
known to the application by some other mechanism (such as an application
protocol data unit or pre-configured values) MUST be validated to match
between the initial client response and the the other source(s) of such
information.  As a concrete example, when SASL is used over TLS, the
hostname can be available via the Server Name Indication TLS extension;
this hostname must be validated to match the value sent in the 'host'