______________________________________________________________________= ___________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you.

With -07=2C I believe that all t= he issues raised during WG last call have been resolved. =3B

Of course=2C it is possible that the issues have not been resolved= correctly=2C or that there are other issues that haven't been found yet.&n= bsp=3B

So please... take a look at -07 and post an= y issues in TRAC. =3B

>=3B From: internet-drafts@ietf.org=
>=3B To: i-d-announce@ietf.org
>=3B Date: Sun=2C 9 Jun 2013 09:1= 5:21 -0700
>=3B CC: radext@ietf.org
>=3B Subject: [radext] I-D Ac= tion: draft-ietf-radext-ieee802ext-07.txt
>=3B
>=3B
>=3B A= New Internet-Draft is available from the on-line Internet-Drafts directori= es.
>=3B This draft is a work item of the RADIUS EXTensions Working G= roup of the IETF.
>=3B
>=3B Title : RADIUS Attributes= for IEEE 802 Networks
>=3B Author(s) : Bernard Aboba
>=3B= Jouni Malinen
>=3B = Paul Congdon
>=3B Joseph Salowey
>=3B= Mark Jones
>=3B Filename : draft-ie= tf-radext-ieee802ext-07.txt
>=3B Pages : 30
>=3B Date= : 2013-06-09
>=3B
>=3B Abstract:
>=3B RFC 35= 80 provides guidelines for the use of the Remote Authentication
>=3B = Dialin User Service (RADIUS) within IEEE 802 local area networks
>= =3B (LANs). This document proposes additional attributes for use within=
>=3B IEEE 802 networks=2C as well as clarifications on the usage o= f the EAP-
>=3B Key-Name attribute=2C updating RFC 4072. The attri= butes defined in
>=3B this document are usable both within RADIUS a= nd Diameter.
>=3B
>=3B
>=3B The IETF datatracker status pa= ge for this draft is:
>=3B https://datatracker.ietf.org/doc/draft-ietf= -radext-ieee802ext
>=3B
>=3B There's also a htmlized version ava= ilable at:
>=3B http://tools.ietf.org/html/draft-ietf-radext-ieee802ex= t-07
>=3B
>=3B A diff from the previous version is available at:=
>=3B http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ieee802ext-= 07
>=3B
>=3B
>=3B Internet-Drafts are also available by an= onymous FTP at:
>=3B ftp://ftp.ietf.org/internet-drafts/
>=3B >=3B _______________________________________________
>=3B radext ma= iling list
>=3B radext@ietf.org
>=3B https://www.ietf.org/mailman= /listinfo/radext

