[abfab] Review of draft-ietf-abfab-aaa-saml-09

tshields <tshields@jive.com> Wed, 13 August 2014 03:16 UTC

Return-Path: <tshields@jive.com>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C452B1A00B0 for <abfab@ietfa.amsl.com>; Tue, 12 Aug 2014 20:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 3sul0oigfQLn for <abfab@ietfa.amsl.com>; Tue, 12 Aug 2014 20:16:00 -0700 (PDT)
Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9282B1A00C2 for <abfab@ietf.org>; Tue, 12 Aug 2014 20:16:00 -0700 (PDT)
Received: by mail-ob0-f180.google.com with SMTP id uy5so7840688obc.39 for <abfab@ietf.org>; Tue, 12 Aug 2014 20:15:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=chTAy2LXdjGLqNuoVeUHpXRqHLwpDcGnDeH/+kpxKLY=; b=DO85Fp5l9W9F5HOWTSIRwzjCDbmEG+VUOkwliPY6Zidd2577ozFu36VG2wFAc1kQqg Wu8MCfDF01cfD93V+ViBsXzo+a4Zz7GanFN9HyBLKcGjsC6n8Cn6kTQ5GiLnBbaK6HMR rpdAfB+PFKRxFB2xmIViSHuFUTIa0bcB3yiFx6WwSa6lmXoi+B8Hgww3uCpj9K1zstHA 7+UvRd09HaahRzRQIiGWej4s08GnM6jtH+hEQH50UvBzqTIp2oDbyHp+vLcXQZS1SWdC euOq10xfGc8fDZm02dmOWa7JZxVKWJ2ZU8eryJiRULw9WwawkxCdixDUyFYvIV/64v0Y yLGg==
X-Gm-Message-State: ALoCoQlNr42+uq91WdMwiFhpXxzZsFZZp2+jrzLq4QjEesBagNC1+v/U9y9JDGLngsWPHFuJUUeU
X-Received: by 10.60.98.206 with SMTP id ek14mr1651789oeb.51.1407899759831; Tue, 12 Aug 2014 20:15:59 -0700 (PDT)
Received: from [10.117.1.6] (173.192.81.133-static.reverse.softlayer.com. [173.192.81.133]) by mx.google.com with ESMTPSA id zv11sm784488obb.24.2014.08.12.20.15.59 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Aug 2014 20:15:59 -0700 (PDT)
Message-ID: <53EAD86D.105@jive.com>
Date: Tue, 12 Aug 2014 21:15:57 -0600
From: tshields <tshields@jive.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: abfab@ietf.org, Josh.Howlett@ja.net, hartmans-ietf@mit.edu
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/gLXgwsr6cMb6PyyquS7EgIxiZeM
Subject: [abfab] Review of draft-ietf-abfab-aaa-saml-09
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab/>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 03:16:02 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I don't have any major notes or concerns addressing the draft as a
whole as it was concise and easy to read through. Below are notes on
my questions and suggestions for improvement on some specific areas.


Section 2, Paragraph 5
> This document aspires to the guidelines stipulated by...

"Aspires" seems like a weird word choice, consider replacing with
"adheres".


Section 4, Paragraph 1

> The RADIUS SAML binding defined by this binding Section 5 uses two 
> attributes to convey SAML assertions and protocol messages 
> respectively [OASIS.saml-core-2.0-os] .

This sentence does not compute and can be reworded to be more
meaningful.


Section 4, Paragraph 1

> The Length of both of these attributes is >=5.

Greater than or equal to 5 what?


Section 5.2, Paragraph 2

> Support for fragmentation over UDP is not mandatory.

Is support for fragmentation over UDP RECOMMENDED or OPTIONAL? May be
beneficial to be more explicit here on what this draft's opinion is.
If the draft doesn't care at all, then consider removing this sentence
entirely.


Section 5.3.2, Paragraph 2 and Paragraph 4

> The following methods are sufficient:
> 
> o  NAS identity in trusted digitally signed request.
> 
> o  NAS identity in trusted SAML federation metadata.

> The following methods are sufficient:
> 
> o  RADIUS realm in trusted digitally signed request.
> 
> o  RADIUS realm in trusted SAML federation metadata.

The wording here makes it unclear whether one of these alone is
sufficient or whether both are required. Rewording to say something
like "Satisfying the following two conditions is sufficient:" is more
clear.


Section 5.3.3, Paragraph 1

> This bindings calls...

Correct to "This binding calls..."


Section 7, Paragraph 1

> The Relying Party, acting as a NAS, attempts to validate the 
> Principal's credentials against a RADIUS server acting the 
> Principal's Identity Provider.

