[Gen-art] Gen-ART LC review of draft-ietf-abfab-aaa-saml-12

"Roni Even" <ron.even.tlv@gmail.com> Thu, 03 December 2015 14:31 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 01AA81A88D5; Thu, 3 Dec 2015 06:31:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OVchPZaMpzPs; Thu, 3 Dec 2015 06:31:17 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F314D1A1A1F; Thu, 3 Dec 2015 06:31:16 -0800 (PST)
Received: by wmec201 with SMTP id c201so24647556wme.1; Thu, 03 Dec 2015 06:31:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=b5a5FVYRsp1BfJKCtp3DnIvhDETkUdpkZ2dBkvfVuCs=; b=u1yjgnv7/AJkEOOCRASNK67ydFFK/03IAPUXmTmmwWwhz7wzIqL1M9gVT2qqDR0U9U BmgBHPuSgzL5I7GD4fZB6osgeFrc8lsoekiiKE8pXMVFbJD6Juu3yii9U9Mq7hkSb6vy xNWo5BuUfwPbqxGyFPz9Bn/4oddygTN8XnrUB93/O5dVYChXokNns0DUcsEfph/vryB7 PrH5Ko0i6GaYGSgyecsnVY2Bo6mtuJzf9xy2J3PkSxVR95w0HBdM0s10qMAElcjz28+P isEAbBA/nK4/mOZ8pr7ecbECIBZO2RAGAHgdoQP6NVYRuba++zfeKDh4HoZYYgrjTT2+ DdYg==
X-Received: by with SMTP id tr6mr13072641wjc.21.1449153075552; Thu, 03 Dec 2015 06:31:15 -0800 (PST)
Received: from RoniPC (bzq-79-176-26-37.red.bezeqint.net. []) by smtp.gmail.com with ESMTPSA id jm4sm7807981wjb.7.2015. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 06:31:14 -0800 (PST)
From: Roni Even <ron.even.tlv@gmail.com>
To: draft-ietf-abfab-aaa-saml.all@tools.ietf.org
Date: Thu, 03 Dec 2015 16:31:10 +0200
Message-ID: <06b101d12dd7$423eb740$c6bc25c0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_06B2_01D12DE8.05C90DE0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdEt10Dx6hiFRh86SzaQcafCWmxhxQ==
Content-Language: he
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/u9OPuBWnqLDl0lg7e8ZE6wwtMTs>
Cc: gen-art@ietf.org, ietf@ietf.org
Subject: [Gen-art] Gen-ART LC review of draft-ietf-abfab-aaa-saml-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2015 14:31:20 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

Please resolve these comments along with any other Last Call comments you
may receive.

Document:  draft-ietf-abfab-aaa-saml-12

Reviewer: Roni Even

Review Date:2015-12-3

IETF LC End Date: 2015-12-4

IESG Telechat date: 


Summary: This draft is almost ready for publication as an Informational RFC.




Major issues:



Minor issues:

1.       Why is the RADIUSNasIpAddress a string and not as specified in for
example in RFC2865

2.       In general I was wondering why this is an Informational document.
It defines procedures and has normative language. 

3.       In the IANA consideration in section 11.1, as far as I understand
the IANA attribute type registry you need to ask for values for TBD1 and
TBD2 from the unassigned space (and not the reserved space)

4.       In step 2 of figure 7 (section 7.2) the text says "In step 2, the
Relying Party may optionally issue a <samlp:AuthnRequest> message to be
delivered to the   Identity Provider using the SAML-Protocol RADIUS
attribute."  My reading is that the rest of the steps are when this message
is sent, since it is  "may" what happens if the message is not sent?




Nits/editorial comments:

1.	In  section 1 please expand ABFAB
2.	In section 7.2, the text says "To implement this scenario, a profile
of the SAML Authentication   Request protocol is used in conjunction with
the SAML RADIUS binding  defined in Section 4." I think that the language
should be more normative maybe it should say  "To implement this scenario,
this profile of the SAML Authentication   Request protocol MUST Be (or
SHOULD if there are other options) used in conjunction with the SAML RADIUS
binding  defined in Section 4."