= --_3b8e4732-a2af-455d-a5a6-13a08d9b363a_-- From jsalowey@cisco.com Sun Jun 9 17:05:22 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B41B21F8E89 for ; Sun, 9 Jun 2013 17:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 qGSHoVlygi78 for ; Sun, 9 Jun 2013 17:05:13 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DD5A321F8F9E for ; Sun, 9 Jun 2013 17:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4098; q=dns/txt; s=iport; t=1370822713; x=1372032313; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BPHsp1zd6CyEP5jlJmznMYgo3rQAot1iwRhihmeo5hU=; b=St41UVV0g83gzsOdg3uy7+ujEc8Gx0G32Cxqj1Jk86gUsDk8MZbzDmBw SFPDReTkTxXFsVtZgmWUvHJpnbocxc8e7YvyC2WEUR4G9Agam4LY5ZTR9 Bp1YaqaXbo5+1oUuwMS4dLRHu/n4MoggLf8dUFkIh5B1+pd1cApRIA20k A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4GAOsWtVGtJV2Y/2dsb2JhbABZgwkwSawOki96Fm0HgiMBAQEDAQEBAWsLBQsCAQgiHQcnCxQRAgQOBQiHcwMJBgy4VYxbgRsadQIxB4J/YQOIaIxygw+JAYF0A4Uhgw+BcTY X-IronPort-AV: E=Sophos;i="4.87,833,1363132800"; d="scan'208";a="220639641" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 10 Jun 2013 00:05:12 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5A05BcS018600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Jun 2013 00:05:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Sun, 9 Jun 2013 19:05:11 -0500 From: "Joseph Salowey (jsalowey)" To: "lionel.morand@orange.com" Thread-Topic: [radext] #153: Section 2.8 Access-Info Thread-Index: AQHOZW4stsZL+aukRUKLu5DzU1lvWA== Date: Mon, 10 Jun 2013 00:05:10 +0000 Message-ID: References: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> <27657_1370418838_51AEEE96_27657_5798_1_6B7134B31289DC4FAF731D844122B36E1FB0BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <27657_1370418838_51AEEE96_27657_5798_1_6B7134B31289DC4FAF731D844122B36E1FB0BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.222] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bernard_aboba@hotmail.com" , "radext@ietf.org" , "draft-ietf-radext-ieee802ext@tools.ietf.org" Subject: Re: [radext] #153: Section 2.8 Access-Info X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 00:05:22 -0000 Access Status is advertised to the supplicant in EAPOL-Announcement Message= s which are separate from authentication messages. I would it expect to = be communicated in any message from the AAA server as it is possible you ha= ve some level of access before authentication completes. Access-Info need= s to be included in an Access-Challenge message. =20 THanks, Joe On Jun 5, 2013, at 12:53 AM, lionel.morand@orange.com wrote: > I'm not sure to understand this point. >=20 > As per section 10.1 in 802.1X, the access status indication is consecutiv= e to an authentication procedure in any case.=20 > So my assumption is that this status is valid for the duration of the ses= sion. If any change is required, you need to restart a session. > Except if I have missed something... >=20 > Regards, >=20 > Lionel >=20 >=20 > -----Message d'origine----- > De : radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] De la part = de radext issue tracker > Envoy=E9 : dimanche 5 mai 2013 00:52 > =C0 : draft-ietf-radext-ieee802ext@tools.ietf.org; bernard_aboba@hotmail.= com > Cc : radext@ietf.org > Objet : [radext] #153: Section 2.8 Access-Info >=20 > #153: Section 2.8 Access-Info >=20 > The Access-Info Attribute is utilized by implementations of > IEEE-802.1X [IEEE-802.1X] to specify the Access status information > field within an Access Information Type Length Value Tuple (TLV) > to be sent to the user within MACsec Key Agreement (MKA) or EAPoL- > Announcement frames. >=20 > A single Access-Info Attribute is permitted within a RADIUS > Access-Accept, Access-Challenge, Access-Reject or Accounting- > Request packet. >=20 > [BA] The above paragraph seems to imply that the Access-Info Attribute > could cause the Access status information to change during and after > authentication. It is unclear how supplicants would respond to such a > change. For example, the potential response to a change in MKA (which is > authenticated) could be quite different from a change in an EAPoL- > Announcement frame (which is not). As a result, the desired behavior is > unclear. >=20 > --=20 > -------------------------------------+-----------------------------------= -- > Reporter: | Owner: draft-ietf-radext- > bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org > Type: defect | Status: new > Priority: critical | Milestone: milestone1 > Component: ieee802ext | Version: 1.0 > Severity: In WG Last Call | Keywords: > -------------------------------------+-----------------------------------= -- >=20 > Ticket URL: > radext >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 From trac+radext@trac.tools.ietf.org Sun Jun 9 17:06:31 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB91321F8E89 for ; Sun, 9 Jun 2013 17:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.649 X-Spam-Level: X-Spam-Status: No, score=-101.649 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, 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 cREcO2fnp4hM for ; Sun, 9 Jun 2013 17:06:31 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 10E3721F8E6E for ; Sun, 9 Jun 2013 17:06:30 -0700 (PDT) Received: from localhost ([127.0.0.1]:36341 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ulpcu-0007Pq-Ka; Mon, 10 Jun 2013 02:06:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, jsalowey@cisco.com X-Trac-Project: radext Date: Mon, 10 Jun 2013 00:06:24 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/153#comment:3 Message-ID: <081.48240e7ba4f5144a1927a83a845b418d@trac.tools.ietf.org> References: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> X-Trac-Ticket-ID: 153 In-Reply-To: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, jsalowey@cisco.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20130610000631.10E3721F8E6E@ietfa.amsl.com> Resent-Date: Sun, 9 Jun 2013 17:06:30 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #153: Section 2.8 Access-Info X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 00:06:31 -0000 #153: Section 2.8 Access-Info Changes (by jsalowey@cisco.com): * status: closed => reopened * resolution: fixed => -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org Type: defect | Status: reopened Priority: critical | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sun Jun 9 17:06:47 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8ECA21F8E89 for ; Sun, 9 Jun 2013 17:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.689 X-Spam-Level: X-Spam-Status: No, score=-101.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, 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 yShIBrIiwbpG for ; Sun, 9 Jun 2013 17:06:47 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEE021F8E6E for ; Sun, 9 Jun 2013 17:06:47 -0700 (PDT) Received: from localhost ([127.0.0.1]:36350 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UlpdC-0004Cr-Kg; Mon, 10 Jun 2013 02:06:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, jsalowey@cisco.com X-Trac-Project: radext Date: Mon, 10 Jun 2013 00:06:42 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/153#comment:4 Message-ID: <081.9785f92d6f61bb59dea7f9c080d9026e@trac.tools.ietf.org> References: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> X-Trac-Ticket-ID: 153 In-Reply-To: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, jsalowey@cisco.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20130610000647.2AEE021F8E6E@ietfa.amsl.com> Resent-Date: Sun, 9 Jun 2013 17:06:47 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #153: Section 2.8 Access-Info X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 00:06:47 -0000 #153: Section 2.8 Access-Info Comment (by jsalowey@cisco.com): Access Status is advertised to the supplicant in EAPOL-Announcement Messages which are separate from authentication messages. I would it expect to be communicated in any message from the AAA server as it is possible you have some level of access before authentication completes. Access-Info needs to be included in an Access-Challenge message. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org Type: defect | Status: reopened Priority: critical | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From hartmans@painless-security.com Mon Jun 10 07:00:33 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B9B21F871D for ; Mon, 10 Jun 2013 07:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 m1nyXJUuuj-G for ; Mon, 10 Jun 2013 07:00:27 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id EE58921F93B7 for ; Mon, 10 Jun 2013 07:00:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 202572016A; Mon, 10 Jun 2013 10:00:14 -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 ESVLsYHT4gzG; Mon, 10 Jun 2013 10:00:13 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Mon, 10 Jun 2013 10:00:13 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3A5A98053B; Mon, 10 Jun 2013 10:00:14 -0400 (EDT) From: Sam Hartman To: Bernard Aboba References: <51B3E6FB.5040606@deployingradius.com> Date: Mon, 10 Jun 2013 10:00:14 -0400 In-Reply-To: (Bernard Aboba's message of "Sat, 8 Jun 2013 19:54:43 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , Alan DeKok Subject: Re: [radext] Review of draft-ietf-radext-nai-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 14:00:33 -0000 For what it's worth, I continue to believe that Bernard may have a point and that we need to engage with the apps community to resolve the question of normalization. I'm not particularly worried about the HTTP/SIP/etc points Bernard raises. I think that there is some semantic ambiguity there, and I'm not against improvements in the text, but I don't see that as a blocking concern. I think that the ambiguity is unlikely to result in problems in practice that do not already exist. --Sam From bernard_aboba@hotmail.com Mon Jun 10 10:49:07 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1188221F88D8 for ; Mon, 10 Jun 2013 10:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wvbHL-R3MSa7 for ; Mon, 10 Jun 2013 10:49:00 -0700 (PDT) Received: from blu0-omc4-s22.blu0.hotmail.com (blu0-omc4-s22.blu0.hotmail.com [65.55.111.161]) by ietfa.amsl.com (Postfix) with ESMTP id 74E9321F8546 for ; Mon, 10 Jun 2013 10:48:56 -0700 (PDT) Received: from BLU169-W96 ([65.55.111.135]) by blu0-omc4-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jun 2013 10:48:56 -0700 X-TMN: [+JmyWd173F+CnD6Aqnljk8HA2K0Wm81sv4QJtIVuXSI=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_f8616681-d982-4f5a-886f-c55adce7c41a_" From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , "lionel.morand@orange.com" Date: Mon, 10 Jun 2013 10:48:55 -0700 Importance: Normal In-Reply-To: References: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org>, <27657_1370418838_51AEEE96_27657_5798_1_6B7134B31289DC4FAF731D844122B36E1FB0BA@PEXCVZYM13.corporate.adroot.infra.ftgroup>, MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jun 2013 17:48:56.0197 (UTC) FILETIME=[C76B0350:01CE6602] Cc: "radext@ietf.org" Subject: Re: [radext] #153: Section 2.8 Access-Info X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 17:49:07 -0000 --_f8616681-d982-4f5a-886f-c55adce7c41a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joe said:=20 =20 "Access Status is advertised to the supplicant in EAPOL-Announcement Messag= es which are separate from authentication messages. I would it expect to= be communicated in any message from the AAA server as it is possible you h= ave some level of access before authentication completes. Access-Info nee= ds to be included in an Access-Challenge message. " =20 [BA] As I understand it=2C the use of the Access-Info attribute is to allo= w for the setting (and reporting) of the Access Status=2C which might be pr= ovided in response to a request (or not)=3B protected by MKA (or not)=3B co= uld relate to a particular NID or for the port in general. This raises th= e question of what the usage scenarios are=2C and whether the document cove= rs them.=20 =20 For example:=20 =20 a. Is there a scenario where the Access-Info attribute could be used along = with Service-Type=3D"Call Check"? For example=2C if a request comes in=2C = could the RADIUS client generate a Call-Check message (e.g. with the MAC ad= dress of the supplicant in the Calling-Station-Id parameter) and then use t= he information in the Access-Info Attribute within the EAPoL-Announcement s= ent in reply?=20 =20 b. Is the Access-Info Attribute always used to communicate status for the = port in general=2C or can it sometimes be used to indicate the status for a= particular NID? If the latter=2C how is the NID to which Access-Info rela= tes communicated? Does the inclusion of an Network-Id-Name Attribute in th= e Access-Accept indicate that the Access-Info Attribute is NID-specific?=20 =20 IEEE 802.1X-2010 Section 11.12.2 states: =20 The Access Information TLV provides the information specified in clause 10.= 1 (see Table 11-9) for a particular NID or for the port in general (if the = TLV is encoded before any set TLV). =20 =20 =20 = --_f8616681-d982-4f5a-886f-c55adce7c41a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Joe said: =3B
=3B&nb= sp=3B
"Access Status is advertised to the supplicant in EAPOL-Announceme= nt Messages which are separate from authentication messages. I would it = expect to be communicated in any message from the AAA server as it is possi= ble you have some level of access before authentication completes. Access= -Info needs to be included in an Access-Challenge message. "
=3B[BA] =3B As I understand it=2C the use of the Access-Info attribute i= s to allow for the setting (and reporting) =3Bof the Access Status=2C w= hich might be provided in response to a request (or not)=3B protected by MK= A (or not)=3B could relate to a particular NID or for the port in general.&= nbsp=3B =3B This raises the question of what the usage scenarios are=2C= and whether the document covers them.
=3B
For example:
&nb= sp=3B
a. Is there a scenario where the Access-Info attribute could be us= ed along with Service-Type=3D"Call Check"? =3B For example=2C if a requ= est comes in=2C could the RADIUS client generate a Call-Check message (e.g.= with the MAC address of the supplicant in the Calling-Station-Id parameter= ) and then use the information in the Access-Info =3BAttribute within t= he EAPoL-Announcement sent in reply? =3B
=3B
b. =3B Is t= he Access-Info Attribute always used to communicate status for the port in = general=2C or can it sometimes be used to indicate the =3Bstatus for a = particular NID? =3B If the latter=2C how is the NID to which Access-Inf= o relates communicated? =3B Does the inclusion of an Network-Id-Name At= tribute in the Access-Accept =3Bindicate that the Access-Info Attribute= =3Bis NID-specific?
=3B
IEEE 802.1X-2010 Section 11.12.2 s= tates:
=3B

