Re: [abfab] Review of draft-ietf-abfab-aaa-saml-11

Sam Hartman <hartmans@painless-security.com> Fri, 16 October 2015 12:55 UTC

Return-Path: <hartmans@painless-security.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 C23181ACEEC for <abfab@ietfa.amsl.com>; Fri, 16 Oct 2015 05:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level:
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 nX4DNUvjmzpN for <abfab@ietfa.amsl.com>; Fri, 16 Oct 2015 05:55:43 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC951ACEF0 for <abfab@ietf.org>; Fri, 16 Oct 2015 05:55:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 0DC4C207DF; Fri, 16 Oct 2015 08:54:09 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q9qv_70zAoE; Fri, 16 Oct 2015 08:54:08 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-50-136-30-120.hsd1.ma.comcast.net [50.136.30.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 16 Oct 2015 08:54:08 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8069888C9F; Fri, 16 Oct 2015 08:55:38 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: Alejandro Pérez Méndez <alex@um.es>
References: <9846A6064BD102419D06814DD0D78DE112712074@CIO-TNC-D2MBX02.osuad.osu.edu> <5620C974.30400@um.es>
Date: Fri, 16 Oct 2015 08:55:38 -0400
In-Reply-To: <5620C974.30400@um.es> ("Alejandro Pérez Méndez"'s message of "Fri, 16 Oct 2015 11:55:00 +0200")
Message-ID: <tslmvvjug51.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/abfab/_EbErheSmQnrJc9TQAAYmM5eQUA>
Cc: abfab@ietf.org
Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-11
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 16 Oct 2015 12:55:44 -0000

>>>>> "Alejandro" == Alejandro Pérez Méndez <alex@um.es> writes:

    Alejandro> Hi Scott, thanks for this thorough review. See my
    Alejandro> comments inline.

    >> Sorry this is a little late. I gave it a pretty thorough read.
    >> 
    >> Substantive:
    >> 
    >> Is it useful to say something in section 3 along the lines that
    >> apart from the binding defined in section 4, the spec doesn't
    >> prescribe any particular pattern/usage/constraint/etc. on the use
    >> of the two RADIUS attributes it defines? I ask because of the
    >> statement in section 4 about the two attributes not being used in
    >> the same RADIUS message, and wondered if that should be stated in
    >> section 3, but then thought maybe that wasn't something being
    >> constrained by the spec, but just the binding.

    Alejandro> I think that it would make sense to move the restriction
    Alejandro> up to section 3, as one can see both attributes as
    Alejandro> exclusive alternatives to represent SAML information. If
    Alejandro> the RADIUS server decides to send a SAML Message, why
    Alejandro> sending a SAML Assertion aside?

Agreed.

    Alejandro> I didn't write that text, so we have to hear the original
    Alejandro> authors' opinion here. I guess the point was that the
    Alejandro> SAML error response is optional, and that the RADIUS
    Alejandro> server, in presence of SAML errors, can just limit to
    Alejandro> provide a RADIUS-only response.

Yes, that's the intent as I understand it.

    Alejandro> Nevertheless, I think the last two paragraphs of section
    Alejandro> 4.2 could be reduced to the following text, it the
    Alejandro> original authors agree:

    Alejandro>    "In the case of a SAML processing error, the RADIUS
    Alejandro> server MAY include a SAML response message with an
    Alejandro> appropriate value for the <samlp:Status> element within
    Alejandro> the Access-Accept or Access-Reject packet to notify this
    Alejandro> fact to the Client.".

I think the following would be more clear:

    "In the case of a SAML processing error, the RADIUS
 server MAY include a SAML response message with an
 appropriate value for the <samlp:Status> element within
 the Access-Accept or Access-Reject packet to notify the client.
 Alternatively, the RADIUS server can respond without a SAML-Message attribute.".

Or did we end up calling it SAML-Protocol?

--Sam