Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-radext-radsec-11

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 29 February 2012 19:35 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF7721F8799 for <gen-art@ietfa.amsl.com>; Wed, 29 Feb 2012 11:35:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.363
X-Spam-Level:
X-Spam-Status: No, score=-103.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuTU8ZeTDOc3 for <gen-art@ietfa.amsl.com>; Wed, 29 Feb 2012 11:35:03 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8634421F87A1 for <gen-art@ietf.org>; Wed, 29 Feb 2012 11:35:03 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAON8Tk/GmAcF/2dsb2JhbABEpk+NEIEHgXoBAQEBAgEBAQEJBh4+CwUHBAIBCA0EAwEBAQEKBgwLAQYBIAYfCQgBAQQTCA4Mh2IFC50wnCqJF4NjEwUBCwsEAkEUC4R/Bz0BDQEBBQQGBRWCSWMEiByTJIUZh1iBUwc
X-IronPort-AV: E=Sophos;i="4.73,504,1325480400"; d="scan'208";a="333370689"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 Feb 2012 14:35:02 -0500
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Feb 2012 14:27:54 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 29 Feb 2012 20:34:57 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A0407534104@307622ANEX5.global.avaya.com>
In-Reply-To: <CAFgnS4V+1G-vaD2F6FT5K17zJegru1ZNUWbHXS7P-LT5R7AR=w@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Gen-art] Gen-ART Telechat Review of draft-ietf-radext-radsec-11
Thread-Index: Acz3GD65eY95Yb36Q5KhLsQ6ffN2YwAAL8MQ
References: <CACvMsLGwVVF3x92O7j-eBjC4_PZ2EC_DuP-pgi1E-4-XkqT6SA@mail.gmail.com><4F279B35.9010409@restena.lu><F2F2B210-D61C-42A1-A947-B59414A36687@vigilsec.com> <CAFgnS4V+1G-vaD2F6FT5K17zJegru1ZNUWbHXS7P-LT5R7AR=w@mail.gmail.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Pete McCann" <mccap@petoni.org>
Cc: gen-art@ietf.org
Subject: Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-radext-radsec-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 29 Feb 2012 19:35:04 -0000

Hi,

Please use this address (dromasca@avaya.com) when you respond. 

Thanks and Reagrds,

Dan

> -----Original Message-----
> From: Dan Romascanu [mailto:dromasca@gmail.com]
> Sent: Wednesday, February 29, 2012 9:28 PM
> To: Romascanu, Dan (Dan)
> Subject: Fwd: [Gen-art] Gen-ART Telechat Review of draft-ietf-radext-
> radsec-11
> 
> ---------- Forwarded message ----------
> From: Russ Housley <housley@vigilsec.com>
> Date: Wed, Feb 29, 2012 at 9:04 PM
> Subject: Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-radext-
> radsec-11
> To: Pete McCann <mccap@petoni.org>
> Cc: IETF Gen-ART <gen-art@ietf.org>rg>, Dan Romascanu <dromasca@gmail.com>
> 
> 
> Pete:
> 
> I did not see a response to this message.  Do these changes resolve
> your concerns?
> 
> Russ
> 
> 
> On Jan 31, 2012, at 2:41 AM, Stefan Winter wrote:
> 
> > Hello,
> >
> > thanks for your review!
> >
> >> Minor issues:
> >>
> >> Section 2.4:
> >>   In TLS-X.509 with PKI infrastructure, a client is uniquely
> identified
> >>   by the serial number of the tuple (presented client
> >>   certificate;Issuer).
> >> SHOULD BE:
> >>   In TLS-X.509 with PKI infrastructure, a client is uniquely
> identified
> >>   by the tuple (serial number of presented client
> certificate;Issuer).
> >
> > Right, thanks for spotting; fixed now in my working copy.
> >
> >> Because RADIUS supports the Disconnect Request (server-to-client)
> message,
> >> it seems that there is some requirement to keep the TLS session open
> for the
> >> duration of the access that was authorized.  Otherwise, the server
> would not be
> >> able to send such a packet to the client without initiating its own
> >> TLS connection
> >> which may not be possible or desirable.  Is this aspect of the
> specification
> >> inherited from the referenced TCP specification?  It may be helpful
> to
> >> add a paragraph
> >> about this issue.
> >
> > Dynamic Authoirzation traffic is only very loosely coupled with the
> > corresponding authentication traffic. In particular, RFC5176 states
> that
> > a DynAuth Client (i.e. the one that would initiate the DM message)
> may
> > or may not be co-located with the RADIUS server which handled the
> > authentication.
> > There's a recommendation that a DynAuth client should not send its
> > traffic directly to the NAS and instead route it via the RADIUS
> server.
> > If that recommendation is followed, it may make sense to re-use the
> same
> > TLS session to send the packets indeed.
> > But it is certainly not a *requirement* that these types of traffic
> are
> > "bundled" together, or even just take the same path.
> >
> > It's true that there may be some operational hassle in setting up a
> TLS
> > session in the reverse direction if the original TLS session doesn't
> > exist any more. RADIUS/TLS shares this fate with all the other
> > transports though (in RADIUS/UDP, getting in the reverse direction
> > through a firewall, possibly combined with traversing NAT is "fun";
> same
> > goes for RADIUS/TCP). So, nothing "new" here IMHO.
> >
> >> Nits/editorial comments:
> >>
> >> Section 2.3:
> >>   x.y.z
> >> Did you mean to fill in a real section number here?
> >
> > Right, for TLS 1.2 that would be RFC6066, section 6.
> >
> > I have updated the text to state:
> >
> >          +  Implementations SHOULD indicate their trusted
> Certification
> >             Authorities.  For TLS 1.2, this is done using [RFC5246]
> >             section 7.4.4 "certificate authorities" (server side) and
> >             [RFC6066] Section 6 "Trusted CA Indication" (client
> side).
> >             See also Section 3.2.
> >
> > I'm wondering if I should also include exact pointers to the TLS 1.1
> > equivalents. After all TLS 1.1 is fading out anyway, so I could
> imagine
> > to leave that as the famous "exercise to the reader" if he wants to
> use
> > TLS 1.1 still. I wouldn't mind adding them explicitly though; just
> let
> > me know what you think is preferable.
> >
> >>   Note Section 3.4 (1) )
> >> Missing open paren?
> >
> > Right. Fixed to:
> >
> >   4.  start exchanging RADIUS datagrams (note Section 3.4 (1) ).  The
> >       shared secret to compute the (obsolete) MD5 integrity checks
> and
> >       attribute encryption MUST be "radsec" (see Section 3.4 (2) ).
> >
> > Greetings,
> >
> > Stefan Winter
> >
> > --
> > Stefan WINTER
> > Ingenieur de Recherche
> > Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale
> et
> > de la Recherche
> > 6, rue Richard Coudenhove-Kalergi
> > L-1359 Luxembourg
> >
> > Tel: +352 424409 1
> > Fax: +352 422473
> >
> > _______________________________________________
> > Gen-art mailing list
> > Gen-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/gen-art
> 
> 
> 
> --
> Dan
> http://dan.romascanu.net/