The Access Information TLV pro= vides the information specified in clause 10.1 (see Table 11-9) for a parti= cular NID or for the port in general (if the TLV is encoded before any set = TLV).

=3B

=3B
= =3B

=3B

= --_f8616681-d982-4f5a-886f-c55adce7c41a_-- From jsalowey@cisco.com Mon Jun 10 21:24:08 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BEB21F8FE5 for ; Mon, 10 Jun 2013 21:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 rGuqFV81PWGh for ; Mon, 10 Jun 2013 21:24:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 69A8621F8EFE for ; Mon, 10 Jun 2013 21:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7407; q=dns/txt; s=iport; t=1370924636; x=1372134236; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LXoqp/6wN8EkaBXjcpRWo/4f38OoSIlZt1q01N1OPH0=; b=buFOHk8CVa3faEHmkvex645tpx9SfLGtoWDuAwmuhWRfHG8PlKM32i7O Jg56tK87uYFLNYD/RychzHGawbZlxmanaH3ycXHq7qEtjeZlfb4gvy4ns NfnesPLUd+F4gx2TCEJ7NLlDuMetcFc8K+gqtyaGXcOr+CpRlHgaa9hL+ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAPyktlGtJV2d/2dsb2JhbABZgkVEeawYkjF7FnSCJAEBBHkQAgEIIh0HMhQRAgQOBQiHcwMPuiiMWoElgQcxB4J/YQOIaIxyjBCBdIUkgw+BaD8 X-IronPort-AV: E=Sophos;i="4.87,842,1363132800"; d="scan'208,217";a="221190189" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 11 Jun 2013 04:23:42 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5B4Ng9w002435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jun 2013 04:23:42 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 23:23:42 -0500 From: "Joseph Salowey (jsalowey)" To: Bernard Aboba Thread-Topic: [radext] #153: Section 2.8 Access-Info Thread-Index: AQHOZW4stsZL+aukRUKLu5DzU1lvWJkvjoKAgACxd4A= Date: Tue, 11 Jun 2013 04:23:42 +0000 Message-ID: References: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org>, <27657_1370418838_51AEEE96_27657_5798_1_6B7134B31289DC4FAF731D844122B36E1FB0BA@PEXCVZYM13.corporate.adroot.infra.ftgroup>,

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.222] Content-Type: multipart/alternative; boundary="_000_A95B4818FD85874D8F16607F1AC7C628CE081Exmbrcdx09ciscocom_" MIME-Version: 1.0 Cc: "radext@ietf.org" , "lionel.morand@orange.com" Subject: Re: [radext] #153: Section 2.8 Access-Info X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 04:24:08 -0000 --_000_A95B4818FD85874D8F16607F1AC7C628CE081Exmbrcdx09ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jun 10, 2013, at 10:48 AM, Bernard Aboba > wrote: Joe said: "Access Status is advertised to the supplicant in EAPOL-Announcement Messag= es which are separate from authentication messages. I would it expect to be= communicated in any message from the AAA server as it is possible you have= some level of access before authentication completes. Access-Info needs to= be included in an Access-Challenge message. " [BA] As I understand it, the use of the Access-Info attribute is to allow = for the setting (and reporting) of the Access Status, which might be provid= ed in response to a request (or not); protected by MKA (or not); could rela= te to a particular NID or for the port in general. This raises the questi= on of what the usage scenarios are, and whether the document covers them. For example: a. Is there a scenario where the Access-Info attribute could be used along = with Service-Type=3D"Call Check"? For example, if a request comes in, coul= d the RADIUS client generate a Call-Check message (e.g. with the MAC addres= s of the supplicant in the Calling-Station-Id parameter) and then use the i= nformation in the Access-Info Attribute within the EAPoL-Announcement sent = in reply? [Joe] Yes, some systems provide limited access for specific MAC addresses. b. Is the Access-Info Attribute always used to communicate status for the = port in general, or can it sometimes be used to indicate the status for a p= articular NID? If the latter, how is the NID to which Access-Info relates = communicated? Does the inclusion of an Network-Id-Name Attribute in the Ac= cess-Accept indicate that the Access-Info Attribute is NID-specific? [Joe] Good point. I agree the behavior should be that if the Access-info a= ttribute is included without a Network-ID-Name then it should pertain to th= e port in general. If the access info attribute is included along with a n= etwork-ID-Name attribute then it pertains to the identified NID. IEEE 802.1X-2010 Section 11.12.2 states: The Access Information TLV provides the information specified in clause 10.= 1 (see Table 11-9) for a particular NID or for the port in general (if the = TLV is encoded before any set TLV). --_000_A95B4818FD85874D8F16607F1AC7C628CE081Exmbrcdx09ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <87EBDD67D2BEB048AF455E75067BCFD1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

On Jun 10, 2013, at 10:48 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

Joe said:

"Access Status is advertised to the supplicant in EAPOL-Announcement M= essages which are separate from authentication messages. I would it expect = to be communicated in any message from the AAA server as it is possible you= have some level of access before authentication completes. Access-Info needs to be included in an Access-Challenge message= . "

[BA] As I understand it, the use of the Access-Info attribute is to a= llow for the setting (and reporting) of the Access Status, which might= be provided in response to a request (or not); protected by MKA (or not); = could relate to a particular NID or for the port in general. This raises the question of what the usage sc= enarios are, and whether the document covers them.

For example:

a. Is there a scenario where the Access-Info attribute could be used along = with Service-Type=3D"Call Check"? For example, if a request= comes in, could the RADIUS client generate a Call-Check message (e.g. with= the MAC address of the supplicant in the Calling-Station-Id parameter) and then use the information in the Access-Info Attribute = within the EAPoL-Announcement sent in reply?

[Joe] Yes, some systems provide limited access for specific MAC addres= ses.

b. Is the Access-Info Attribute always used to commu= nicate status for the port in general, or can it sometimes be used to indic= ate the status for a particular NID? If the latter, how is the N= ID to which Access-Info relates communicated? Does the inclusion of an Network-Id-Name Attribute in the Access-Accept in= dicate that the Access-Info Attribute is NID-specific?

[Joe] Good point. I agree the behavior should be that if the Acc= ess-info attribute is included without a Network-ID-Name then it should per= tain to the port in general. If the access info attribute is included= along with a network-ID-Name attribute then it pertains to the identified NID.

IEEE 802.1X-2010 Section 11.12.2 states:

The Access Information TLV provi= des the information specified in clause 10.1 (see Table 11-9) for a particu= lar NID or for the port in general (if the TLV is encoded before any set TL= V).