Correct to "...Principal's credentials against a RADIUS server acting
as the Principal's Identity Provider."


Section 7.3.3, Paragraph 1

> If the ForceAuthn attribute on the <samlp:AuthnRequest> element
> (if sent by the requester) is present and true, the Identity
> Provider MUST freshly establish this identity rather than relying
> on any existing session state it may have with the Principal (for
> example, TLS state that may be used for session resumption).

Consider breaking this sentence up more and explaining why the
Identity Provider must freshly establish the identity.


Section 7.3.4, Paragraph 1

> The Identity Provider MUST conclude the authentication in a manner 
> consistent with the RADIUS authentication result, and MAY issue a 
> <samlp:Response> message to the Relying Party consisent with the 
> authentication result and as described in [OASIS.saml-core-2.0-os] 
> and delivered to the Relying Party using the SAML RADIUS binding.

Break this sentence up and fix the typo in "consistent".

Something like, "The Identity Provider MUST conclude the
authentication in a manner consistent with the RADIUS authentication
result. The Identity Provider MAY issue a <samlp:Response> message to
the Relying Party that is consistent with the authentication result,
as described in [OASIS.saml-core-2.0-os]."

(The last part of this sentence doesn't make sense to me, so reword
that as necessary).


Section 7.3.5, Paragraph 1

> Any subsequent use of the <saml:Assertion> elements is at the 
> discretion of the Relying Party, subject to any restrictions on
> use contained within the assertions themselves or previously 
> established out-of-band policy governing interactions between the 
> Identity Provider and the Relying Party.

Reword to something like: "Any subsequent use of the <saml:Assertion>
elements is at the discretion of the Relying Party, subject to any
restrictions contained within the assertions themselves or from any
previously established out-of-band policy that governs the interaction
between the Identity Provider and the Relying Party."


Section 7.4.2, Paragraph 2

> ... the <samlp:Response> element MUST conform to the following:
> 
> o  It MAY be signed.

Extremely minor, but I found it a little distracting/funny that the
first bullet in a list of MUSTs is a MAY. My recommendation is to
reword the introduction to this: "... the <samlp:Response> element is
subject to the following conditions."


Section 7.4.3, Bullet 3

> If a <saml:AuthnStatement> used to establish a security context for
> the Principal contains a SessionNotOnOrAfter attribute, the 
> security context SHOULD be discarded once this time is reached, 
> unless the service provider reestablishes the Principal's identity 
> by repeating the use of this profile.

Why is this a SHOULD and not a MUST? If it is a SHOULD merely to allow
for the situation described above (where the service provider
reestablishes the identity), then it actually should be a MUST. "The
security context MUST be discarded unless the service provider
reestablishes the Principal's identity" is a perfectly sound requirement.

- -- 
Troy Shields
Developer of Awesome | Jive Communications, Inc.
Jive.com | tshields@jive.com


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJT6thtAAoJEPpHBvvPaXlQlToQAJatdEwvYJUFeaHp2/Es5cj8
WdKgqhBkgyBkVSHw4yezgoWJsWsduln8943zglxPnohg6N/ID/Z/IavBIakcbbju
PdtdxNUWl/NmV8TUQ2FRgublzUKfOkPaD+++ajCplx+lZmnti4rimCZhBAhd52iT
gzgWdjFVowCqzFNoffCJvm2sx2FHvlOsOT41mq/7NRZT6f8I4T1+Rv91ZrI83ERo
Pt7471Y+UcoqliQqNEs5KFZEad0Z8TqxDFiJWGuiwNIXzISrLsZmulGo0l/x33Zc
LUso8rAdDq4THRcrQCshI7qvcTyQZVap1FskuasoKvBERdk/gZmxve11JZF27u0S
JiuQPOA3Jt7ymyYqUCBI7kteSr5u17n/4xuxhwfE+cNsUl0oQd+k8pH86ZUk2QUX
EAcJVgbUiYyCEWVATzXBcoIjUlF/xtQ4eexfjMc7Ilco1t0PvU7HdHEjzuMweKH2
huYkYZXaVebqCNVWxaatMI4TvMaJ6sbdThI0BpPvO2z3QektRCxmDC8TRv5zz4Y7
RWBzaqe3XiYAOUP75ibcinbLI5pntUpfIb45pOmtgkoCpvoFHmUiRjedEiFq3JVW
bx+u1y2FDs7byciIpGeBOGK9Qg+HCPuXy5VDYxNRgoFaYiFNNl5CF2j1TU/UkF58
Yt8Bnp9oG7dopBGZkG1e
=ony5
-----END PGP SIGNATURE-----