--_000_A95B4818FD85874D8F16607F1AC7C628CE081Exmbrcdx09ciscocom_-- From jouni.nospam@gmail.com Tue Jun 18 00:50:08 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733F721F9BF0 for ; Tue, 18 Jun 2013 00:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599] 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 we+QYJgqlEzQ for ; Tue, 18 Jun 2013 00:50:07 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1CB21F9BDB for ; Tue, 18 Jun 2013 00:49:59 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id fs12so3209405lab.26 for ; Tue, 18 Jun 2013 00:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=fTw7Z3n/nuu2KbC/XJu2pC1qwOQCJLvFKPvwHxQaW9A=; b=c07cOkY07JZuYeWngUn75gnIeuOf+DBecJUSTzcFnQkJlpmr1YgL6OimuwGrZMqpvE 0lFILV5IqjHAJWjD8cAdtNr5XSJB/rXBK+o3yi0pSHzqwWE5kN0OfZAM6O7zm80jDaeD +hmdqkz+IAwF3A+m3JCwbSC+/AxQqZ9AXuOzazSpJjoKucc+rJ/AO+fkNRbUl2ySXvEK tHUq5K24Q02So/IgkCJvZJ0mih2Nav1M5w7VWxROOash4/1jNuJxLPqnG/02dIbViONq chYXGebUMJws56CrgPyQlWaGeFILr86Ylu1UaYTYlQw8jbeiJTUR0llrG4/SKc74M7g7 soLA== X-Received: by 10.112.138.230 with SMTP id qt6mr513259lbb.34.1371541460535; Tue, 18 Jun 2013 00:44:20 -0700 (PDT) Received: from [192.168.250.166] ([194.100.71.98]) by mx.google.com with ESMTPSA id n7sm6679297lbd.12.2013.06.18.00.44.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 00:44:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: Jouni Korhonen In-Reply-To: <48059112-8694-43E2-994F-14382BED4AD9@gmail.com> Date: Tue, 18 Jun 2013 10:44:19 +0300 Content-Transfer-Encoding: 7bit Message-Id: <4198A764-0ADB-43B1-82B1-B9B208B05BCC@gmail.com> References: <48059112-8694-43E2-994F-14382BED4AD9@gmail.com> To: radext@ietf.org X-Mailer: Apple Mail (2.1508) Cc: radext-chairs@tools.ietf.org Subject: Re: [radext] Call for agenda items for IETF#87 Berlin meeting X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 07:50:08 -0000 Just a reminder. - Jouni & Mauricio On May 26, 2013, at 6:38 PM, Jouni wrote: > Folks, > > We have requested for one and half hour meeting slot. If you feel > like presenting your work (be that in the current charter or not), > send a request to the co-chairs. Obviously, chartered items will > be prioritized over other topics. > > - Jouni & Mauricio > From jouni.nospam@gmail.com Tue Jun 18 02:25:24 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2467421F9DBF for ; Tue, 18 Jun 2013 02:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599] 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 vUumweTEorq7 for ; Tue, 18 Jun 2013 02:25:23 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1567321F9DCD for ; Tue, 18 Jun 2013 02:25:07 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id eb20so3290131lab.29 for ; Tue, 18 Jun 2013 02:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=klvjdKYGSIUniWa4VUIoo347EZF0uf034vQK1uOZmvs=; b=gsmpF5fXvW83F6//lltsPmNhjPbMBLbPT2vLj6FIaQayH/V1lrmKYVfs/YamY3MrkH SxLntzHj7GwoNQuyxL3Qy5TDyjkzVAQLhrIMylE40cbKV0COuQDst1UYE8wgoZqvpBz8 1yJXWIWtrXkmpY5FpbA4cpf5siJ43l1UZT0n8uZxT8R+7P9UDjB49myZg1zmPA5KaxBg 4NED9SJkZMZTTtVbFuyXIJjni/eXxbyoZz7NEHXMEFOts0Pe/s7QebDQl6ImWFxwAlmC ljToTPxJ6d8Yx44qX7r5reHWBik89/9rV6vBzqnE9taoHHxI0n/FzLRYMORs2Teyl4c0 FABg== X-Received: by 10.112.181.71 with SMTP id du7mr685695lbc.24.1371547506390; Tue, 18 Jun 2013 02:25:06 -0700 (PDT) Received: from [192.168.250.166] ([194.100.71.98]) by mx.google.com with ESMTPSA id et10sm6843319lbc.6.2013.06.18.02.25.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 02:25:05 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) Content-Type: text/plain; charset=iso-8859-1 From: Jouni Korhonen X-Priority: 1 In-Reply-To: Date: Tue, 18 Jun 2013 12:25:04 +0300 Content-Transfer-Encoding: 7bit Message-Id: <7A3DC30B-CBEF-4B4B-B542-89CAB29682BC@gmail.com> References: <516EA97E.2000005@deployingradius.com>

<0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> <517FBD04.1050009@deployingradius.com> <51828E77.9020303@deployingradius.com> <061B9149-3354-4E53-8721-FCD86BF03EF0@gmail.com> To: "radext@ietf.org" X-Mailer: Apple Mail (2.1508) Cc: "Joseph Salowey $jsalowey$" , Alan DeKok Subject: [radext] A way forward with the DTLS document - a poll for WG consensus X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 09:25:26 -0000 Folks, We still have a sticking issue with the DTLS document on protocol multiplexing raised by Joe, see: http://www.ietf.org/mail-archive/web/radext/current/msg08459.html So, in order to progress things and get the (rough) WG consensus what to include in the document, We ask the WG to pick up their favourite approach from the two choices below. This poll ends on Tuesday 25th June EOB (EEST). 1) Forbid the protocol multiplexing i.e., require RADIUS over port 1812. 2) Allow protocol multiplexing i.e., Allow RADIUS or DTLS over port 1812. In both cases, DTLS would be allowed on the DTLS-only TBD port. The DTLS document will then be changed accordingly to reflect the WG consensus. - Jouni & Mauricio From bernard_aboba@hotmail.com Tue Jun 18 06:51:55 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0420921F9DE8 for ; Tue, 18 Jun 2013 06:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, 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 caWtbIBv7Wbn for ; Tue, 18 Jun 2013 06:51:39 -0700 (PDT) Received: from blu0-omc2-s20.blu0.hotmail.com (blu0-omc2-s20.blu0.hotmail.com [65.55.111.95]) by ietfa.amsl.com (Postfix) with ESMTP id B7E9B21F9D32 for ; Tue, 18 Jun 2013 06:51:39 -0700 (PDT) Received: from BLU404-EAS77 ([65.55.111.73]) by blu0-omc2-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jun 2013 06:51:39 -0700 X-TMN: [c1GWRAFkbuG5yD6r/iMwLzZmmS8Aomcy] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit References: <516EA97E.2000005@deployingradius.com>

<0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> <517FBD04.1050009@deployingradius.com> <51828E77.9020303@deployingradius.com> <061B9149-3354-4E53-8721-FCD86BF03EF0@gmail.com> <7A3DC30B-CBEF-4B4B-B542-89CAB29682BC@gmail.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <7A3DC30B-CBEF-4B4B-B542-89CAB29682BC@gmail.com> Date: Tue, 18 Jun 2013 06:51:36 -0700 To: Jouni Korhonen X-OriginalArrivalTime: 18 Jun 2013 13:51:39.0202 (UTC) FILETIME=[F4CFFA20:01CE6C2A] Cc: "radext@ietf.org" , "Joseph Salowey $jsalowey$" , Alan DeKok Subject: Re: [radext] A way forward with the DTLS document - a poll for WG consensus X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 13:51:55 -0000 Assuming that the RADSEC port is allocated, I would prefer choice #1. On Jun 18, 2013, at 2:25 AM, "Jouni Korhonen" wrote: > > Folks, > > We still have a sticking issue with the DTLS document on protocol > multiplexing raised by Joe, see: > http://www.ietf.org/mail-archive/web/radext/current/msg08459.html > > So, in order to progress things and get the (rough) WG consensus > what to include in the document, We ask the WG to pick up their > favourite approach from the two choices below. This poll ends on > Tuesday 25th June EOB (EEST). > > 1) Forbid the protocol multiplexing i.e., > require RADIUS over port 1812. > > 2) Allow protocol multiplexing i.e., > Allow RADIUS or DTLS over port 1812. > > In both cases, DTLS would be allowed on the DTLS-only TBD port. > The DTLS document will then be changed accordingly to reflect > the WG consensus. > > > - Jouni & Mauricio > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From hartmans@painless-security.com Tue Jun 18 07:21:53 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3DC21F9BAF for ; Tue, 18 Jun 2013 07:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 6oUCd7wlqnvK for ; Tue, 18 Jun 2013 07:21:46 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 42F6321F9F47 for ; Tue, 18 Jun 2013 07:21:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 409712013A; Tue, 18 Jun 2013 10:17:51 -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 T3JKoqM0NNHH; Tue, 18 Jun 2013 10:17:51 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Tue, 18 Jun 2013 10:17:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9D66D80046; Tue, 18 Jun 2013 10:21:32 -0400 (EDT) From: Sam Hartman To: Jouni Korhonen References: <48059112-8694-43E2-994F-14382BED4AD9@gmail.com> <4198A764-0ADB-43B1-82B1-B9B208B05BCC@gmail.com> Date: Tue, 18 Jun 2013 10:21:32 -0400 In-Reply-To: <4198A764-0ADB-43B1-82B1-B9B208B05BCC@gmail.com> (Jouni Korhonen's message of "Tue, 18 Jun 2013 10:44:19 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, radext-chairs@tools.ietf.org Subject: Re: [radext] Call for agenda items for IETF#87 Berlin meeting X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 14:21:54 -0000 I think it's fairly important that we spend enough time on the radius fragmentation issue that we can move forward and avoid continuing to block ABFAB documents. --Sam From diego@tid.es Tue Jun 18 09:06:13 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3327E21F9635 for ; Tue, 18 Jun 2013 09:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dXNK5F1-kxa7 for ; Tue, 18 Jun 2013 09:06:07 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 681B111E80E4 for ; Tue, 18 Jun 2013 09:05:57 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MOL00HGOJDPEK@tid.hi.inet> for radext@ietf.org; Tue, 18 Jun 2013 18:05:54 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 1B.F9.05654.26580C15; Tue, 18 Jun 2013 18:05:54 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MOL00HH3JDUEK@tid.hi.inet> for radext@ietf.org; Tue, 18 Jun 2013 18:05:54 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Tue, 18 Jun 2013 18:04:58 +0200 Date: Tue, 18 Jun 2013 16:04:57 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: Sam Hartman Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [radext] Call for agenda items for IETF#87 Berlin meeting Thread-index: AQHOWibyJy0Ua/OBOESmvMMD1NBlTJk7GXKAgABu+wCAAB0kAA== X-AuditID: 0a5f4e69-b7f4b6d000001616-ca-51c085629cf4 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42Lhivcz1E1qPRBocP2pmEXLq5lsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeHZ1E0vBJZ6Kp48dGxhX8HQxcnJICJhIfD/3nR3CFpO4cG89 G4gtJLCdUWLT+tIuRi4g+xejxP07m5ggnGmMEms2P2MCqWIRUJW4vOYoI4jNBmQ/av4NNklY wE1i2pXDLCA2p4CaxOrWThaIDQoSf849BrNFBAwk5r06xgYylFmgj1HiRd9zsGZeAW+JWY+f gg1lFjCT6Pr+iwUiLijxY/I9IJsDKK4uMWVKLkSJuERz600WCFtRYtqiBrBWRgFZiXfz57NC 7HKXWP9xKxuE7STxZ1IzM8Q9AhJL9pyHskUlXj7+xwrxZCejxOqbrewTGCVmITljFpIzZiGc MQvJGbOQnLGAkXUVo1hxUlFmekZJbmJmTrqBkV5Gpl5mXmrJJkZI1GXuYFy+U+UQowAHoxIP L4fI/kAh1sSy4srcQ4wSHMxKIrx/mg8ECvGmJFZWpRblxxeV5qQWH2Jk4uCUamBUiCiYtW0P 72HfqdvY7P/4zvLb8KTPL3EWZ8Sq+v3bThS53D3LvGX355bySQKPjr06wfOl+lfpz9IlcaZ+ c1caR1rnKbV7Pb6rdO5Z7c0Fp4P1LMwLpx2bprbXa/HL6z62uWfvLkqT+aD5RPrWprpP9zTK zpm/LA4QdZX87tL9wWnx9W/iguvvKLEUZyQaajEXFScCAOlzcT+YAgAA References: <48059112-8694-43E2-994F-14382BED4AD9@gmail.com> <4198A764-0ADB-43B1-82B1-B9B208B05BCC@gmail.com> Cc: Jouni Korhonen , "" , "" Subject: Re: [radext] Call for agenda items for IETF#87 Berlin meeting X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 16:06:13 -0000 SGkgU2FtLA0KDQpHb29kIHlvdSBtZW50aW9uIGl0LiBBbGFuLCB5b3VycyB0cnVseSBhbmQgdGhl IG90aGVyIGF1dGhvcnMgYXJlIHByZXBhcmluZyBhIHBsYW4gZm9yIG1ha2luZyBhIG5ldyBzdWJt aXNzaW9uIGluIHRoZSBsaW5lIG9mIHdoYXQgd2UgZGlzY3Vzc2VkIGluIE9ybGFuZG8uLi4NCg0K QmUgZ29vZGUsDQoNCk9uIDE4IEp1biAyMDEzLCBhdCAxNjoyMSAsIFNhbSBIYXJ0bWFuIHdyb3Rl Og0KDQo+IEkgdGhpbmsgaXQncyBmYWlybHkgaW1wb3J0YW50IHRoYXQgd2Ugc3BlbmQgZW5vdWdo IHRpbWUgb24gdGhlIHJhZGl1cw0KPiBmcmFnbWVudGF0aW9uIGlzc3VlIHRoYXQgd2UgY2FuIG1v dmUgZm9yd2FyZCBhbmQgYXZvaWQgY29udGludWluZyB0bw0KPiBibG9jayBBQkZBQiBkb2N1bWVu dHMuDQo+DQo+IC0tU2FtDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IHJhZGV4dCBtYWlsaW5nIGxpc3QNCj4gcmFkZXh0QGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQoNCg0KLS0NCiJFc3Rh IHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6 DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUt bWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQg NjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRp cmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51 ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOz bmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGlu dGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJl Y2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDov L3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg== From peterd@iea-software.com Tue Jun 18 10:33:57 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C037621E8091 for ; Tue, 18 Jun 2013 10:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 rbA9KyZGwKa4 for ; Tue, 18 Jun 2013 10:33:53 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5DC21E8095 for ; Tue, 18 Jun 2013 10:33:53 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 18 Jun 2013 10:33:52 -0700 Date: Tue, 18 Jun 2013 10:33:43 -0700 (Pacific Daylight Time) From: Peter Deacon To: Jouni Korhonen In-Reply-To: <7A3DC30B-CBEF-4B4B-B542-89CAB29682BC@gmail.com> Message-ID: References: <516EA97E.2000005@deployingradius.com>

<0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> <517FBD04.1050009@deployingradius.com> <51828E77.9020303@deployingradius.com> <061B9149-3354-4E53-8721-FCD86BF03EF0@gmail.com> <7A3DC30B-CBEF-4B4B-B542-89CAB29682BC@gmail.com> In-Reply-To: <7A3DC30B-CBEF-4B4B-B542-89CAB29682BC@gmail.com> Date: Tue, 18 Jun 2013 12:20:43 -0700 Message-ID: <031401ce6c58$edb4e420$c91eac60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQG0kL15MphKpbMXeMiOWfqLL2Y1fQKSNM9rAcdjkhUBtVRJ6wIWcZalAcaNEB4BqF1YLgD8biayAQxRvs8BmjQL+Zj11mmw Cc: "'Joseph Salowey $jsalowey$'" , 'Alan DeKok' Subject: Re: [radext] A way forward with the DTLS document - a poll for WG consensus X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 19:21:43 -0000 Forbid the multiplexing. - Just easier. > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf > Of Jouni Korhonen > Sent: Tuesday, June 18, 2013 2:25 AM > To: radext@ietf.org > Cc: Joseph Salowey (jsalowey); Alan DeKok > Subject: [radext] A way forward with the DTLS document - a poll for WG > consensus > Importance: High > > > Folks, > > We still have a sticking issue with the DTLS document on protocol > multiplexing raised by Joe, see: > http://www.ietf.org/mail-archive/web/radext/current/msg08459.html > > So, in order to progress things and get the (rough) WG consensus what to > include in the document, We ask the WG to pick up their favourite approach > from the two choices below. This poll ends on Tuesday 25th June EOB (EEST). > > 1) Forbid the protocol multiplexing i.e., > require RADIUS over port 1812. > > 2) Allow protocol multiplexing i.e., > Allow RADIUS or DTLS over port 1812. > > In both cases, DTLS would be allowed on the DTLS-only TBD port. > The DTLS document will then be changed accordingly to reflect the WG > consensus. > > > - Jouni & Mauricio > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From diego@tid.es Tue Jun 18 13:00:42 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0D121E8098 for ; Tue, 18 Jun 2013 13:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1hKc1sJlnnMr for ; Tue, 18 Jun 2013 13:00:38 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3367821E808E for ; Tue, 18 Jun 2013 13:00:37 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MOL00H4RU8ZU2@tid.hi.inet> for radext@ietf.org; Tue, 18 Jun 2013 22:00:35 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id B7.BC.05654.36CB0C15; Tue, 18 Jun 2013 22:00:35 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MOL00H4JU8YU2@tid.hi.inet> for radext@ietf.org; Tue, 18 Jun 2013 22:00:35 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Tue, 18 Jun 2013 22:00:34 +0200 Date: Tue, 18 Jun 2013 19:59:38 +0000 From: "Diego R. Lopez" In-reply-to: <031401ce6c58$edb4e420$c91eac60$@augustcellars.com> X-Originating-IP: [10.95.64.115] To: Jim Schaad Message-id: Content-id: <4F1672CDE14B344DB88F70C52A6425F5@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [radext] A way forward with the DTLS document - a poll for WG consensus Thread-index: AQG0kL15MphKpbMXeMiOWfqLL2Y1fQKSNM9rAcdjkhUBtVRJ6wIWcZalAcaNEB4BqF1YLgD8biayAQxRvs8BmjQL+Zj11mmw///pq4A= X-AuditID: 0a5f4e69-b7f4b6d000001616-ca-51c0bc63ae95 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42Lhivcz1E3ecyDQ4OoVLYuWVzPZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfjHfZaCS+IVh/vPMTcwtoh3MXJySAiYSPx4tYUFwhaTuHBv PRuILSSwnVFi1zn2LkYuIPsXo8TPo3fYIJxpjBKnd51hAqliEVCV2L/tASOIzQZkP2r+zQ5i CwuESez/eBoszingINHyazMbxAYFiT/nHoNtExFQl9i6+iYTyFBmgU2MEruPHwNr4BXwlrh1 vRusgVnATOLqmU/MEHFBiR+T7wE1cwDF1SWmTMmFKBGXaG69yQJhK0pMW9QANoZRQFbi3fz5 rBC7wiUa3u1iBWkVEaiQuL3YDeIcAYkle84zQ9iiEi8f/2OF+HE3i8TB9j6mCYwSs5BcMQvJ FbMQrpiF5IpZSK5YwMi6ilGsOKkoMz2jJDcxMyfdwEgvI1MvMy+1ZBMjJOoydzAu36lyiFGA g1GJh7dh5YFAIdbEsuLK3EOMEhzMSiK8f5qBQrwpiZVVqUX58UWlOanFhxiZODilGhhnLPs9 MVbL/PgS9aY4g4lnPe6lP25gCXwRPqcwYavL7sqPi/p0bGsz87fmOkjuL1/+alV6gHK71ewF U/y+17Btsftk/FW78YVzxgqp8yn7656FL5sb+fvhtcNSr86fuKKme9+bZYZH41mefweyzdh3 erF7B1jJhkd83nOteu+CxatmvDTrrtVSYinOSDTUYi4qTgQAxEuER5gCAAA= References: <516EA97E.2000005@deployingradius.com>

<0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> <517FBD04.1050009@deployingradius.com> <51828E77.9020303@deployingradius.com> <061B9149-3354-4E53-8721-FCD86BF03EF0@gmail.com> <7A3DC30B-CBEF-4B4B-B542-89CAB29682BC@gmail.com> <031401ce6c58$edb4e420$c91eac60$@augustcellars.com> Cc: "" , Jouni Korhonen , "Joseph Salowey $jsalowey$" , Alan DeKok Subject: Re: [radext] A way forward with the DTLS document - a poll for WG consensus X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:00:42 -0000 RWFzaWVyIGFuZCB3YXkgbW9yZSBuYXR1cmFsLCBJJ2Qgc2F5Li4uDQoNCk9uIDE4IEp1biAyMDEz LCBhdCAyMToyMCAsIEppbSBTY2hhYWQgd3JvdGU6DQoNCj4gRm9yYmlkIHRoZSBtdWx0aXBsZXhp bmcuIC0gSnVzdCBlYXNpZXIuDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g RnJvbTogcmFkZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyYWRleHQtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmDQo+PiBPZiBKb3VuaSBLb3Job25lbg0KPj4gU2VudDogVHVlc2RheSwg SnVuZSAxOCwgMjAxMyAyOjI1IEFNDQo+PiBUbzogcmFkZXh0QGlldGYub3JnDQo+PiBDYzogSm9z ZXBoIFNhbG93ZXkgKGpzYWxvd2V5KTsgQWxhbiBEZUtvaw0KPj4gU3ViamVjdDogW3JhZGV4dF0g QSB3YXkgZm9yd2FyZCB3aXRoIHRoZSBEVExTIGRvY3VtZW50IC0gYSBwb2xsIGZvciBXRw0KPj4g Y29uc2Vuc3VzDQo+PiBJbXBvcnRhbmNlOiBIaWdoDQo+Pg0KPj4NCj4+IEZvbGtzLA0KPj4NCj4+ IFdlIHN0aWxsIGhhdmUgYSBzdGlja2luZyBpc3N1ZSB3aXRoIHRoZSBEVExTIGRvY3VtZW50IG9u IHByb3RvY29sDQo+PiBtdWx0aXBsZXhpbmcgcmFpc2VkIGJ5IEpvZSwgc2VlOg0KPj4gaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3JhZGV4dC9jdXJyZW50L21zZzA4NDU5Lmh0 bWwNCj4+DQo+PiBTbywgaW4gb3JkZXIgdG8gcHJvZ3Jlc3MgdGhpbmdzIGFuZCBnZXQgdGhlIChy b3VnaCkgV0cgY29uc2Vuc3VzIHdoYXQgdG8NCj4+IGluY2x1ZGUgaW4gdGhlIGRvY3VtZW50LCBX ZSBhc2sgdGhlIFdHIHRvIHBpY2sgdXAgdGhlaXIgZmF2b3VyaXRlIGFwcHJvYWNoDQo+PiBmcm9t IHRoZSB0d28gY2hvaWNlcyBiZWxvdy4gVGhpcyBwb2xsIGVuZHMgb24gVHVlc2RheSAyNXRoIEp1 bmUgRU9CDQo+IChFRVNUKS4NCj4+DQo+PiAxKSBGb3JiaWQgdGhlIHByb3RvY29sIG11bHRpcGxl eGluZyBpLmUuLA0KPj4gICByZXF1aXJlIFJBRElVUyBvdmVyIHBvcnQgMTgxMi4NCj4+DQo+PiAy KSBBbGxvdyBwcm90b2NvbCBtdWx0aXBsZXhpbmcgaS5lLiwNCj4+ICAgQWxsb3cgUkFESVVTIG9y IERUTFMgb3ZlciBwb3J0IDE4MTIuDQo+Pg0KPj4gSW4gYm90aCBjYXNlcywgRFRMUyB3b3VsZCBi ZSBhbGxvd2VkIG9uIHRoZSBEVExTLW9ubHkgVEJEIHBvcnQuDQo+PiBUaGUgRFRMUyBkb2N1bWVu dCB3aWxsIHRoZW4gYmUgY2hhbmdlZCBhY2NvcmRpbmdseSB0byByZWZsZWN0IHRoZSBXRw0KPj4g Y29uc2Vuc3VzLg0KPj4NCj4+DQo+PiAtIEpvdW5pICYgTWF1cmljaW8NCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiByYWRleHQgbWFpbGluZyBs aXN0DQo+PiByYWRleHRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcmFkZXh0DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IHJhZGV4dCBtYWlsaW5nIGxpc3QNCj4gcmFkZXh0QGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0DQoNCg0KLS0NCiJF c3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExv cGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoN CmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiAr MzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNl IGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFy IG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0 csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlz IGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5k IHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0 cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg== From stig@venaas.com Tue Jun 18 13:05:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8294821F9AE8 for ; Tue, 18 Jun 2013 13:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 RrN6keMl5nDP for ; Tue, 18 Jun 2013 13:05:17 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 722DB21F9AE1 for ; Tue, 18 Jun 2013 13:05:17 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-235.cisco.com [128.107.239.235]) by ufisa.uninett.no (Postfix) with ESMTPSA id 09D697FDF; Tue, 18 Jun 2013 22:05:14 +0200 (CEST) Message-ID: <51C0BD74.3040302@venaas.com> Date: Tue, 18 Jun 2013 13:05:08 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jim Schaad References: <516EA97E.2000005@deployingradius.com>

<0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> <517FBD04.1050009@deployingradius.com> <51828E77.9020303@deployingradius.com> <061B9149-3354-4E53-8721-FCD86BF03EF0@gmail.com> <7A3DC30B-CBEF-4B4B-B542-89CAB29682BC@gmail.com> <031401ce6c58$edb4e420$c91eac60$@augustcellars.com> In-Reply-To: <031401ce6c58$edb4e420$c91eac60$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, 'Jouni Korhonen' , "'Joseph Salowey $jsalowey$'" , 'Alan DeKok' Subject: Re: [radext] A way forward with the DTLS document - a poll for WG consensus X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:05:18 -0000 On 6/18/2013 12:20 PM, Jim Schaad wrote: > Forbid the multiplexing. - Just easier. > >> -----Original Message----- >> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf >> Of Jouni Korhonen >> Sent: Tuesday, June 18, 2013 2:25 AM >> To: radext@ietf.org >> Cc: Joseph Salowey (jsalowey); Alan DeKok >> Subject: [radext] A way forward with the DTLS document - a poll for WG >> consensus >> Importance: High >> >> >> Folks, >> >> We still have a sticking issue with the DTLS document on protocol >> multiplexing raised by Joe, see: >> http://www.ietf.org/mail-archive/web/radext/current/msg08459.html >> >> So, in order to progress things and get the (rough) WG consensus what to >> include in the document, We ask the WG to pick up their favourite approach >> from the two choices below. This poll ends on Tuesday 25th June EOB > (EEST). >> >> 1) Forbid the protocol multiplexing i.e., >> require RADIUS over port 1812. Agree with 1, forbidding the multiplexing. Stig >> 2) Allow protocol multiplexing i.e., >> Allow RADIUS or DTLS over port 1812. >> >> In both cases, DTLS would be allowed on the DTLS-only TBD port. >> The DTLS document will then be changed accordingly to reflect the WG >> consensus. >> >> >> - Jouni & Mauricio >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From jouni.nospam@gmail.com Tue Jun 18 23:22:00 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566C221F995B for ; Tue, 18 Jun 2013 23:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599] 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 AbsvKEr7i7oI for ; Tue, 18 Jun 2013 23:21:59 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 83B8221F9EA9 for ; Tue, 18 Jun 2013 23:21:58 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id lx15so4206824lab.21 for ; Tue, 18 Jun 2013 23:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wuTsG6M9B0X7mJO6N5lvI/K/xj28lPeyon2VK7DAwM0=; b=n655OaZB4jCQ4HbjHPZblZ3abogcn5yS/nFQsmuAZdKoGqp4FhrRdglz5MHEFnUPOL kQFSz8LUy+kczLb7VERtFP6XFTxV9S2mQibuhbWWjbgM6Dri6gidolql/Q7TiPDmDZVy X1H3XZjvWTH6+ewZV2ie+SF9xyccQ8Cvk8ytvopPXvyG46v7UuD3TxTqHl7g1xe9bBq/ LLKOv9UNjW/0x61dMc+dWUYbutHUu/SPaoyL1yBDXF7sW79ElbFG/zQzuzQ54qx5oIJ6 nvsKcbGhbiJwH3kK6Dc8VS4+CqgqfpnKXAZhjaR9RzUZEpcxgpYRY2bYS7ywWfs9OKvJ HeNQ== X-Received: by 10.112.140.231 with SMTP id rj7mr2679795lbb.16.1371622917153; Tue, 18 Jun 2013 23:21:57 -0700 (PDT) Received: from [192.168.250.158] ([194.100.71.98]) by mx.google.com with ESMTPSA id uo8sm8291168lbb.5.2013.06.18.23.21.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 23:21:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: Jouni Korhonen In-Reply-To: <7104B68E-C97B-4847-B0BF-8590ED1810D7@gmail.com> Date: Wed, 19 Jun 2013 09:21:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7104B68E-C97B-4847-B0BF-8590ED1810D7@gmail.com> To: "radext@ietf.org" X-Mailer: Apple Mail (2.1508) Cc: "radext-chairs@tools.ietf.org" Subject: Re: [radext] WGLC #1 for draft-ietf-radext-nai-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 06:22:00 -0000 Folks, The WGLC#1 has ended. There are now five open tickets in the issue = tracker (#162, #145, #146, #164 and #167). I encourage the I-D author(s) and the = WG to sort out the remaining tickets as soon as possible. - Jouni & Mauricio On Jun 4, 2013, at 7:42 AM, Jouni Korhonen = wrote: > Folks, >=20 > This email starts a two week WGLC for draft-ietf-radext-nai-03. The = WGLC end > 18th June 2013 EOB (EEST). We require minimum three reasonable = reviews. Post > your comments and concerns to the mailing list and also enter your = issues you > want to be _addressed/resolved_ into the issue tracker. >=20 >=20 > - Jouni & Mauricio From jouni.nospam@gmail.com Tue Jun 18 23:32:25 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D67821F9EAD for ; Tue, 18 Jun 2013 23:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 otgntblYee4A for ; Tue, 18 Jun 2013 23:32:21 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 99A8A21F9E58 for ; Tue, 18 Jun 2013 23:32:20 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id 10so4312767lbf.8 for ; Tue, 18 Jun 2013 23:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=J+gnMKCsnfzdESUj/hcIrdBGqUTI50ywiw1wvMaQrNE=; b=tLa+tHawPnfcSmoVlSTjFdY50izFC9X57wPzz71CHGpdbL8H12Qdnc1l5VUDWnT8dl ilaAtvfJLx47JcfaueUG4LsFpob25vafSlNk1Mk0nGZd8BUDNNjgFzsPL3gov1je/1JE U+FLOYjCx8B0ULOxl4OS1s6PxbF03eIbmDT3po2XQtjZj9Rs8rfb+LUGQ+5K2QbOHihB 12vn7OA6scwLeSBKTKIebujO5dSoriAri85pZzd8q0aOIxYUA2ObSY/YibtufGKDmN/L 2p0JJ3dToYFEaqpCWQYko7m7HuzK8S+kvfBpeYL7Nj2/FWiJ/LbKbh3VnAdlasXC1QDf J7dA== X-Received: by 10.152.120.228 with SMTP id lf4mr617666lab.65.1371623539524; Tue, 18 Jun 2013 23:32:19 -0700 (PDT) Received: from [192.168.250.158] ([194.100.71.98]) by mx.google.com with ESMTPSA id a3sm8310170lbg.2.2013.06.18.23.32.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 23:32:18 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: Jouni Korhonen In-Reply-To: Date: Wed, 19 Jun 2013 09:32:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <11FAD0B4-6888-4A93-A5B2-0B9821A5E44F@gmail.com> References: <48059112-8694-43E2-994F-14382BED4AD9@gmail.com> <4198A764-0ADB-43B1-82B1-B9B208B05BCC@gmail.com>

To: Diego R. Lopez X-Mailer: Apple Mail (2.1508) Cc: Sam Hartman , "" , "" , Jouni Korhonen Subject: Re: [radext] Call for agenda items for IETF#87 Berlin meeting X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 06:32:25 -0000 Speaking of updates I hope we can see one quickly. The -05 revision left = the situation into a bit floating state and I hope the new revision = addresses the issues Bernard and Sam had. - Jouni On Jun 18, 2013, at 7:04 PM, Diego R. Lopez wrote: > Hi Sam, >=20 > Good you mention it. Alan, yours truly and the other authors are = preparing a plan for making a new submission in the line of what we = discussed in Orlando... >=20 > Be goode, >=20 > On 18 Jun 2013, at 16:21 , Sam Hartman wrote: >=20 >> I think it's fairly important that we spend enough time on the radius >> fragmentation issue that we can move forward and avoid continuing to >> block ABFAB documents. >>=20 >> --Sam >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >=20 >=20 > -- > "Esta vez no fallaremos, Doctor Infierno" >=20 > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ >=20 > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- >=20 >=20 > ________________________________ >=20 > Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo = electr=F3nico en el enlace situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send = and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx From jouni.nospam@gmail.com Tue Jun 18 23:39:32 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0F821F9F55 for ; Tue, 18 Jun 2013 23:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.309 X-Spam-Level: X-Spam-Status: No, score=-3.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Mf5GS5nMg678 for ; Tue, 18 Jun 2013 23:39:28 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id B356021F9F54 for ; Tue, 18 Jun 2013 23:39:27 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id z5so4313644lbh.7 for ; Tue, 18 Jun 2013 23:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=pljK557SiO9Y6cxlu74Ic7mtpQx0PVrqp2NjLIf3uO0=; b=UcfLNj6oieFF5dN4OgXn/EWgg9YZFvVee0Z6Fbza/qAP0iqox9cJ76cKE7RVN5G/8D CeObatevZujFrpnhKRgC8dwGBW+JxHmeztkAk1vPaX0crN0yLvbgrZKwUqKSd2Zmezs8 l4AiQDvvGOvNHN1mZfWkC2XzRgfOxtKcnyJ3gu8roySDtR8Mq6nrfspYGSrhYB5dT3Tp PbNTjRaYeDssb5sV3PkhMVrh0IqxIaq3O16wqnKfk2x+K+sh40sjRMc5+Y2zpNn7ywZz 3x4tV2gTtk3VPtAm4xFkVk7Uize+mhrU8Hs7Ipdq8+Ie367JoX7TxHXuO7WuZ98QXRZn uYfQ== X-Received: by 10.112.142.66 with SMTP id ru2mr2701120lbb.7.1371623966390; Tue, 18 Jun 2013 23:39:26 -0700 (PDT) Received: from [192.168.250.158] ([194.100.71.98]) by mx.google.com with ESMTPSA id 8sm8317671lbq.4.2013.06.18.23.39.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 23:39:25 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jun 2013 09:39:23 +0300 References: <51C0B82D.3070703@ericsson.com> To: "" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) X-Mailer: Apple Mail (2.1508) Subject: [radext] Fwd: [Softwires] Adoption of draft-jiang-softwire-map-radius-04 as wg draft X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 06:39:32 -0000 Folks, Just let you know that this I-D is in horizon.. and something for us to = check from the RADIUS protocol correctness point of view. - Jouni Begin forwarded message: > From: Suresh Krishnan > Subject: [Softwires] Adoption of draft-jiang-softwire-map-radius-04 as = wg draft > Date: June 18, 2013 10:42:37 PM GMT+03:00 > To: Softwires WG > Cc: Yong Cui >=20 > Hi all, > The adoption call on the mailing list has demonstrated consensus to > adopt this draft as a wg draft. Authors, please resubmit this draft as > draft-ietf-softwire-map-radius-00. >=20 > Regards > Suresh & Yong > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From aland@deployingradius.com Wed Jun 19 07:03:41 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231CD21F9C0F for ; Wed, 19 Jun 2013 07:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 PdrrEYhS9bgm for ; Wed, 19 Jun 2013 07:03:34 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2761521F9CC2 for ; Wed, 19 Jun 2013 07:03:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 6B06E224007C; Wed, 19 Jun 2013 16:02:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsAQZKeRgCHs; Wed, 19 Jun 2013 16:02:39 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176120556.dsl.bell.ca [70.26.44.236]) by power.freeradius.org (Postfix) with ESMTPSA id 3467D2240054; Wed, 19 Jun 2013 16:02:39 +0200 (CEST) Message-ID: <51C1BA01.7060106@deployingradius.com> Date: Wed, 19 Jun 2013 10:02:41 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jouni Korhonen References: <7104B68E-C97B-4847-B0BF-8590ED1810D7@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] WGLC #1 for draft-ietf-radext-nai-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:03:41 -0000 Jouni Korhonen wrote: > The WGLC#1 has ended. There are now five open tickets in the issue tracker > (#162, #145, #146, #164 and #167). I encourage the I-D author(s) and the WG > to sort out the remaining tickets as soon as possible. I should have an updated draft on Friday. Who does normalization is a big issue. I think it should be done at the edge, for a number of reasons. For one, it follows the general Internet philosophy of having smart edges and a dumb core. For another, it's really the only workable approach. Let's look at an example. Proxy P has been deployed, and is running quite happily for years. End user device E wants to get network access. The user just bought it, and it's fully of shiny new unicode goodness. Including code points which are unknown to proxy P. The end point account "belongs" to home server H. It may, or may not, have the same unicode information as the endpoint E. It may, or may not, have the same unicode information as proxy P. It has been suggested that the proxy P do normalization. Partly because end points don't do it now, and because there are fewer proxies than end points. However, according to the scenario above (which WILL happen), proxy P has insufficient information to normalize the realm used by E. So the *only* thing that P can do is to treat it as an opaque string. However, home server H has supplied P with a "canonical" version of the realm, as canonicalized by H. This realm is sadly not the same byte string as supplied by E. Therefore, E can't authenticate. H has to either supply P with *all* possible versions of it's realm, or has to give up, and not use i18n at all. All this comes about because E is pretty much guaranteed to be newer than P or H. It is therefore the *only* entity in the network who is capable of normalizing the realm. No one else has the correct information. See this page for a recent example of how normalization issues can cause security holes: http://labs.spotify.com/2013/06/18/creative-usernames/ My $0.02 is the following: - proxies should try to normalize realms, knowing that many endpoints won't do that. If the realm can't be normalized, treat it as an opaque byte string. - end points MUST normalize realms. Yes, they don't do this now. Too bad. We've been riding the ASCII wave for 50 years, and it's about to crash hard on the shoals of i18n. I'd like counter-examples showing that end points shouldn't do normalization. Alan DeKok. From bernard_aboba@hotmail.com Wed Jun 19 07:28:45 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C5421F9C1E for ; Wed, 19 Jun 2013 07:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 z7QA3IIspkpo for ; Wed, 19 Jun 2013 07:28:39 -0700 (PDT) Received: from blu0-omc2-s15.blu0.hotmail.com (blu0-omc2-s15.blu0.hotmail.com [65.55.111.90]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1E121F9C20 for ; Wed, 19 Jun 2013 07:28:39 -0700 (PDT) Received: from BLU169-W63 ([65.55.111.71]) by blu0-omc2-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jun 2013 07:28:39 -0700 X-TMN: [SOXSGLBQnmIvSahyKCjMd4+87V/gWVH8] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_2c02c371-6b8c-4106-a957-7de893c7a69a_" From: Bernard Aboba To: Alan DeKok , Jouni Korhonen Date: Wed, 19 Jun 2013 07:28:38 -0700 Importance: Normal In-Reply-To: <51C1BA01.7060106@deployingradius.com> References: <7104B68E-C97B-4847-B0BF-8590ED1810D7@gmail.com>, , <51C1BA01.7060106@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jun 2013 14:28:39.0184 (UTC) FILETIME=[4A701900:01CE6CF9] Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] WGLC #1 for draft-ietf-radext-nai-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: