From pau.minoves@i2cat.net Wed Sep 7 07:37:09 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5902B21F8B37 for ; Wed, 7 Sep 2011 07:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 2LSqmp2uZePY for ; Wed, 7 Sep 2011 07:37:08 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7E23821F8B2C for ; Wed, 7 Sep 2011 07:37:07 -0700 (PDT) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id p87EcutU003657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 Sep 2011 16:38:56 +0200 Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id p87Ecswp020981 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Wed, 7 Sep 2011 16:38:55 +0200 Received: by gyf3 with SMTP id 3so5583889gyf.31 for ; Wed, 07 Sep 2011 07:38:54 -0700 (PDT) Received: by 10.236.195.33 with SMTP id o21mr32674596yhn.35.1315406334653; Wed, 07 Sep 2011 07:38:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.69.232 with HTTP; Wed, 7 Sep 2011 07:30:50 -0700 (PDT) X-Originating-IP: [147.83.206.92] From: Pau Minoves Date: Wed, 7 Sep 2011 16:30:50 +0200 Message-ID: To: netconf@ietf.org Content-Type: multipart/alternative; boundary=20cf305638954ff50904ac5ae717 X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Wed, 07 Sep 2011 16:38:56 +0200 (CEST) Subject: [Netconf] netconf java implementation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 14:37:09 -0000 --20cf305638954ff50904ac5ae717 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, This mail is just to let you know about a netconf client implementation tha= t we maintain. We were developing it internally in a research project, so we decided to release it standalone as open source about a year ago. You can find it here: http://code.google.com/p/netconf4j/ It is java, low dependency and OSGI-ready. Of course we welcome any users, feedback or contributions. Also, we have seen that there are a couple of implementation lists here: http://www.ops.ietf.org/netconf/ http://trac.tools.ietf.org/wg/netconf/trac/wiki I'm just assuming that the maintainers are in this list, but, could it be possible to add our implementation there too? Thanks. Best regards, Pau --=20 Distributed Applications and Networks Area (DANA) Fundaci=F3 i2CAT, Internet i Innovaci=F3 Digital a Catalunya C/ Gran Capit=E0 2-4, Nexus I building, 1st floor, office 109 08034 Barcelona, Spain T: +34 935 679 927 --20cf305638954ff50904ac5ae717 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

This mail is just to let you know about a netconf client i= mplementation that we maintain. We were developing it internally in a resea= rch project, so we decided to release it standalone as open source about a = year ago.

You can find it here:

http://code.google.com/p/netconf4j/

It is java, low depend= ency and OSGI-ready. Of course we welcome any users, feedback or contributi= ons.

Also, we have seen that there are a couple of implementation lists here= :

http://www.ops.ietf.o= rg/netconf/
http://trac.tools.ietf.org/wg/netconf/trac/wiki

I'm just assuming that the maintainers are in this list, but, could= it be possible to add our implementation there too?

Thanks.

= Best regards,
Pau

--
Distributed Applications and Networks Ar= ea (DANA)
Fundaci=F3 i2CAT, Internet i Innovaci=F3 Digital a Catalunya
C/ Gran Cap= it=E0 2-4, Nexus I building, 1st floor, office 109
08034 Barcelona, Spai= n
T: +34 935 679 927
--20cf305638954ff50904ac5ae717-- From simon.leinen@switch.ch Sun Sep 11 12:26:06 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD2A21F8783 for ; Sun, 11 Sep 2011 12:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 yDAyFgTWPi4F for ; Sun, 11 Sep 2011 12:26:06 -0700 (PDT) Received: from diotima.switch.ch (diotima.switch.ch [IPv6:2001:620:0:4:203:baff:fe4c:d751]) by ietfa.amsl.com (Postfix) with ESMTP id 38A6B21F8782 for ; Sun, 11 Sep 2011 12:25:31 -0700 (PDT) Received: from diotima (localhost [IPv6:::1]) by diotima.switch.ch (8.14.3+Sun/8.14.3) with ESMTP id p8BJRTRI008210; Sun, 11 Sep 2011 21:27:29 +0200 (CEST) From: Simon Leinen To: Pau Minoves In-Reply-To: (Pau Minoves's message of "Wed, 7 Sep 2011 16:30:50 +0200") References: User-Agent: Gnus/5.110015 (No Gnus v0.15) Emacs/23.3 (usg-unix-v) X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Sun, 11 Sep 2011 21:27:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] netconf java implementation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2011 19:26:06 -0000 Pau Minoves writes: > Also, we have seen that there are a couple of implementation lists here: > http://www.ops.ietf.org/netconf/ > http://trac.tools.ietf.org/wg/netconf/trac/wiki > I'm just assuming that the maintainers are in this list, but, could it be > possible to add our implementation there too? Done for the first page, please review. The second is a Wiki, so you should be able to add suitable text yourself. -- Simon. From pau.minoves@i2cat.net Mon Sep 12 01:24:50 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C6C21F8A57 for ; Mon, 12 Sep 2011 01:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 pm+qiTDATdvH for ; Mon, 12 Sep 2011 01:24:50 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by ietfa.amsl.com (Postfix) with ESMTP id A176321F893C for ; Mon, 12 Sep 2011 01:24:49 -0700 (PDT) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id p8C8QoGr018275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 12 Sep 2011 10:26:51 +0200 Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id p8C8Qn4E026474 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 12 Sep 2011 10:26:50 +0200 Received: by vws10 with SMTP id 10so2562681vws.16 for ; Mon, 12 Sep 2011 01:26:49 -0700 (PDT) Received: by 10.52.178.137 with SMTP id cy9mr666897vdc.340.1315816009216; Mon, 12 Sep 2011 01:26:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.201.9 with HTTP; Mon, 12 Sep 2011 01:26:28 -0700 (PDT) X-Originating-IP: [147.83.206.92] In-Reply-To: References: From: Pau Minoves Date: Mon, 12 Sep 2011 10:26:28 +0200 Message-ID: To: Simon Leinen Content-Type: multipart/alternative; boundary=bcaec51a7c5cd1b0d304acba4983 X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Mon, 12 Sep 2011 10:26:51 +0200 (CEST) Cc: netconf@ietf.org Subject: Re: [Netconf] netconf java implementation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 08:24:50 -0000 --bcaec51a7c5cd1b0d304acba4983 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Great, Thanks. I added it too to the second page. On Sun, Sep 11, 2011 at 9:27 PM, Simon Leinen wrote= : > Pau Minoves writes: > > Also, we have seen that there are a couple of implementation lists here= : > > > http://www.ops.ietf.org/netconf/ > > http://trac.tools.ietf.org/wg/netconf/trac/wiki > > > I'm just assuming that the maintainers are in this list, but, could it = be > > possible to add our implementation there too? > > Done for the first page, please review. The second is a Wiki, so you > should be able to add suitable text yourself. > -- > Simon. > --=20 Distributed Applications and Networks Area (DANA) Fundaci=F3 i2CAT, Internet i Innovaci=F3 Digital a Catalunya C/ Gran Capit=E0 2-4, Nexus I building, 1st floor, office 109 08034 Barcelona, Spain T: +34 935 679 927 --bcaec51a7c5cd1b0d304acba4983 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Great, Thanks.

I added it too to the second page.

On Sun, Sep 11, 2011 at 9:27 PM, Simon Leinen <simon.leinen@switch.ch<= /a>> wrote:
Pau Minoves writes:
> Also, we have seen that there are a couple of implementation lists her= e:

> http://= www.ops.ietf.org/netconf/
> http://trac.tools.ietf.org/wg/netconf/trac/wiki

> I'm just assuming that the maintainers are in this list, but, coul= d it be
> possible to add our implementation there too?

Done for the first page, please review. =A0The second is a Wiki, so y= ou
should be able to add suitable text yourself.
--
Simon.



--
Distributed Appl= ications and Networks Area (DANA)
Fundaci=F3 i2CAT, Internet i Innovaci= =F3 Digital a Catalunya
C/ Gran Capit=E0 2-4, Nexus I building, 1st floo= r, office 109
08034 Barcelona, Spain
T: +34 935 679 927
--bcaec51a7c5cd1b0d304acba4983-- From bertietf@bwijnen.net Sun Sep 18 10:03:22 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205B321F8532 for ; Sun, 18 Sep 2011 10:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.132 X-Spam-Level: X-Spam-Status: No, score=-100.132 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=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 iv2P9VdY4mtw for ; Sun, 18 Sep 2011 10:03:21 -0700 (PDT) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2A50621F84D2 for ; Sun, 18 Sep 2011 10:03:19 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1R5KoE-0004bY-UM for netconf@ietf.org; Sun, 18 Sep 2011 19:05:39 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Sun, 18 Sep 2011 19:05:33 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Subject: [Netconf] Fw: Nomcom 2011-2012: Second Call for Nominations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 17:03:22 -0000 Please consider yourself as a nominee, or nominate somone else who you think would be a good leader in the IETF. It is us (the IETF community) who have to nominate and volunteer good eladership for ourselves. Bert Wijnen co-chair of NETCONF WG. ----- Original Message ----- From: "NomCom Chair" To: "IETF Announcement list" Cc: Sent: Sunday, September 18, 2011 4:05 AM Subject: Nomcom 2011-2012: Second Call for Nominations > Hi All, > > We are halfway through the nomination period (it ends on October > 2, 2011) and we need more nominees than we have received so > far. We appreciate the folks that have taken the time to nominate > people and those who have accepted so far. But the fact remains > that the number of nominations have been below average and the > acceptance rates of those nominated has also been low. > > We need **YOUR** input and participation! We cannot properly > execute the task of selecting the best candidates for these > positions with so few nominations and acceptances. So, please > consider making nominations for the open positions, in particular > those for which we have so few nominations � it takes just a few > minutes of your time. Right now, we just need the names/email > addresses. > > Why do we need more nominations? Well, even if you think a > willing incumbent is doing a very good job and should be > returned, his or her ability to serve again might be impacted by > unforeseen circumstances between now and March. NomCom needs to > consider multiple nominees to be prepared in the event one or > more candidates is unable to serve come next March and to ensure > we have chosen the best candidate. > > There are several ways you can help the Nomcom > > - You can nominate yourself. > - You can nominate someone you know whom you think would do a > good job. > > Don't worry about whether they might already be nominated. We > would much prefer to receive the same nomination several times > rather than miss a good person we should consider. > > How to submit Nominations: > -------------------------- > > The list of positions we need to fill, and the provided Job > Descriptions, and forms for nominations, can be found in the call > for nominations at: > > https://datatracker.ietf.org/ann/nomcom/3049/ > > You can enter a nomination by going to the following URL: > > https://www.ietf.org/group/nomcom/2011/nominate > > You can also nominate someone by sending an email to > nomcom11@ietf.org and giving us their name, email address and the > open position you are nominating them for. We will take care of > the rest. > > If you are asked for a user name and password, use an existing > ietf login and password. If you need a login and password, > request one from the following URL: > > https://datatracker.ietf.org/accounts/create/ > > > Open List: > ---------- > > As you already know, NomCom 2011-2012 will follow the policy > for "Open Disclosure of Willing Nominees" described in RFC 5680. > > Feedback Collection: > -------------------- > > The open list is currently available on the Nomcom page and the > entire community is invited to provide feedback on all nominees. > You can provide your comments on all willing nominees at the > following URL: > > https://www.ietf.org/group/nomcom/2011/input/ > > Suresh Krishnan > Chair, NomCom 2011-2012 > nomcom-chair@ietf.org > suresh.krishnan@ericsson.com > -------------------------------------------------------------------------------- > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From matjaz@mg-soft.si Thu Sep 22 05:55:47 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A35421F8CBF for ; Thu, 22 Sep 2011 05:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] 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 R9imCbG8tU5p for ; Thu, 22 Sep 2011 05:55:46 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id CB38A21F8CB5 for ; Thu, 22 Sep 2011 05:55:45 -0700 (PDT) Received: from [127.0.0.1] (mg-soft.si [10.0.0.15]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id p8MCw8Rl001696; Thu, 22 Sep 2011 14:58:08 +0200 Message-ID: <4E7B30D9.5080502@mg-soft.si> Date: Thu, 22 Sep 2011 14:58:01 +0200 From: Matjaz Vrecko Organization: MG-SOFT Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Simon Leinen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] netconf java implementation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Matjaz Vrecko List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 12:55:47 -0000 Hello Simon, Pau, We would appreciate if you could be so kind and extend the contents of the http://www.ops.ietf.org/netconf/ page, by adding also the following two entries to the "Implementations" section: MG-SOFT NETCONF Browser, a user friendly NETCONF GUI client/manager, based on MG-SOFT's own NETCONF V1 and V1.1 protocols. Application is implemented in Java. (http://www.mg-soft.com/mgNetConfBrowser.html) MG-SOFT Visual YANG Designer, a user friendly YANG file designer (creator, editor, modeler, builder), based on MG-SOFT's own YANG compiler. Application is implemented in Java. (http://www.mg-soft.com/mgYangDesigner.html) Please let me know if you need any additional information. Thank you very much and best regards, Matjaz On 11-Sep-2011 9:27 PM, Simon Leinen wrote: > Pau Minoves writes: >> Also, we have seen that there are a couple of implementation lists here: > >> http://www.ops.ietf.org/netconf/ >> http://trac.tools.ietf.org/wg/netconf/trac/wiki > >> I'm just assuming that the maintainers are in this list, but, could it be >> possible to add our implementation there too? > > Done for the first page, please review. The second is a Wiki, so you > should be able to add suitable text yourself. -- Matjaz Vrecko MG-SOFT Corporation, Strma ulica 8, SI-2000 Maribor, Slovenia Internet: http://www.mg-soft.si/ E-mail: Phone: +386 2 2506565, Fax: +386 2 2506566 From mehmet.ersue@nsn.com Fri Sep 23 09:14:22 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17BF21F8CAD for ; Fri, 23 Sep 2011 09:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.095 X-Spam-Level: X-Spam-Status: No, score=-106.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 cT5Sd9Uy5-HO for ; Fri, 23 Sep 2011 09:14:22 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id A984021F8CAC for ; Fri, 23 Sep 2011 09:14:21 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8NGGtxo027665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 18:16:55 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8NGGqRg002406; Fri, 23 Sep 2011 18:16:55 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Sep 2011 18:16:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Sep 2011 18:16:51 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402AE3496@DEMUEXC006.nsn-intra.net> In-Reply-To: <4E7B30D9.5080502@mg-soft.si> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] netconf java implementation Thread-Index: Acx5J1D4hzufAlaDQvC95dAWhHJXHQA40hiQ References: <4E7B30D9.5080502@mg-soft.si> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Matjaz Vrecko" , "Simon Leinen" , X-OriginalArrivalTime: 23 Sep 2011 16:16:52.0434 (UTC) FILETIME=[34682B20:01CC7A0C] Subject: Re: [Netconf] netconf java implementation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 16:14:23 -0000 Hi All, before everybody begins editing the (official) NETCONF Wiki page at ietf.org: Please read the introduction part of http://trac.tools.ietf.org/wg/netconf/trac/wiki. "Please send any suggestions or NETCONF related information you would like to see on this Wiki to NETCONF WG chairs (netconf-chairs@tools.ietf.org), e.g. links to NETCONF implementations, presentations or tutorials."=20 We would like to please you to stick to this rule. Regards, Mehmet & Bert Co-chairs of NETCONF WG > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of > ext Matjaz Vrecko > Sent: Thursday, September 22, 2011 2:58 PM > To: Simon Leinen > Cc: netconf@ietf.org > Subject: Re: [Netconf] netconf java implementation >=20 > Hello Simon, Pau, >=20 > We would appreciate if you could be so kind and extend the contents > of the http://www.ops.ietf.org/netconf/ page, by adding also the > following two entries to the "Implementations" section: >=20 >=20 > MG-SOFT NETCONF Browser, a user friendly NETCONF GUI client/manager, based > on MG-SOFT's own NETCONF V1 and V1.1 protocols. Application is implemented > in Java. > (http://www.mg-soft.com/mgNetConfBrowser.html) >=20 >=20 > MG-SOFT Visual YANG Designer, a user friendly YANG file designer (creator, > editor, modeler, builder), based on MG-SOFT's own YANG compiler. Application > is implemented in Java. > (http://www.mg-soft.com/mgYangDesigner.html) >=20 >=20 >=20 > Please let me know if you need any additional information. >=20 > Thank you very much and best regards, >=20 > Matjaz >=20 >=20 > On 11-Sep-2011 9:27 PM, Simon Leinen wrote: > > Pau Minoves writes: > >> Also, we have seen that there are a couple of implementation lists here: > > > >> http://www.ops.ietf.org/netconf/ > >> http://trac.tools.ietf.org/wg/netconf/trac/wiki > > > >> I'm just assuming that the maintainers are in this list, but, could it be > >> possible to add our implementation there too? > > > > Done for the first page, please review. The second is a Wiki, so you > > should be able to add suitable text yourself. >=20 > -- > Matjaz Vrecko > MG-SOFT Corporation, Strma ulica 8, SI-2000 Maribor, Slovenia > Internet: http://www.mg-soft.si/ E-mail: > Phone: +386 2 2506565, Fax: +386 2 2506566 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From luchuk@snmp.com Mon Sep 26 06:22:43 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E19A21F85D1 for ; Mon, 26 Sep 2011 06:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 EDVXjaKgfw+1 for ; Mon, 26 Sep 2011 06:22:43 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB7A21F85B1 for ; Mon, 26 Sep 2011 06:22:42 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id JAA09268; Mon, 26 Sep 2011 09:25:15 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id JAA23059; Mon, 26 Sep 2011 09:25:14 -0400 (EDT) Date: Mon, 26 Sep 2011 09:25:14 -0400 (EDT) From: Alan Luchuk Message-Id: <201109261325.JAA23059@adminfs.snmp.com> To: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 13:22:43 -0000 Hello, Is an update to RFC 5539 (NETCONF over TLS) available, and, if so, where might the update be found? I saw the flurry of discussion about this topic that took place on the NETCONF WG mailing list in late May 2011, but have not found any indication that the issues discussed were resolved, or that an update to RFC 5539 was produced. Thanks in advance. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From j.schoenwaelder@jacobs-university.de Mon Sep 26 06:43:01 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D53821F8C3E for ; Mon, 26 Sep 2011 06:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.124 X-Spam-Level: X-Spam-Status: No, score=-103.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 wY8eFQyzsw6p for ; Mon, 26 Sep 2011 06:43:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5773921F8C2F for ; Mon, 26 Sep 2011 06:43:00 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E77B20D7E; Mon, 26 Sep 2011 15:45:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id o2K_wOlylhwb; Mon, 26 Sep 2011 15:45:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2078E20D5E; Mon, 26 Sep 2011 15:45:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 674611AF7D13; Mon, 26 Sep 2011 15:45:28 +0200 (CEST) Date: Mon, 26 Sep 2011 15:45:27 +0200 From: Juergen Schoenwaelder To: Alan Luchuk Message-ID: <20110926134527.GC36350@elstar.local> Mail-Followup-To: Alan Luchuk , netconf@ietf.org References: <201109261325.JAA23059@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109261325.JAA23059@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 13:43:01 -0000 On Mon, Sep 26, 2011 at 09:25:14AM -0400, Alan Luchuk wrote: > Is an update to RFC 5539 (NETCONF over TLS) available, and, if so, where > might the update be found? I saw the flurry of discussion about this topic > that took place on the NETCONF WG mailing list in late May 2011, but have > not found any indication that the issues discussed were resolved, or that > an update to RFC 5539 was produced. I don't think there is such a document yet. I would, however, be interested - primarily from the background of constrained devices where having SSH is expensive if TLS is already available (to secure other protocols). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Mon Sep 26 06:53:41 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0E721F8C9E for ; Mon, 26 Sep 2011 06:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.116 X-Spam-Level: X-Spam-Status: No, score=-106.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 uQn33xGrTrbP for ; Mon, 26 Sep 2011 06:53:40 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id F326621F8C9D for ; Mon, 26 Sep 2011 06:53:39 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8QDuLcp029801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 15:56:21 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8QDuLdG031437; Mon, 26 Sep 2011 15:56:21 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 15:56:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Sep 2011 15:56:12 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> In-Reply-To: <20110926134527.GC36350@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Updating NETCONF over TLS document (RFC5539) Thread-Index: Acx8UpvWyube33xUTWWL3a4SiYNuGQAACHUA References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Alan Luchuk" X-OriginalArrivalTime: 26 Sep 2011 13:56:13.0472 (UTC) FILETIME=[0DA20200:01CC7C54] Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 13:53:41 -0000 Hi All, there was no substantial result from the discussion in May,=20 which would lead to an update of the standard document. I would like to encourage everybody to contribute if there=20 is any concrete idea to improve RFC 5539. Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of > ext Juergen Schoenwaelder > Sent: Monday, September 26, 2011 3:45 PM > To: Alan Luchuk > Cc: netconf@ietf.org > Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) >=20 > On Mon, Sep 26, 2011 at 09:25:14AM -0400, Alan Luchuk wrote: >=20 > > Is an update to RFC 5539 (NETCONF over TLS) available, and, if so, where > > might the update be found? I saw the flurry of discussion about this topic > > that took place on the NETCONF WG mailing list in late May 2011, but have > > not found any indication that the issues discussed were resolved, or that > > an update to RFC 5539 was produced. >=20 > I don't think there is such a document yet. I would, however, be > interested - primarily from the background of constrained devices > where having SSH is expensive if TLS is already available (to secure > other protocols). >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From kwatsen@juniper.net Mon Sep 26 11:35:27 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F58D1F0C4F for ; Mon, 26 Sep 2011 11:35:27 -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 Ur-+kdglYBAv for ; Mon, 26 Sep 2011 11:35:26 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 398CE1F0C4D for ; Mon, 26 Sep 2011 11:35:22 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKToDGi59pULOPE6k/zSub7CUcbPlrB6uq@postini.com; Mon, 26 Sep 2011 11:38:10 PDT Received: from P-EMHUB11-HQ.jnpr.net (172.24.192.58) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 26 Sep 2011 11:36:03 -0700 Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB11-HQ.jnpr.net ([::1]) with mapi; Mon, 26 Sep 2011 11:36:03 -0700 From: Kent Watsen To: "Ersue, Mehmet (NSN - DE/Munich)" , Juergen Schoenwaelder , Alan Luchuk Date: Mon, 26 Sep 2011 11:36:00 -0700 Thread-Topic: [Netconf] Updating NETCONF over TLS document (RFC5539) Thread-Index: Acx8UpvWyube33xUTWWL3a4SiYNuGQAACHUAAAfu+WA= Message-ID: <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 18:35:27 -0000 Ideally there would be a standard for how to extract an identity from a cli= ent certificate, but since there isn't (and since it's out of scope for us = to define one), it seems that we should either adopt 5953 language to produ= ce a NetConf username or move this RFC off the standards-track. K. -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Ersue, Mehmet (NSN - DE/Munich) Sent: Monday, September 26, 2011 9:56 AM To: Juergen Schoenwaelder; Alan Luchuk Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) Hi All, there was no substantial result from the discussion in May,=20 which would lead to an update of the standard document. I would like to encourage everybody to contribute if there=20 is any concrete idea to improve RFC 5539. Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of > ext Juergen Schoenwaelder > Sent: Monday, September 26, 2011 3:45 PM > To: Alan Luchuk > Cc: netconf@ietf.org > Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) >=20 > On Mon, Sep 26, 2011 at 09:25:14AM -0400, Alan Luchuk wrote: >=20 > > Is an update to RFC 5539 (NETCONF over TLS) available, and, if so, where > > might the update be found? I saw the flurry of discussion about this topic > > that took place on the NETCONF WG mailing list in late May 2011, but have > > not found any indication that the issues discussed were resolved, or that > > an update to RFC 5539 was produced. >=20 > I don't think there is such a document yet. I would, however, be > interested - primarily from the background of constrained devices > where having SSH is expensive if TLS is already available (to secure > other protocols). >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Mon Sep 26 11:49:23 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192B821F8E45 for ; Mon, 26 Sep 2011 11:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 NiwQdvpajpku for ; Mon, 26 Sep 2011 11:49:22 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8605C21F8E44 for ; Mon, 26 Sep 2011 11:49:22 -0700 (PDT) Received: from localhost (unknown [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id B11981200AD8; Mon, 26 Sep 2011 20:52:02 +0200 (CEST) Date: Mon, 26 Sep 2011 20:52:00 +0200 (CEST) Message-Id: <20110926.205200.286870508.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4E41689D.1020901@andybierman.com> References: <4E32E026.5000305@bwijnen.net> <4E3A4630.3010902@bwijnen.net> <4E41689D.1020901@andybierman.com> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Finished WG Last Call for draft-ietf-netconf-system-notifications-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 18:49:23 -0000 Hi, Andy Bierman wrote: > A new version (-05) has been posted: > http://www.ietf.org/id/draft-ietf-netconf-system-notifications-05.txt > > Please verify that the disputed text has been adjusted correctly. The new version is fine with regards to my comments. But it has one change that I do not think should be there: OLD: leaf killed-by { when "../termination-reason = 'killed' and ."; The "and ." is confusing. It should be: NEW: leaf killed-by { when "../termination-reason = 'killed'"; On a purely editorial note, so far all our published modules has followed the (stylistic) guideline to have the YANG statements in a consistent order (the canonical order). I suggest this module follows this style. /martin From biermana@Brocade.com Mon Sep 26 12:09:54 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E6821F8BA6 for ; Mon, 26 Sep 2011 12:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 VUxahPqZk74j for ; Mon, 26 Sep 2011 12:09:53 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 45C6321F8D0B for ; Mon, 26 Sep 2011 12:09:53 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p8QJ7LaB024962; Mon, 26 Sep 2011 12:12:34 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id 102wg802gd-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Sep 2011 12:12:34 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 26 Sep 2011 12:25:49 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::192e:5a11:9069:7a70]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Mon, 26 Sep 2011 12:12:33 -0700 From: Andy Bierman To: Martin Bjorklund Date: Mon, 26 Sep 2011 12:12:31 -0700 Thread-Topic: [Netconf] Finished WG Last Call for draft-ietf-netconf-system-notifications-04.txt Thread-Index: Acx8fWYUGU/shvs5RV2xCnhETPXFiAAAUi/g Message-ID: References: <4E32E026.5000305@bwijnen.net> <4E3A4630.3010902@bwijnen.net> <4E41689D.1020901@andybierman.com> <20110926.205200.286870508.mbj@tail-f.com> In-Reply-To: <20110926.205200.286870508.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-09-26_07:2011-09-26, 2011-09-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1109260218 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Finished WG Last Call for draft-ietf-netconf-system-notifications-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 19:09:54 -0000 If the 'when-stmt' is changed then the data type has to be changed to allow 0 instead of a session-id. I think there was consensus that a server should be able to send this notification even if the server knew the session was killed by some external source, but there is no NETCONF session tracking for that external session. IMO, since a client has to deal with session-id=3D0 in some cases already, then it is better to continue using zero consistently for new things. I will reorder the YANG statements in canonical order. The other issue has to be resolved by first deciding what to do if termination-reason=3D'killed' and no killed-by=20 session ID is available. 1) come up with a different termination-reason enum and don't use 'killed' OR 2) adjust the leaf definition to either 3) be allowed to exist with a value of 0 OR 4) not be instantiated unless the value is non-zero (what the current when-stmt says and what Phil wanted) Straw poll? Survey says? ... Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Martin Bjorklund Sent: Monday, September 26, 2011 11:52 AM To: ietf@andybierman.com Cc: netconf@ietf.org Subject: Re: [Netconf] Finished WG Last Call for draft-ietf-netconf-system-= notifications-04.txt Hi, Andy Bierman wrote: > A new version (-05) has been posted: > http://www.ietf.org/id/draft-ietf-netconf-system-notifications-05.txt >=20 > Please verify that the disputed text has been adjusted correctly. The new version is fine with regards to my comments. But it has one change that I do not think should be there: OLD: leaf killed-by { when "../termination-reason =3D 'killed' and ."; The "and ." is confusing. It should be: NEW: leaf killed-by { when "../termination-reason =3D 'killed'"; On a purely editorial note, so far all our published modules has followed the (stylistic) guideline to have the YANG statements in a consistent order (the canonical order). I suggest this module follows this style. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Mon Sep 26 13:01:37 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3CD11E80F5 for ; Mon, 26 Sep 2011 13:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 V0fhkKvWYGHZ for ; Mon, 26 Sep 2011 13:01:37 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 512B811E80F4 for ; Mon, 26 Sep 2011 13:01:37 -0700 (PDT) Received: from localhost (unknown [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id CA24012008E8; Mon, 26 Sep 2011 22:04:19 +0200 (CEST) Date: Mon, 26 Sep 2011 22:04:18 +0200 (CEST) Message-Id: <20110926.220418.411095502.mbj@tail-f.com> To: biermana@Brocade.com From: Martin Bjorklund In-Reply-To: References: <4E41689D.1020901@andybierman.com> <20110926.205200.286870508.mbj@tail-f.com> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Finished WG Last Call for draft-ietf-netconf-system-notifications-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 20:01:38 -0000 Andy Bierman wrote: > If the 'when-stmt' is changed then the data type has to be changed > to allow 0 instead of a session-id. No... why? The when expression says that the leaf "killed-by" is valid when termination-reason equals 'killed' and the leaf "killed-by" exists. The last part is confusing b/c it is redundant. The when statement now says that if the leaf doesn't exist, it can't exist, and if it exists, it can exist (!) > I think there was consensus > that a server should be able to send this notification even if the > server knew the session was killed by some external source, > but there is no NETCONF session tracking for that external session. Yes, and that's fine; it is not mandatory. If you do a new version, you may want to: s/Summarizes each edit being reported/ Summarizes the edits that have been detected/ s/an YANG data model/a YANG data model/ /martin From mbadra@gmail.com Mon Sep 26 23:12:04 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F8721F8C52 for ; Mon, 26 Sep 2011 23:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8I3wRkJ+WciE for ; Mon, 26 Sep 2011 23:12:03 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 54A3B21F8C49 for ; Mon, 26 Sep 2011 23:12:03 -0700 (PDT) Received: by vws5 with SMTP id 5so7716616vws.31 for ; Mon, 26 Sep 2011 23:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rs0MOvBVKWgAsTPMvHUvv1n1lMeZXcIOKroLdw3PqUA=; b=bIfIKIL0fKBTc06exWVpn9hF2btpaM3vaSZsNIZt53JJO33lwFeHuiENj8NXQ0Aj/y cg5AR8f9Dzr7b/HtAa6oZec57cE8WY0sF1+8l23gPdfwNF47QVHM0k/aee4n5uxLvAT9 iYR6gDJ+wAxfpCi0tAGLVrqObILkJlWpKzFzY= MIME-Version: 1.0 Received: by 10.52.22.130 with SMTP id d2mr7773352vdf.223.1317104087551; Mon, 26 Sep 2011 23:14:47 -0700 (PDT) Received: by 10.220.176.198 with HTTP; Mon, 26 Sep 2011 23:14:47 -0700 (PDT) In-Reply-To: <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> Date: Tue, 27 Sep 2011 10:14:47 +0400 Message-ID: From: Badra To: Kent Watsen Content-Type: multipart/alternative; boundary=20cf307d073845507804ade6314a Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 06:12:04 -0000 --20cf307d073845507804ade6314a Content-Type: text/plain; charset=ISO-8859-1 Hi, Juergen already proposed two options during last May: "RFC 4741bis needs to provide this functionality by allowing transports to supply (ordered?) sets of usernames or the TLS transport has to figure out how to select the one and only username" I thing RFC6141 didn't say anything about that issue (Juergen, please correct me if I am wrong), and the only way is to figure out how to select one and only one username. If the certificate contains a single subjectAltName, that is fine, we extract it. Else, if you have more than one, you shall specify which one you would extract, the first? the last? Moreover, if you have non-empty subject distinguished name field, would be enough to extract its value and set it as the user identity? Would you please elaborate more to see how we can adopt 5953 language to resolve the above problem? P.S. Most of the current standards that run applications over TLS (such as HTTP over TLS or EAP-TLS) defines a common way to extract the an identity from a client certificate. Best regards, Badra On Mon, Sep 26, 2011 at 10:36 PM, Kent Watsen wrote: > > Ideally there would be a standard for how to extract an identity from a > client certificate, but since there isn't (and since it's out of scope for > us to define one), it seems that we should either adopt 5953 language to > produce a NetConf username or move this RFC off the standards-track. > > K. > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf > Of Ersue, Mehmet (NSN - DE/Munich) > Sent: Monday, September 26, 2011 9:56 AM > To: Juergen Schoenwaelder; Alan Luchuk > Cc: netconf@ietf.org > Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) > > Hi All, > > there was no substantial result from the discussion in May, > which would lead to an update of the standard document. > I would like to encourage everybody to contribute if there > is any concrete idea to improve RFC 5539. > > Cheers, > Mehmet > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of > > ext Juergen Schoenwaelder > > Sent: Monday, September 26, 2011 3:45 PM > > To: Alan Luchuk > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) > > > > On Mon, Sep 26, 2011 at 09:25:14AM -0400, Alan Luchuk wrote: > > > > > Is an update to RFC 5539 (NETCONF over TLS) available, and, if so, > where > > > might the update be found? I saw the flurry of discussion about > this topic > > > that took place on the NETCONF WG mailing list in late May 2011, but > have > > > not found any indication that the issues discussed were resolved, or > that > > > an update to RFC 5539 was produced. > > > > I don't think there is such a document yet. I would, however, be > > interested - primarily from the background of constrained devices > > where having SSH is expensive if TLS is already available (to secure > > other protocols). > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --20cf307d073845507804ade6314a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Juergen already proposed two option= s during last May: "RFC 4741bis needs to provide this functionality by= allowing transports to supply (ordered?) sets of usernames or the TLS tran= sport has to figure out how to select the one and only username"

=A0

= I thing RFC6141 didn't say anything about that issue (Juergen, please c= orrect me if I am wrong), and the only way is to figure out how to select o= ne and only one username. If the certificate contains a single subjectAltNa= me, that is fine, we extract it. Else,=A0=A0if you have more = than one,=A0you shall specify which one you would extract, the first? the l= ast? Moreover, if you have non-empty subject distinguished name field, woul= d be enough to extract its value and set it as the user identity?

=A0

Would you please elaborate more to see how we can adopt 5953 l= anguage to resolve the above problem?=A0

P.S.=A0Mo= st of the current standards that run applications over TLS (such as HTTP ov= er TLS or EAP-TLS) defines a common way to extract the an identity from a c= lient certificate.=A0

Best regards,
Badra

On Mon, Sep 26, 2011 at 10:36 PM, Kent Watse= n <kwatsen@juniper.net> wrote:

Ideally there would be a standard for how to extract an identity from a cli= ent certificate, but since there isn't (and since it's out of scope= for us to define one), it seems that we should either adopt 5953 language = to produce a NetConf username or move this RFC off the standards-track.

K.


-----Original Message-----
From: netconf= -bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (= NSN - DE/Munich)
Sent: Monday, September 26, 2011 9:56 AM
To: Juergen Schoenwaelder; Alan Luchuk
Cc: netconf@ietf.org<= /a>
Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539)

Hi All,

there was no substantial result from the discussion in May,
which would lead to an update of the standard document.
I would like to encourage everybody to contribute if there
is any concrete idea to improve RFC 5539.

Cheers,
Mehmet

> -----Original Message-----
> From: ne= tconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On
Behalf Of
> ext Juergen Schoenwaelder
> Sent: Monday, September 26, 2011 3:45 PM
> To: Alan Luchuk
> Cc: netconf@ietf= .org
> Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) >
> On Mon, Sep 26, 2011 at 09:25:14AM -0400, Alan Luchuk wrote:
>
> > Is an update to RFC 5539 (NETCONF over TLS) available, and, if so= ,
where
> > might the update be found? =A0I saw the flurry of discussion abou= t
this topic
> > that took place on the NETCONF WG mailing list in late May 2011, = but
have
> > not found any indication that the issues discussed were resolved,= or
that
> > an update to RFC 5539 was produced.
>
> I don't think there is such a document yet. I would, however, be > interested - primarily from the background of constrained devices
> where having SSH is expensive if TLS is already available (to secure > other protocols).
>
> /js
>
> --
> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGm= bH
> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 287= 59 Bremen, Germany
> Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-univer= sity.de/>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org=
> https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

--20cf307d073845507804ade6314a-- From j.schoenwaelder@jacobs-university.de Tue Sep 27 02:31:03 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E0721F8DE7 for ; Tue, 27 Sep 2011 02:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.125 X-Spam-Level: X-Spam-Status: No, score=-103.125 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 4ewOLAKJXCL1 for ; Tue, 27 Sep 2011 02:31:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0752E21F8DD8 for ; Tue, 27 Sep 2011 02:31:02 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14B4920CDD; Tue, 27 Sep 2011 11:33:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id F5Bl8pNm_Gw1; Tue, 27 Sep 2011 11:33:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4238120CD8; Tue, 27 Sep 2011 11:33:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BBF9A1AF898F; Tue, 27 Sep 2011 11:33:29 +0200 (CEST) Date: Tue, 27 Sep 2011 11:33:29 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20110927093329.GB252@elstar.local> Mail-Followup-To: Kent Watsen , "Ersue, Mehmet (NSN - DE/Munich)" , Alan Luchuk , "netconf@ietf.org" References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 09:31:03 -0000 On Mon, Sep 26, 2011 at 11:36:00AM -0700, Kent Watsen wrote: > > Ideally there would be a standard for how to extract an identity > from a client certificate, but since there isn't (and since it's out > of scope for us to define one), it seems that we should either adopt > 5953 language to produce a NetConf username or move this RFC off the > standards-track. Yes, it is a pitty that the TLS folks just do not close this hole. And I am sure once they do address this, they will come up with something slightly different... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Sep 27 02:43:01 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E5721F8CE5 for ; Tue, 27 Sep 2011 02:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.126 X-Spam-Level: X-Spam-Status: No, score=-103.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ZJv3mSMPFzyc for ; Tue, 27 Sep 2011 02:43:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E80B321F8CE2 for ; Tue, 27 Sep 2011 02:42:59 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A796C20CE8; Tue, 27 Sep 2011 11:45:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id s83FAmYBoXZg; Tue, 27 Sep 2011 11:45:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D7AC20CDD; Tue, 27 Sep 2011 11:45:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8DB1B1AF89E3; Tue, 27 Sep 2011 11:45:29 +0200 (CEST) Date: Tue, 27 Sep 2011 11:45:29 +0200 From: Juergen Schoenwaelder To: Badra Message-ID: <20110927094527.GC252@elstar.local> Mail-Followup-To: Badra , Kent Watsen , "Ersue, Mehmet (NSN - DE/Munich)" , Alan Luchuk , "netconf@ietf.org" References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 09:43:01 -0000 On Tue, Sep 27, 2011 at 10:14:47AM +0400, Badra wrote: > I thing RFC6141 didn't say anything about that issue (Juergen, please > correct me if I am wrong), and the only way is to figure out how to select > one and only one username. If the certificate contains a single > subjectAltName, that is fine, we extract it. Else, if you have more than > one, you shall specify which one you would extract, the first? the last? > Moreover, if you have non-empty subject distinguished name field, would be > enough to extract its value and set it as the user identity? I guess you mean RFC 6241. Yes, this document just says the transport mappings need to define how a username is provided: [...] The username is a string of characters that match the "Char" production from Section 2.2 of [W3C.REC-xml-20001006]. The algorithm used to derive the username is transport protocol specific and in addition specific to the authentication mechanism used by the transport protocol. The transport protocol MUST provide a username to be used by the other NETCONF layers. This essentially means that all the transports need to be updated at some point in time to define how a username is provided. > Would you please elaborate more to see how we can adopt 5953 language to > resolve the above problem? There is text on how to map a certificate's subjectAltName or CommonName components to a tmSecurityName, or to map a certificate's fingerprint value to a directly specified tmSecurityName. Now, a tmSecurityName is not exactly having the same restrictions as a NETCONF username. What I am interested in is a solution that in addition can work with pre-shared keys on devices that do not have the resources to engage in certificate exchanges. > P.S. Most of the current standards that run applications over TLS (such as > HTTP over TLS or EAP-TLS) defines a common way to extract the an identity > from a client certificate. Can you point to the revelant sections in the RFCs? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbadra@gmail.com Tue Sep 27 03:02:23 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D4921F8B4C for ; Tue, 27 Sep 2011 03:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 L67f6-R+mlAI for ; Tue, 27 Sep 2011 03:02:23 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA43621F8B23 for ; Tue, 27 Sep 2011 03:02:22 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4973794vcb.31 for ; Tue, 27 Sep 2011 03:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cZSfGXRNg4UuAZI41QWy5c4UrhzdYPABZmssNxLsxnE=; b=UYM3vNseSDE88Lg8V0ubkSynYs0WFpQs/sxFMTxJrmaBI9k+EET954uj8gcu2DfT1W CROYeisEeTHXHXxcvNptP/RSYX84UMaTeXfjhiERsQ4wWi49ad9tEWYK1RQkkNpn5gO2 aHVOi+d766vtu2JOAi8k8n3BseibgM6l5Rn9s= MIME-Version: 1.0 Received: by 10.220.140.143 with SMTP id i15mr2052326vcu.241.1317117907466; Tue, 27 Sep 2011 03:05:07 -0700 (PDT) Received: by 10.220.176.198 with HTTP; Tue, 27 Sep 2011 03:05:07 -0700 (PDT) In-Reply-To: <20110927094527.GC252@elstar.local> References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> <20110927094527.GC252@elstar.local> Date: Tue, 27 Sep 2011 14:05:07 +0400 Message-ID: From: Badra To: Juergen Schoenwaelder , Badra , Kent Watsen , "Ersue, Mehmet (NSN - DE/Munich)" , Alan Luchuk , "netconf@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7eb0007b8b04ade96957 Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 10:02:23 -0000 --f46d043c7eb0007b8b04ade96957 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 27, 2011 at 1:45 PM, Juergen Schoenwaelder wrote: > > > There is text on how to map a certificate's subjectAltName or > CommonName components to a tmSecurityName, or to map a certificate's > fingerprint value to a directly specified tmSecurityName. Now, a > tmSecurityName is not exactly having the same restrictions as a > NETCONF username. > > What I am interested in is a solution that in addition can work with > pre-shared keys on devices that do not have the resources to engage in > certificate exchanges. > Currently RFC5539 only specifies Certificate-based authentication! > > > P.S. Most of the current standards that run applications over TLS (such > as > > HTTP over TLS or EAP-TLS) defines a common way to extract the an identity > > from a client certificate. > > Can you point to the revelant sections in the RFCs? > > Please see RFC 5216 section 5.2 and RFC 2818 Section 3 Best regards Badra --f46d043c7eb0007b8b04ade96957 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 27, 2011 at 1:45 PM, Juergen Schoenw= aelder wrote:

=A0
There is text on how to map a certificate= 9;s subjectAltName or
CommonName components to a tmSecurityName, or to m= ap a certificate's
fingerprint value to a directly specified tmSecur= ityName. Now, a
tmSecurityName is not exactly having the same restrictions as a
NETCONF = username.

What I am interested in is a solution that in addition can= work with
pre-shared keys on devices that do not have the resources to = engage in
certificate exchanges.
=A0
=A0
Currently RFC5539 only specifies Certificate-based authentication!
=A0
=A0

> P.S. Most of the current standards that run appl= ications over TLS (such as
> HTTP over TLS or EAP-TLS) defines a comm= on way to extract the an identity
> from a client certificate.

Can you point to the revelant sections in the RFCs?

=A0
=A0
Please see RFC 5216 section 5.2 and RFC 2818 Section 3
=A0
Best regards
Badra
--f46d043c7eb0007b8b04ade96957-- From j.schoenwaelder@jacobs-university.de Tue Sep 27 03:16:04 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B185021F8E03 for ; Tue, 27 Sep 2011 03:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.128 X-Spam-Level: X-Spam-Status: No, score=-103.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 9ak-wFrOdiIF for ; Tue, 27 Sep 2011 03:16:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id ED2AA21F8D8B for ; Tue, 27 Sep 2011 03:16:03 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C19A120CF8; Tue, 27 Sep 2011 12:18:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id D0EpXVg8ZcP8; Tue, 27 Sep 2011 12:18:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F55F20CF7; Tue, 27 Sep 2011 12:18:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3290E1AF914B; Tue, 27 Sep 2011 12:18:34 +0200 (CEST) Date: Tue, 27 Sep 2011 12:18:34 +0200 From: Juergen Schoenwaelder To: Badra Message-ID: <20110927101834.GE252@elstar.local> Mail-Followup-To: Badra , Kent Watsen , "Ersue, Mehmet (NSN - DE/Munich)" , Alan Luchuk , "netconf@ietf.org" References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> <20110927094527.GC252@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 10:16:04 -0000 On Tue, Sep 27, 2011 at 02:05:07PM +0400, Badra wrote: > > Please see RFC 5216 section 5.2 and RFC 2818 Section 3 Well, RFC 2818 section 3.2 says: 3.2. Client Identity Typically, the server has no external knowledge of what the client's identity ought to be and so checks (other than that the client has a certificate chain rooted in an appropriate CA) are not possible. If a server has such knowledge (typically from some source external to HTTP or TLS) it SHOULD check the identity as described above. This is kind of handwaving, no? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbadra@gmail.com Tue Sep 27 03:55:42 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5AC21F8CDE for ; Tue, 27 Sep 2011 03:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4Y5mjyyyI65L for ; Tue, 27 Sep 2011 03:55:41 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C345121F8CD3 for ; Tue, 27 Sep 2011 03:55:41 -0700 (PDT) Received: by vws5 with SMTP id 5so7930732vws.31 for ; Tue, 27 Sep 2011 03:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cHCDaarvTGMC9qYPLSSOY2BS1yNa4rrY6NP1OZkDNqk=; b=pr534Q2KLASMHsryccPgCbVjymuxgj6PsKHWPHP54/4bA+nbed79SkvpNUsBNJsttN tQUXMbRzVDGVbjttJpcLmzD7Atw0xEyo8+H0zeJHHz2tsWWnzSQKpx/mSvoTJuXmkyND H45WaJlH0hmCM7WdjwGotWsRq4lTihQjE8sZc= MIME-Version: 1.0 Received: by 10.52.22.130 with SMTP id d2mr8026976vdf.223.1317121106408; Tue, 27 Sep 2011 03:58:26 -0700 (PDT) Received: by 10.220.176.198 with HTTP; Tue, 27 Sep 2011 03:58:26 -0700 (PDT) In-Reply-To: <20110927101834.GE252@elstar.local> References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> <20110927094527.GC252@elstar.local> <20110927101834.GE252@elstar.local> Date: Tue, 27 Sep 2011 14:58:26 +0400 Message-ID: From: Badra To: Juergen Schoenwaelder , Badra , Kent Watsen , "Ersue, Mehmet (NSN - DE/Munich)" , Alan Luchuk , "netconf@ietf.org" Content-Type: multipart/alternative; boundary=20cf307d0738ac753604adea2762 Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 10:55:42 -0000 --20cf307d0738ac753604adea2762 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 27, 2011 at 2:18 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Sep 27, 2011 at 02:05:07PM +0400, Badra wrote: > > > > Please see RFC 5216 section 5.2 and RFC 2818 Section 3 > > Well, RFC 2818 section 3.2 says: > > 3.2. Client Identity > > Typically, the server has no external knowledge of what the client's > identity ought to be and so checks (other than that the client has a > certificate chain rooted in an appropriate CA) are not possible. If a > server has such knowledge (typically from some source external to > HTTP or TLS) it SHOULD check the identity as described above. > > This is kind of handwaving, no? > > > Please read Section 3.1 --20cf307d0738ac753604adea2762 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Sep 27, 2011 at 2:1= 8 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>= wrote:
On Tue, Sep 27, 2011 at 0= 2:05:07PM +0400, Badra wrote:
>
> Please see RFC 5216 section 5.2 and RFC 2818 Section 3

Well, RFC 2818 section 3.2 says:

3.2. =A0Client Identity

=A0 Typically, the server has no external knowledge of what the client'= ;s
=A0 identity ought to be and so checks (other than that the client has a =A0 certificate chain rooted in an appropriate CA) are not possible. If a<= br> =A0 server has such knowledge (typically from some source external to
=A0 HTTP or TLS) it SHOULD check the identity as described above.

This is kind of handwaving, no?



Pl= ease read Section 3.1=A0

--20cf307d0738ac753604adea2762-- From j.schoenwaelder@jacobs-university.de Tue Sep 27 04:55:13 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BC921F8CE1 for ; Tue, 27 Sep 2011 04:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.129 X-Spam-Level: X-Spam-Status: No, score=-103.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 F5D0ZrmhDuAY for ; Tue, 27 Sep 2011 04:55:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0614E21F8CDE for ; Tue, 27 Sep 2011 04:55:13 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B4E320D22; Tue, 27 Sep 2011 13:57:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ysUzXPY_MTKm; Tue, 27 Sep 2011 13:57:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B70620D07; Tue, 27 Sep 2011 13:57:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BD85B1AF94B9; Tue, 27 Sep 2011 13:57:42 +0200 (CEST) Date: Tue, 27 Sep 2011 13:57:42 +0200 From: Juergen Schoenwaelder To: Badra Message-ID: <20110927115742.GA1478@elstar.local> Mail-Followup-To: Badra , Kent Watsen , "Ersue, Mehmet (NSN - DE/Munich)" , Alan Luchuk , "netconf@ietf.org" References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> <20110927094527.GC252@elstar.local> <20110927101834.GE252@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 11:55:13 -0000 On Tue, Sep 27, 2011 at 02:58:26PM +0400, Badra wrote: > On Tue, Sep 27, 2011 at 2:18 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Tue, Sep 27, 2011 at 02:05:07PM +0400, Badra wrote: > > > > > > Please see RFC 5216 section 5.2 and RFC 2818 Section 3 > > > > Well, RFC 2818 section 3.2 says: > > > > 3.2. Client Identity > > > > Typically, the server has no external knowledge of what the client's > > identity ought to be and so checks (other than that the client has a > > certificate chain rooted in an appropriate CA) are not possible. If a > > server has such knowledge (typically from some source external to > > HTTP or TLS) it SHOULD check the identity as described above. > > > > This is kind of handwaving, no? > > > Please read Section 3.1 But that section is about how a web client checks the identity claimed by an HTTP over TLS server. And even though 3.2 refers vaguely to 3.1, it seems 3.1 really talks about server host names, that is, it is pretty much server identity specific. I still believe RFC 2818 is not very helpful for us. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfc@btconnect.com Tue Sep 27 06:06:38 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F5821F8CF2 for ; Tue, 27 Sep 2011 06:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 17K3LucaJa2l for ; Tue, 27 Sep 2011 06:06:38 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by ietfa.amsl.com (Postfix) with ESMTP id D776421F8CF4 for ; Tue, 27 Sep 2011 06:06:37 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2bthomr07.btconnect.com with SMTP id ERM41956; Tue, 27 Sep 2011 14:09:18 +0100 (BST) Message-ID: <029b01cc7d0d$abff8bc0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" , "Kent Watsen" References: <201109261325.JAA23059@adminfs.snmp.com><20110926134527.GC36350@elstar.local><80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net><84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> <20110927093329.GB252@elstar.local> Date: Tue, 27 Sep 2011 14:04:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0303.4E81CAFD.013D, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.7.19.51514:17:7.586, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_CONTACT_NUM, __CP_URI_IN_BODY, __C230066_P5, BODY_SIZE_1500_1599, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4E81CAFF.018B,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 13:06:38 -0000 ---- Original Message ----- From: "Juergen Schoenwaelder" To: "Kent Watsen" Cc: Sent: Tuesday, September 27, 2011 11:33 AM > On Mon, Sep 26, 2011 at 11:36:00AM -0700, Kent Watsen wrote: > > > > Ideally there would be a standard for how to extract an identity > > from a client certificate, but since there isn't (and since it's out > > of scope for us to define one), it seems that we should either adopt > > 5953 language to produce a NetConf username or move this RFC off the > > standards-track. > > Yes, it is a pitty that the TLS folks just do not close this hole. And > I am sure once they do address this, they will come up with something > slightly different... Juergen It wasn't TLS that came up with that ... RFC6125, assuming that that is what you had in mind, but the Applications Area, and it emerged late in the day that they would like everyone to start from a service name, for use in XMPP, SIP and such like, giving that RFC a very narrow focus. Traditional protocols, like ours, were never on their radar. Tom Petch > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From wjhns1@hardakers.net Tue Sep 27 07:57:41 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3C921F8DDE for ; Tue, 27 Sep 2011 07:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 MMMxbrik16DW for ; Tue, 27 Sep 2011 07:57:40 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 134B021F8DD4 for ; Tue, 27 Sep 2011 07:57:40 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 25A023B2; Tue, 27 Sep 2011 07:59:55 -0700 (PDT) From: Wes Hardaker To: Kent Watsen References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> Date: Tue, 27 Sep 2011 07:59:55 -0700 In-Reply-To: <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> (Kent Watsen's message of "Mon, 26 Sep 2011 11:36:00 -0700") Message-ID: <0ly5xahvys.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 14:57:41 -0000 >>>>> On Mon, 26 Sep 2011 11:36:00 -0700, Kent Watsen said: KW> Ideally there would be a standard for how to extract an identity KW> from a client certificate, but since there isn't (and since it's out KW> of scope for us to define one), it seems that we should either adopt KW> 5953 language to produce a NetConf username or move this RFC off the KW> standards-track. That's not quite the problem. A client certificate has an identity: the certificate. The TLS and corresponding X.509 protocols give you an identity. It tells you that "this client certificate has shown that it, indeed, is on the other side of the connection". The problem is that people and software being configured really don't want a big bunch of gobbledygook printed to their log file (imagine syslog entries saying "XXX connected to the IMAP server" where XXX was a full certificate in ASCII-DER-Dump format. Unfortunately, that is *actually* happening. The certificate is the identity connecting. The text in 5953 (which is now 6353, by the way) was written specifically because an entire certificate really doesn't fit in the 32 character restriction imposed by the access control system. A mapping had to be done or the system wouldn't work. Humans need a mapping too, because the certificate itself is really not that recognizable in its complete form. Humans need something shorter. But the reality is that you *can't* shorten a certificate down to something human-readable or, at least, uniquely named for a configuration field *without losing something* (hence the word "shortening"). When you try and shorten a complete certificate and you ditch some of the elements in it you don't think you care about, you end up with naming collision issues. With a complete certificate in all its full-length glory, you're positive that for someone or something on the other side to use that certificate successfully they must have the private half. It's very very convincing (cryptographically). But... when you try to find a word somewhere in the middle of the certificate (say "Dave") that you can use, because you really don't want to care about the rest of the gobbledygook, you invariably put yourself in trouble: it's quite easy to create another certificate that has the word "Dave" in it in the exact same spot. Suddenly you now have two separate identities that you've accidentally given the permissions for "Dave" too when you really only meant to give them one set of different permissions each. So to state that "there should be a standard for how to extract an identity from a client certificate" is problematic in itself, because you *can't* extract a simple-string identity without loosing a very important part: the proof bits. And without the proof bits, your shortened identity is suddenly subject to naming collisions. Its not *too* bad if you only have one root-CA as a trust anchor. The instant you adopt 2 you'd better know what you're doing. The language, and techniques, in 6353 is designed to do a few things to minimize the impact of the shortening. First and foremost, the wording was designed to state what happens when you have more than one trust anchor. The system is flexible enough to let you do stupid things, because sometimes "doing the right things" can't be done without allowing for "the stupid things" to be possible as well. In reality, if I'd had a choice, I'd have used the full certificate as the identity. Or maybe just a (good) fingerprint of it. But that's not really people-friendly (nor VACM friendly). Tread carefully, but have fun. -- Wes Hardaker SPARTA, Inc. From j.schoenwaelder@jacobs-university.de Tue Sep 27 23:16:54 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B71921F8B13 for ; Tue, 27 Sep 2011 23:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.13 X-Spam-Level: X-Spam-Status: No, score=-103.13 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 vuL9xeYTThZD for ; Tue, 27 Sep 2011 23:16:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4A35321F8B14 for ; Tue, 27 Sep 2011 23:16:53 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 018CE20D22; Wed, 28 Sep 2011 08:19:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wUHX8ZYxpW2M; Wed, 28 Sep 2011 08:19:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE48A20D1C; Wed, 28 Sep 2011 08:19:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4E3801AFA0B9; Wed, 28 Sep 2011 08:19:23 +0200 (CEST) Date: Wed, 28 Sep 2011 08:19:23 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20110928061923.GA4487@elstar.local> Mail-Followup-To: Wes Hardaker , Kent Watsen , "Ersue, Mehmet (NSN - DE/Munich)" , Alan Luchuk , "netconf@ietf.org" References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> <0ly5xahvys.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ly5xahvys.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 06:16:54 -0000 On Tue, Sep 27, 2011 at 07:59:55AM -0700, Wes Hardaker wrote: > >>>>> On Mon, 26 Sep 2011 11:36:00 -0700, Kent Watsen said: > > KW> Ideally there would be a standard for how to extract an identity > KW> from a client certificate, but since there isn't (and since it's out > KW> of scope for us to define one), it seems that we should either adopt > KW> 5953 language to produce a NetConf username or move this RFC off the > KW> standards-track. > > That's not quite the problem. A client certificate has an identity: the > certificate. The TLS and corresponding X.509 protocols give you an > identity. It tells you that "this client certificate has shown that it, > indeed, is on the other side of the connection". > > The problem is that people and software being configured really don't > want a big bunch of gobbledygook printed to their log file (imagine > syslog entries saying "XXX connected to the IMAP server" where XXX was a > full certificate in ASCII-DER-Dump format. Unfortunately, that is > *actually* happening. The certificate is the identity connecting. [...] > The language, and techniques, in 6353 is designed to do a few things to > minimize the impact of the shortening. First and foremost, the wording > was designed to state what happens when you have more than one trust > anchor. The system is flexible enough to let you do stupid things, > because sometimes "doing the right things" can't be done without > allowing for "the stupid things" to be possible as well. In reality, if > I'd had a choice, I'd have used the full certificate as the identity. > Or maybe just a (good) fingerprint of it. But that's not really > people-friendly (nor VACM friendly). So the bottom line is that we need a mapping of the client identity (that is client certificates or fingerprints of them) to a human friendly string. That is just more config and NETCONF was designed for that. ;-) The question is whether we envision a NETCONF specific solution or a more general configuration module for X.509 certs. That said, I like to have support also for constrained devices that just do pre-shared key TLS. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Wed Sep 28 00:02:35 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5667E21F8B0E for ; Wed, 28 Sep 2011 00:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 bK-h1YbC7+Dv for ; Wed, 28 Sep 2011 00:02:34 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id C67B721F8B0C for ; Wed, 28 Sep 2011 00:02:33 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1R8oAo-0002of-RW; Wed, 28 Sep 2011 09:05:15 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1R8oAo-0005wj-2y; Wed, 28 Sep 2011 09:03:18 +0200 Message-ID: <4E82C6B5.1040600@bwijnen.net> Date: Wed, 28 Sep 2011 09:03:17 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Wes Hardaker , Kent Watsen , "Ersue, Mehmet (NSN - DE/Munich)" , Alan Luchuk , "netconf@ietf.org" References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> <0ly5xahvys.fsf@wjh.hardakers.net> <20110928061923.GA4487@elstar.local> In-Reply-To: <20110928061923.GA4487@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd40bc83f8a528c446c1f9d446e7e1e24ae Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 07:02:35 -0000 On 9/28/11 8:19 AM, Juergen Schoenwaelder wrote: > So the bottom line is that we need a mapping of the client identity > (that is client certificates or fingerprints of them) to a human > friendly string. That is just more config and NETCONF was designed > for that.;-) The question is whether we envision a NETCONF specific > solution or a more general configuration module for X.509 certs. Sounds like that might be a generic YANG module then, no? Bert From mbadra@gmail.com Wed Sep 28 00:04:43 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7D821F8D0A for ; Wed, 28 Sep 2011 00:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 5wY4-FpmEzYV for ; Wed, 28 Sep 2011 00:04:42 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC7F21F8B2F for ; Wed, 28 Sep 2011 00:04:42 -0700 (PDT) Received: by vws5 with SMTP id 5so9127487vws.31 for ; Wed, 28 Sep 2011 00:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qjCv5W/mwjbygTqkAIblykitQAB66myZmVSfJx93F/Y=; b=QBRXW90a10TmbgDS7EClZ6YWCUDzPmqh+9UV1Sz7f7pw//70Rm86B8pOkf2zNKlnLW RjhN0wozhMKh3SYfEwbte5K6eY3/4kY2P0zTNwZqNzh5kMyKReFMlh8cOcdI+lJd8WA7 kevmG6XPkILO0f3nRurRFUSJ7TKzv28JAHrS0= MIME-Version: 1.0 Received: by 10.52.27.140 with SMTP id t12mr9011877vdg.156.1317193649393; Wed, 28 Sep 2011 00:07:29 -0700 (PDT) Received: by 10.220.176.198 with HTTP; Wed, 28 Sep 2011 00:07:29 -0700 (PDT) In-Reply-To: <20110928061923.GA4487@elstar.local> References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> <0ly5xahvys.fsf@wjh.hardakers.net> <20110928061923.GA4487@elstar.local> Date: Wed, 28 Sep 2011 11:07:29 +0400 Message-ID: From: Badra To: Juergen Schoenwaelder , Wes Hardaker , Kent Watsen , "Ersue, Mehmet (NSN - DE/Munich)" , Alan Luchuk , "netconf@ietf.org" Content-Type: multipart/alternative; boundary=20cf307abe7592921804adfb0b46 Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 07:04:43 -0000 --20cf307abe7592921804adfb0b46 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 28, 2011 at 10:19 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Sep 27, 2011 at 07:59:55AM -0700, Wes Hardaker wrote: > > >>>>> On Mon, 26 Sep 2011 11:36:00 -0700, Kent Watsen < > kwatsen@juniper.net> said: > > > > KW> Ideally there would be a standard for how to extract an identity > > KW> from a client certificate, but since there isn't (and since it's out > > KW> of scope for us to define one), it seems that we should either adopt > > KW> 5953 language to produce a NetConf username or move this RFC off the > > KW> standards-track. > > > > That's not quite the problem. A client certificate has an identity: the > > certificate. The TLS and corresponding X.509 protocols give you an > > identity. It tells you that "this client certificate has shown that it, > > indeed, is on the other side of the connection". > > > > The problem is that people and software being configured really don't > > want a big bunch of gobbledygook printed to their log file (imagine > > syslog entries saying "XXX connected to the IMAP server" where XXX was a > > full certificate in ASCII-DER-Dump format. Unfortunately, that is > > *actually* happening. The certificate is the identity connecting. > > [...] > > > The language, and techniques, in 6353 is designed to do a few things to > > minimize the impact of the shortening. First and foremost, the wording > > was designed to state what happens when you have more than one trust > > anchor. The system is flexible enough to let you do stupid things, > > because sometimes "doing the right things" can't be done without > > allowing for "the stupid things" to be possible as well. In reality, if > > I'd had a choice, I'd have used the full certificate as the identity. > > Or maybe just a (good) fingerprint of it. But that's not really > > people-friendly (nor VACM friendly). > > So the bottom line is that we need a mapping of the client identity > (that is client certificates or fingerprints of them) to a human > friendly string. That is just more config and NETCONF was designed > for that. ;-) The question is whether we envision a NETCONF specific > solution or a more general configuration module for X.509 certs. > > That said, I like to have support also for constrained devices that > just do pre-shared key TLS. I also support adding PSK, and the mapping is trivial in that case, by using the psk_identity Best regards Badra --20cf307abe7592921804adfb0b46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 28, 2011 at= 10:19 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Sep 27, 2011 at 0= 7:59:55AM -0700, Wes Hardaker wrote:
> >>>>> On Mon, 26 Sep 2011 11:36:00 -0700, Kent Watsen &= lt;kwatsen@juniper.net> said:=
>
> KW> Ideally there would be a standard for how to extract an identit= y
> KW> from a client certificate, but since there isn't (and since= it's out
> KW> of scope for us to define one), it seems that we should either = adopt
> KW> 5953 language to produce a NetConf username or move this RFC of= f the
> KW> standards-track.
>
> That's not quite the problem. =A0A client certificate has an ident= ity: the
> certificate. =A0The TLS and corresponding X.509 protocols give you an<= br> > identity. =A0It tells you that "this client certificate has shown= that it,
> indeed, is on the other side of the connection".
>
> The problem is that people and software being configured really don= 9;t
> want a big bunch of gobbledygook printed to their log file (imagine > syslog entries saying "XXX connected to the IMAP server" whe= re XXX was a
> full certificate in ASCII-DER-Dump format. =A0Unfortunately, that is > *actually* happening. =A0The certificate is the identity connecting.
[...]

> The language, and techniques, in 6353 is desig= ned to do a few things to
> minimize the impact of the shortening. =A0First and foremost, the word= ing
> was designed to state what happens when you have more than one trust > anchor. =A0The system is flexible enough to let you do stupid things,<= br> > because sometimes "doing the right things" can't be done= without
> allowing for "the stupid things" to be possible as well. =A0= In reality, if
> I'd had a choice, I'd have used the full certificate as the id= entity.
> Or maybe just a (good) fingerprint of it. =A0But that's not really=
> people-friendly (nor VACM friendly).

So the bottom line is that we need a mapping of the client identity (that is client certificates or fingerprints of them) to a human
friendly string. =A0That is just more config and NETCONF was designed
for that. ;-) The question is whether we envision a NETCONF specific
solution or a more general configuration module for X.509 certs.

That said, I like to have support also for constrained devices that
just do pre-shared key TLS.

I also support addin= g PSK, and the mapping is trivial in that case, by using the=A0psk_identity=

Best = regards
Badra
--20cf307abe7592921804adfb0b46-- From kwatsen@juniper.net Wed Sep 28 07:05:14 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B7521F8C9B for ; Wed, 28 Sep 2011 07:05:14 -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 XTxOTq-SJiwV for ; Wed, 28 Sep 2011 07:05:13 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 81DCB21F8C92 for ; Wed, 28 Sep 2011 07:05:13 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKToMqMI2rYhjR/48EpvfXejwS9QdDHwWB@postini.com; Wed, 28 Sep 2011 07:08:02 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 28 Sep 2011 06:59:26 -0700 From: Kent Watsen To: "Bert Wijnen (IETF)" , Wes Hardaker , "Ersue, Mehmet (NSN - DE/Munich)" , Alan Luchuk , "netconf@ietf.org" Date: Wed, 28 Sep 2011 06:59:24 -0700 Thread-Topic: [Netconf] Updating NETCONF over TLS document (RFC5539) Thread-Index: Acx9rP6OdK7SWaHbR5mcUEm08DNMAQANvCSw Message-ID: <84600D05C20FF943918238042D7670FD414E1A1657@EMBX01-HQ.jnpr.net> References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> <0ly5xahvys.fsf@wjh.hardakers.net> <20110928061923.GA4487@elstar.local> <4E82C6B5.1040600@bwijnen.net> In-Reply-To: <4E82C6B5.1040600@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 14:05:14 -0000 > Sounds like that might be a generic YANG module then, no? Correct, if we go the route of the device needing to be configured to know = how to extract a NetConf username from a client certificate, then a YANG mo= dule would be good. But I still wonder how many are using TLS/SOAP/BEEP a= nd the need to keep these RFCs standard? > That said, I like to have support also for constrained devices=20 > that just do pre-shared key TLS. Supporting pre-shared keys may introduce a new username-identification prob= lem - without passing a client certificate, how would the device know which= user it is? - a global/default user Defining a YANG module for a generi= c user (even if just a partial mapping) could be slippery. Would we also t= hen define a model for pre-shared SSH RSA/DSA keys? Thanks, Kent From j.schoenwaelder@jacobs-university.de Wed Sep 28 09:11:29 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAB621F8C53 for ; Wed, 28 Sep 2011 09:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.131 X-Spam-Level: X-Spam-Status: No, score=-103.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 3RMKEXPgBp3V for ; Wed, 28 Sep 2011 09:11:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAF621F8AE6 for ; Wed, 28 Sep 2011 09:11:28 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F8C520D84; Wed, 28 Sep 2011 18:14:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jGojiUMcIqfX; Wed, 28 Sep 2011 18:14:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A4F8D20D43; Wed, 28 Sep 2011 18:14:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 02F861AFB208; Wed, 28 Sep 2011 18:13:58 +0200 (CEST) Date: Wed, 28 Sep 2011 18:13:58 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20110928161358.GA7995@elstar.local> Mail-Followup-To: Kent Watsen , "Bert Wijnen (IETF)" , Wes Hardaker , "Ersue, Mehmet (NSN - DE/Munich)" , Alan Luchuk , "netconf@ietf.org" References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> <0ly5xahvys.fsf@wjh.hardakers.net> <20110928061923.GA4487@elstar.local> <4E82C6B5.1040600@bwijnen.net> <84600D05C20FF943918238042D7670FD414E1A1657@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD414E1A1657@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 16:11:29 -0000 On Wed, Sep 28, 2011 at 06:59:24AM -0700, Kent Watsen wrote: > > > Sounds like that might be a generic YANG module then, no? > > Correct, if we go the route of the device needing to be configured > to know how to extract a NetConf username from a client certificate, > then a YANG module would be good. But I still wonder how many are > using TLS/SOAP/BEEP and the need to keep these RFCs standard? I think there is a case for TLS on low-end devices that do not happen to have SSH and where adding SSH would be expensive. Will NETCONF (or NETCONF light) get traction on such devices, I do not know. > > That said, I like to have support also for constrained devices > > that just do pre-shared key TLS. > > Supporting pre-shared keys may introduce a new > username-identification problem - without passing a client > certificate, how would the device know which user it is? I think the TLS pre-shared key extension takes care of this, but I am not an expert. > a global/default user Defining a YANG module for a generic user > (even if just a partial mapping) could be slippery. Would we also > then define a model for pre-shared SSH RSA/DSA keys? I think pre-shared SSH RSA/DSA keys are different from TLS pre-shared keys. I believe it is common practice that people copy public SSH keys to boxes in order to enable access to whoever holds the private key. At least we like to do this. ;-) It would not be bad if there would be a common standard for this and perhaps the NETMOD system model covers this, see . /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From luchuk@snmp.com Wed Sep 28 12:36:03 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F5B11E8121 for ; Wed, 28 Sep 2011 12:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 o-wt2KB+Jh4b for ; Wed, 28 Sep 2011 12:36:02 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8AA11E80FF for ; Wed, 28 Sep 2011 12:36:02 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA07758; Wed, 28 Sep 2011 15:38:34 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id PAA15511; Wed, 28 Sep 2011 15:38:25 -0400 (EDT) Date: Wed, 28 Sep 2011 15:38:25 -0400 (EDT) From: Alan Luchuk Message-Id: <201109281938.PAA15511@adminfs.snmp.com> To: kwatsen@juniper.net, netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 19:36:03 -0000 Hello, >On Wed, Sep 28, 2011 at 06:59:24AM -0700, Kent Watsen wrote: >> >> > Sounds like that might be a generic YANG module then, no? >> >> Correct, if we go the route of the device needing to be configured >> to know how to extract a NetConf username from a client certificate, >> then a YANG module would be good. But I still wonder how many are >> using TLS/SOAP/BEEP and the need to keep these RFCs standard? SNMP Research has implemented NETCONF over TLS. Until a standard mechanism exists for mapping certificates to NETCONF usernames, SNMP Research will implement a proprietary solution. >I think there is a case for TLS on low-end devices that do not happen >to have SSH and where adding SSH would be expensive. Will NETCONF (or >NETCONF light) get traction on such devices, I do not know. I strongly agree there may be platforms on which TLS is readily avail- able, but, for various reasons, SSH is not easily, readily, or freely available. I think the number of machines deployed of this type (think small embedded or desktop machines) is surprisingly large. On these platforms, there may never be a compliant NETCONF implementation of RFC 4741/6241, simply because of the single sentence in sections 2.4 (RFC 4741) or 2.3 (RFC 6241) that requires SSH. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From bertietf@bwijnen.net Thu Sep 29 00:47:37 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0C621F8AD2 for ; Thu, 29 Sep 2011 00:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 t3PQ+BCrpMp6 for ; Thu, 29 Sep 2011 00:47:37 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id CD43A21F8ABE for ; Thu, 29 Sep 2011 00:47:35 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1R9BNq-0002gp-Uu; Thu, 29 Sep 2011 09:50:19 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest187.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1R9BNq-0002Af-K4; Thu, 29 Sep 2011 09:50:18 +0200 Message-ID: <4E84233A.9060000@bwijnen.net> Date: Thu, 29 Sep 2011 09:50:18 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Alan Luchuk References: <201109281938.PAA15511@adminfs.snmp.com> In-Reply-To: <201109281938.PAA15511@adminfs.snmp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd405885866b539c1ed71028cac591309ee Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 07:47:37 -0000 On 9/28/11 9:38 PM, Alan Luchuk wrote: > Hello, > >> >On Wed, Sep 28, 2011 at 06:59:24AM -0700, Kent Watsen wrote: >>> >> >>>> >> > Sounds like that might be a generic YANG module then, no? >>> >> >>> >> Correct, if we go the route of the device needing to be configured >>> >> to know how to extract a NetConf username from a client certificate, >>> >> then a YANG module would be good. But I still wonder how many are >>> >> using TLS/SOAP/BEEP and the need to keep these RFCs standard? > SNMP Research has implemented NETCONF over TLS. Until a standard > mechanism exists for mapping certificates to NETCONF usernames, SNMP > Research will implement a proprietary solution. > As WG chair, I would much more appreciate it if SNMP Research helps us define/document a potential solution that we can try to get consensus on and then standardize it. Certainly if you are doing a commercial implementation and so probably have customers who deploy it, such experience would be very helpful to try and work on a standardized solution. Bert From janl@tail-f.com Thu Sep 29 01:15:13 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2910D21F8C37 for ; Thu, 29 Sep 2011 01:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001] 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 nfIk-jLK2RWz for ; Thu, 29 Sep 2011 01:15:09 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B832B21F8C3E for ; Thu, 29 Sep 2011 01:15:08 -0700 (PDT) Received: from [192.168.1.126] (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0352C12008F2; Thu, 29 Sep 2011 10:17:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_E7BE49D8-E5EF-46CC-8807-20A96CDD5B60" From: Jan Lindblad In-Reply-To: <20110928161358.GA7995@elstar.local> Date: Thu, 29 Sep 2011 10:17:57 +0200 Message-Id: References: <201109261325.JAA23059@adminfs.snmp.com> <20110926134527.GC36350@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6402B2D285@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD414D8FE7CB@EMBX01-HQ.jnpr.net> <0ly5xahvys.fsf@wjh.hardakers.net> <20110928061923.GA4487@elstar.local> <4E82C6B5.1040600@bwijnen.net> <84600D05C20FF943918238042D7670FD414E1A1657@EMBX01-HQ.jnpr.net> <20110928161358.GA7995@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1244.3) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 08:15:13 -0000 --Apple-Mail=_E7BE49D8-E5EF-46CC-8807-20A96CDD5B60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28 sep 2011, at 18:13, Juergen Schoenwaelder wrote: > On Wed, Sep 28, 2011 at 06:59:24AM -0700, Kent Watsen wrote: >>=20 >>> Sounds like that might be a generic YANG module then, no? >>=20 >> Correct, if we go the route of the device needing to be configured >> to know how to extract a NetConf username from a client certificate, >> then a YANG module would be good. But I still wonder how many are >> using TLS/SOAP/BEEP and the need to keep these RFCs standard? Here's one data point from the BBWF 2011, yesterday in Paris. One of my = colleagues were there and summarized a conversation with a NEP: "Interesting conversation with [----]. It seems that [----] had = introduced Netconf themselves, over SOAP, for their [----] product line. = He said they were not that satisfied with it, claimed that using Netconf = over SOAP removed the benefits of SOAP and web services and they had = decided to drop it." Seems to me there is a risk that keeping old and rarely used specs could = hurt the NETCONF adoption. /jan -- Jan Lindblad, janl@tail-f.com, +46 702855728 Principal Solutions Architect, Tail-f Systems, www.tail-f.com --Apple-Mail=_E7BE49D8-E5EF-46CC-8807-20A96CDD5B60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Wed, Sep 28, 2011 at 06:59:24AM -0700, Kent Watsen = wrote:

Sounds like that might be a = generic YANG module then, no?

Correct, if we = go the route of the device needing to be = configured
to know how to = extract a NetConf username from a client = certificate,
then a YANG = module would be good.  But I still wonder how many = are
using TLS/SOAP/BEEP and = the need to keep these RFCs = standard?

Her= e's one data point from the BBWF 2011, yesterday in Paris. One of my = colleagues were there and summarized a conversation with a = NEP:

"Interesting conversation with [----]. It = seems that [----] had introduced Netconf themselves, over SOAP, for = their [----] product line. He said they were not that satisfied with it, = claimed that using Netconf over SOAP removed the benefits of SOAP and = web services and they had decided to drop = it."

Seems to me there is a risk that keeping = old and rarely used specs could hurt the NETCONF = adoption.

/jan
--
Jan Lindblad, janl@tail-f.com, +46 = 702855728
www.tail-f.com

= --Apple-Mail=_E7BE49D8-E5EF-46CC-8807-20A96CDD5B60-- From luchuk@snmp.com Thu Sep 29 13:42:33 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C362B21F8C82 for ; Thu, 29 Sep 2011 13:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.572 X-Spam-Level: X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, SORTED_RECIPS=1.125] 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 uyXMaSn2HQq0 for ; Thu, 29 Sep 2011 13:42:33 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id EE6BE21F8C80 for ; Thu, 29 Sep 2011 13:42:32 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA13330; Thu, 29 Sep 2011 16:45:09 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id QAA28573; Thu, 29 Sep 2011 16:44:48 -0400 (EDT) Date: Thu, 29 Sep 2011 16:44:48 -0400 (EDT) From: Alan Luchuk Message-Id: <201109292044.QAA28573@adminfs.snmp.com> To: bertietf@bwijnen.net Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 20:42:33 -0000 Hello, >As WG chair, I would much more appreciate it if SNMP Research >helps us define/document a potential solution that we can try >to get consensus on and then standardize it. > >Certainly if you are doing a commercial implementation and so >probably have customers who deploy it, such experience would >be very helpful to try and work on a standardized solution. > >Bert We'll be glad assist as we are able, and implement and test products from WG efforts. That's why I posed the initial question about updates to RFC 5539; I was ready to implement and test them. However, after the late May 2011 WG discussion about updates to RFC 5539, we did not have anything useful to add to the discussion that had not already been offered. For the interim, a simple scheme to map certificate fingerprints to NETCONF usernames is sufficient. But for the longer term, as a standardized solution, I would look closely at RFC 6353 and see if its mechanisms could be adapted for use with NETCONF. I have great respect for the knowledge and experience of the team that developed RFC 6353, and believe RFC 6353's mechanism for mapping certificates is well-considered, flexible, and useful, in the "real world." Regards --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From mbadra@gmail.com Fri Sep 30 04:29:24 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9FD21F8AC9 for ; Fri, 30 Sep 2011 04:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 CJZ6JLCDajpP for ; Fri, 30 Sep 2011 04:29:23 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABD121F8B0A for ; Fri, 30 Sep 2011 04:29:20 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1802612vcb.31 for ; Fri, 30 Sep 2011 04:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xAajzoBMuEiHshqVvJR/99G/iPV8FuysLFl/cNsy9Gk=; b=jIxcFyFn2SUotHjXDgjJ1msbGtCXAaVkxQbhCsTIcUdiNwcASb2DrVI7orfp6UVLgL flrnIKWvoONit/L9/gzg1rIuZZ8WQUeVaJy0Jm8ZW5g8ZwlnYopud38dwJcKETP1/A81 BkrwXwp7XVEZ9DNvW/nw0avCEOP3yVk6WI2Ig= MIME-Version: 1.0 Received: by 10.52.22.130 with SMTP id d2mr12335740vdf.223.1317382333721; Fri, 30 Sep 2011 04:32:13 -0700 (PDT) Received: by 10.220.190.76 with HTTP; Fri, 30 Sep 2011 04:32:13 -0700 (PDT) In-Reply-To: <201109292044.QAA28573@adminfs.snmp.com> References: <201109292044.QAA28573@adminfs.snmp.com> Date: Fri, 30 Sep 2011 13:32:13 +0200 Message-ID: From: Badra To: Alan Luchuk Content-Type: multipart/alternative; boundary=20cf307d073808ed5f04ae26fa55 Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 11:29:24 -0000 --20cf307d073808ed5f04ae26fa55 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 29, 2011 at 10:44 PM, Alan Luchuk wrote: > > For the interim, a simple scheme to map certificate fingerprints to > NETCONF usernames is sufficient. But for the longer term, as a > standardized solution, I would look closely at RFC 6353 and see if > its mechanisms could be adapted for use with NETCONF. I have great > respect for the knowledge and experience of the team that developed > RFC 6353, and believe RFC 6353's mechanism for mapping certificates > is well-considered, flexible, and useful, in the "real world." > > > The fingerprint described in RFC 5425 would be more than enough for our case. Our issue is when multiple subjectAltNames are presented in the certificate. Shall we exporte all of them to the NETCONF message layer. No, simply because RFC6241 doens't provide that service to the transport. We shall then define our order when exporting the SubjectAltName fields. Consider we agreed on assigning the order on the following types 1= dNSName 2=rfc822Name 3= iPAddress (I believe we shall limit our set of acceptable SubjectAltName to the above three types) Suppose the order is 1, 2, 3 If 1 is set, we extract only 1, ElseIf 2 is set, we extract 2, ElseIf if 3 is set we extract 3 Else, drop the TLS session Once we agree on the order, I can extend the above algorithm and define a loop iterating over the set a set of SubjectAltName. This may be useful if we want to find a match in any of the exported subjectAltNames. P.S. In RFC 6353, the use of CommonName field is NOT deprecated, whereas we agreed on not recommend this usage here. Best regards, Badra --20cf307d073808ed5f04ae26fa55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 29, 2011 at= 10:44 PM, Alan Luchuk <luchuk@snmp.com> wrote:

For the interim, a simple scheme to map certificate fingerprints to
NETCONF usernames is sufficient. =A0But for the longer term, as a
standardized solution, I would look closely at RFC 6353 and see if
its mechanisms could be adapted for use with NETCONF. =A0I have great
respect for the knowledge and experience of the team that developed
RFC 6353, and believe RFC 6353's mechanism for mapping certificates
is well-considered, flexible, and useful, in the "real world."



The fingerpri= nt described in RFC 5425 would be more than enough for our case.

O= ur issue is when multiple subjectAltNames are presented in the certificate.= =A0Shall we=A0exporte all of them to=A0the=A0NETCONF=A0message layer. No, s= imply because=A0RFC6241 doens't provide that service to the transport.<= div>
We shall then=A0define our order when exporting the Sub= jectAltName fields. Consider we agreed on assigning the order on the follow= ing types
1=3D dNSName
2=3Drfc822Name
3=3D iP= Address

(I believe we shall limit our set of acceptable Subject= AltName to the above three types)

Suppose the orde= r is 1, 2, 3

If 1 is set, we extract only 1,=A0
ElseIf 2 is set, we extract 2,=A0
ElseIf if 3 is set we extr= act 3
Else, drop the TLS session

Once we= agree on the order, I can extend the above algorithm and define a=A0loop i= terating over the set a set of SubjectAltName. This may be useful if we wan= t to find a=A0match in any of the exported=A0subjectAltNames.

P.S.=A0In RFC 6353, the use of=A0CommonName field is NOT deprecated, whereas we agreed on not recommend this usage here.


Best regards,

Badra

--20cf307d073808ed5f04ae26fa55-- From wjhns1@hardakers.net Fri Sep 30 07:00:37 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8120621F8BBF for ; Fri, 30 Sep 2011 07:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 I9fTkU8tWMvJ for ; Fri, 30 Sep 2011 07:00:37 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 01F7921F8BBE for ; Fri, 30 Sep 2011 07:00:37 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 84114395; Fri, 30 Sep 2011 07:03:00 -0700 (PDT) From: Wes Hardaker To: Badra References: <201109292044.QAA28573@adminfs.snmp.com> Date: Fri, 30 Sep 2011 07:03:00 -0700 In-Reply-To: (Badra's message of "Fri, 30 Sep 2011 13:32:13 +0200") Message-ID: <0lzkhm9lgr.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 14:00:37 -0000 >>>>> On Fri, 30 Sep 2011 13:32:13 +0200, Badra said: B> We shall then define our order when exporting the SubjectAltName fields. B> Consider we agreed on assigning the order on the following types B> 1= dNSName B> 2=rfc822Name B> 3= iPAddress B> (I believe we shall limit our set of acceptable SubjectAltName to the above B> three types) I hope you mean: "ignore the others" not "drop any certificate that contains something else". Also, make sure algorithm deals with certificates that include multiple instances of the subjectAltName types you want to use (eg, multiple rfc822Names). -- Wes Hardaker SPARTA, Inc. From luchuk@snmp.com Fri Sep 30 07:26:57 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631FD21F84C1 for ; Fri, 30 Sep 2011 07:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.497, 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 101bbbcj0fML for ; Fri, 30 Sep 2011 07:26:56 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7182821F84BC for ; Fri, 30 Sep 2011 07:26:56 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA28893; Fri, 30 Sep 2011 10:29:45 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id KAA07229; Fri, 30 Sep 2011 10:29:40 -0400 (EDT) Date: Fri, 30 Sep 2011 10:29:40 -0400 (EDT) From: Alan Luchuk Message-Id: <201109301429.KAA07229@adminfs.snmp.com> To: mbadra@gmail.com Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 14:26:57 -0000 Hello, >The fingerprint described in RFC 5425 would be more than enough for our >case. > >Our issue is when multiple subjectAltNames are presented in the >certificate. Shall we exporte all of them to the NETCONF message layer. No, >simply because RFC6241 doens't provide that service to the transport. > >We shall then define our order when exporting the SubjectAltName fields. >Consider we agreed on assigning the order on the following types >1= dNSName >2=rfc822Name >3= iPAddress > >(I believe we shall limit our set of acceptable SubjectAltName to the above >three types) > >Suppose the order is 1, 2, 3 > >If 1 is set, we extract only 1, >ElseIf 2 is set, we extract 2, >ElseIf if 3 is set we extract 3 >Else, drop the TLS session > >Once we agree on the order, I can extend the above algorithm and define >a loop iterating over the set a set of SubjectAltName. This may be useful if >we want to find a match in any of the exported subjectAltNames. > >P.S. In RFC 6353, the use of CommonName field is NOT deprecated, whereas we >agreed on not recommend this usage here. > >Best regards, >Badra I can align with this suggestion, but I have no clue how generally useful it would be to NETCONF over TLS users. Because I think alot of really experienced people already discussed mapping certificates to security names when RFC 6353 was developed, I consider the mechanism proposed in RFC 6353 is likely useful to the NETCONF over TLS user community as well. Thus, for a proposed standard, my _preference_ would be to implement something similar to RFC 6353 in NETCONF over TLS. In RFC 6353, for each configured fingerprint, there is another configu- ration parameter that specifies: - Map the fingerprint to a specific security name (the interim solution); - Choose any specific one of the subjectAltName fields above; - Check all three of the subjectAltName fields above, and check them in the priority order of rfc822Name, dNSName, iPAddress; - Choose the CommonName field (because the CommonName portion of the Subject field is deprecated, perhaps this should NOT be included in NETCONF over TLS.) I would propose using this model in NETCONF, and adding at least one additional choice to the list: - Check all three of the subjectAltName fields above, and check them in the priority order of dNSName, rfc822Name, iPAddress, to satisfy your envisioned need described above; I think that another pretty important feature from RFC 6353 is the ability to specify the fingerprint of one of the CA certificates in the trust chain. This way, for example, all of the certificates signed by the CA for the Network Management group would be mapped the same way, without requiring explicit mappings for each certificate issued to each member of the Network Management group. (It's been awhile since I worked with or thoroughly read RFC 6353, so someone please jump in and correct any technical errors.) Using these features from RFC 6353, all foreseen possible mappings from certificates to NETCONF over TLS usernames could be covered. The NETCONF over TLS users could choose the scheme that works best in their deployment; they would not be constrained by a more restricted scheme specified by the NETCONF over TLS specification developers. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From mbadra@gmail.com Fri Sep 30 09:59:34 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77ED821F8BA2 for ; Fri, 30 Sep 2011 09:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3yXvtavNPwB4 for ; Fri, 30 Sep 2011 09:59:33 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0BCC21F8B6B for ; Fri, 30 Sep 2011 09:59:28 -0700 (PDT) Received: by qyk32 with SMTP id 32so531370qyk.10 for ; Fri, 30 Sep 2011 10:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o39oFAa61zI96mxiN60gdbIopRDgtfki13tnt/I4erY=; b=ikRhZj3dMSv2MUNoomCRXcsLasCgs3fHlFDOzszifKUOyOD9GanX9OFq9LyRNSUFiJ 0n1I7LXbkcjCNirgjHMYmRS9oWhKHZULy0cvPSoPCCUbgAj7jD2d1/5d2sjZ2+qo1J3C WnCdGEfoCvQuEG2w/aMtsZl8ZYqlnk2iSRUIA= MIME-Version: 1.0 Received: by 10.229.43.194 with SMTP id x2mr9376040qce.63.1317402142722; Fri, 30 Sep 2011 10:02:22 -0700 (PDT) Received: by 10.229.234.13 with HTTP; Fri, 30 Sep 2011 10:02:22 -0700 (PDT) In-Reply-To: <0lzkhm9lgr.fsf@wjh.hardakers.net> References: <201109292044.QAA28573@adminfs.snmp.com> <0lzkhm9lgr.fsf@wjh.hardakers.net> Date: Fri, 30 Sep 2011 19:02:22 +0200 Message-ID: From: Badra To: Wes Hardaker Content-Type: multipart/alternative; boundary=0016367b6f54be4a1f04ae2b965d Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 16:59:34 -0000 --0016367b6f54be4a1f04ae2b965d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 30, 2011 at 4:03 PM, Wes Hardaker wrote: > >>>>> On Fri, 30 Sep 2011 13:32:13 +0200, Badra said: > > B> We shall then define our order when exporting the SubjectAltName fields. > B> Consider we agreed on assigning the order on the following types > B> 1= dNSName > B> 2=rfc822Name > B> 3= iPAddress > > B> (I believe we shall limit our set of acceptable SubjectAltName to the > above > B> three types) > > I hope you mean: "ignore the others" not "drop any certificate that > contains something else". Also, make sure algorithm deals with > certificates that include multiple instances of the subjectAltName types > you want to use (eg, multiple rfc822Names). > > The idea is to specify a set of parameters that would be extracted from the certificate, any certificate that not contains at least one of these parameters would be rejected. Best regards Badra --0016367b6f54be4a1f04ae2b965d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 30, 2011 at= 4:03 PM, Wes Hardaker <wjhns1@hardakers.net> wrote:
>>>>> On Fri, 30 Sep 2011 13:32:13 +0200, Badra <mbadra@gmail.com> said:

B> We shall then define our order when exporting the SubjectAltName fiel= ds.
B> Consider we agreed on assigning the order on the following types
B> 1=3D dNSName
B> 2=3Drfc822Name
B> 3=3D iPAddress

B> (I believe we shall limit our set of acceptable SubjectAltName to the= above
B> three types)

I hope you mean: "ignore the others" not "drop any certifica= te that
contains something else". =A0Also, make sure algorithm deals with
certificates that include multiple instances of the subjectAltName types you want to use (eg, multiple rfc822Names).


The idea is to specify a set of parameters that would be extracted= from the certificate, any certificate that not contains at least one of th= ese parameters would be rejected.

Best regards
Badra

--0016367b6f54be4a1f04ae2b965d-- From mbadra@gmail.com Fri Sep 30 10:02:15 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143EC21F8672 for ; Fri, 30 Sep 2011 10:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 oBZCDPLElYN8 for ; Fri, 30 Sep 2011 10:02:14 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C035221F8520 for ; Fri, 30 Sep 2011 10:02:12 -0700 (PDT) Received: by qadb12 with SMTP id b12so622115qad.31 for ; Fri, 30 Sep 2011 10:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G8e2km2EolFGbF+0A6yOc5vlH+0QLSmjQvaKZfGDPQE=; b=YNOtYsTEAg7KkMweKuOgeG1TN4U3SMabswYAHx8ElOe6uj9LUIOKe0XwEwvt2RkOEO ElkhihW9wkhOMPhix3C1qBjNdJ3Tlw2ocxrU1MwOj60cs8znkGRuQhIt6vPSRopO7/vS 7EkQM4aSQbY2v8vl4h4CjZnd9zq8jEVZ8zk9k= MIME-Version: 1.0 Received: by 10.224.70.212 with SMTP id e20mr433770qaj.389.1317402306591; Fri, 30 Sep 2011 10:05:06 -0700 (PDT) Received: by 10.229.234.13 with HTTP; Fri, 30 Sep 2011 10:05:06 -0700 (PDT) In-Reply-To: <201109301429.KAA07229@adminfs.snmp.com> References: <201109301429.KAA07229@adminfs.snmp.com> Date: Fri, 30 Sep 2011 19:05:06 +0200 Message-ID: From: Badra To: Alan Luchuk Content-Type: multipart/alternative; boundary=bcaec51ba3f982ba8904ae2ba014 Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 17:02:15 -0000 --bcaec51ba3f982ba8904ae2ba014 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 30, 2011 at 4:29 PM, Alan Luchuk wrote: > Hello, > > >The fingerprint described in RFC 5425 would be more than enough for our > >case. > > > >Our issue is when multiple subjectAltNames are presented in the > >certificate. Shall we exporte all of them to the NETCONF message layer. > No, > >simply because RFC6241 doens't provide that service to the transport. > > > >We shall then define our order when exporting the SubjectAltName fields. > >Consider we agreed on assigning the order on the following types > >1= dNSName > >2=rfc822Name > >3= iPAddress > > > >(I believe we shall limit our set of acceptable SubjectAltName to the > above > >three types) > > > >Suppose the order is 1, 2, 3 > > > >If 1 is set, we extract only 1, > >ElseIf 2 is set, we extract 2, > >ElseIf if 3 is set we extract 3 > >Else, drop the TLS session > > > >Once we agree on the order, I can extend the above algorithm and define > >a loop iterating over the set a set of SubjectAltName. This may be useful > if > >we want to find a match in any of the exported subjectAltNames. > > > >P.S. In RFC 6353, the use of CommonName field is NOT deprecated, whereas > we > >agreed on not recommend this usage here. > > > >Best regards, > >Badra > > > I can align with this suggestion, but I have no clue how generally useful > it would be to NETCONF over TLS users. Because I think alot of really > experienced people already discussed mapping certificates to security > names when RFC 6353 was developed, I consider the mechanism proposed in > RFC 6353 is likely useful to the NETCONF over TLS user community as well. > Thus, for a proposed standard, my _preference_ would be to implement > something similar to RFC 6353 in NETCONF over TLS. > > In RFC 6353, for each configured fingerprint, there is another configu- > ration parameter that specifies: > > - Map the fingerprint to a specific security name (the interim solution); > - Choose any specific one of the subjectAltName fields above; > - Check all three of the subjectAltName fields above, and check them > in the priority order of rfc822Name, dNSName, iPAddress; > - Choose the CommonName field (because the CommonName portion of the > Subject field is deprecated, perhaps this should NOT be included > in NETCONF over TLS.) > > I would propose using this model in NETCONF, and adding at least one > additional choice to the list: > > - Check all three of the subjectAltName fields above, and check them > in the priority order of dNSName, rfc822Name, iPAddress, to satisfy > your envisioned need described above; > > I think that another pretty important feature from RFC 6353 is the ability > to specify the fingerprint of one of the CA certificates in the trust > chain. > This way, for example, all of the certificates signed by the CA for the > Network Management group would be mapped the same way, without requiring > explicit mappings for each certificate issued to each member of the > Network Management group. > > (It's been awhile since I worked with or thoroughly read RFC 6353, so > someone please jump in and correct any technical errors.) > > Using these features from RFC 6353, all foreseen possible mappings from > certificates to NETCONF over TLS usernames could be covered. The NETCONF > over TLS users could choose the scheme that works best in their deployment; > they would not be constrained by a more restricted scheme specified by > the NETCONF over TLS specification developers. > > > Regards, > --Alan > > Dear Alan, I think this is what we do need. How does RFC 6353 deal when certificates include multiple instances of the subjectAltName (refer to Wes example, multiple rfc822Names)? Best regards Badra --bcaec51ba3f982ba8904ae2ba014 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 30, 2011 at= 4:29 PM, Alan Luchuk <luchuk@snmp.com> wrote:

>The fingerprint described in RFC 5425 would be more than enough for our=
>case.
>
>Our issue is when multiple subjectAltNames are presented in the
>certificate. Shall we exporte all of them to the NETCONF message layer.= No,
>simply because RFC6241 doens't provide that service to the transpor= t.
>
>We shall then define our order when exporting t= he SubjectAltName fields.
>Consider we agreed on assigning the order on th= e following types
>1=3D dNSName
>2=3Drfc822Name
>3=3D iPAddress
>
>(I believe we shall limit our set of acceptable= SubjectAltName to the above
>three types)
>
>Suppose the order is 1, 2, 3
>
>If 1 is set, we extract only 1,
>ElseIf 2 is set, we extract 2,
>ElseIf if 3 is set we extract 3
>Else, drop the TLS session
>
>Once we agree on the order, I can extend the above algorithm and define=
>a loop iterating over the set a set of SubjectAltName. This may be usef= ul if
>we want to find a match in any of the exported subjectAltNames.
>
>P.S. In RFC 6353, the use of CommonName field is NOT deprecated, wherea= s we
>agreed on not recommend this usage here.
>
>Best regards,
>Badra


I can align with this suggestion, but I have no clue how generally us= eful
it would be to NETCONF over TLS users. =A0Because I think alot of really experienced people already discussed mapping certificates to security
names when RFC 6353 was developed, I consider the mechanism proposed in
RFC 6353 is likely useful to the NETCONF over TLS user community as well. Thus, for a proposed standard, my _preference_ would be to implement
something similar to RFC 6353 in NETCONF over TLS.

In RFC 6353, for each configured fingerprint, there is another configu-
ration parameter that specifies:

- =A0Map the fingerprint to a specific security name (the interim solution)= ;
- =A0Choose any specific one of the subjectAltName fields above;
- =A0Check all three of the subjectAltName fields above, and check them
=A0 in the priority order of rfc822Name, dNSName, iPAddress;
- =A0Choose the CommonName field (because the CommonName portion of the
=A0 Subject field is deprecated, perhaps this should NOT be included
=A0 in NETCONF over TLS.)

I would propose using this model in NETCONF, and adding at least one
additional choice to the list:

- =A0Check all three of the subjectAltName fields above, and check them
=A0 in the priority order of dNSName, rfc822Name, iPAddress, to satisfy =A0 your envisioned need described above;

I think that another pretty important feature from RFC 6353 is the ability<= br> to specify the fingerprint of one of the CA certificates in the trust chain= .
This way, for example, all of the certificates signed by the CA for the
Network Management group would be mapped the same way, without requiring explicit mappings for each certificate issued to each member of the
Network Management group.

(It's been awhile since I worked with or thoroughly read RFC 6353, so someone please jump in and correct any technical errors.)

Using these features from RFC 6353, all foreseen possible mappings from
certificates to NETCONF over TLS usernames could be covered. =A0The NETCONF=
over TLS users could choose the scheme that works best in their deployment;=
they would not be constrained by a more restricted scheme specified by
the NETCONF over TLS specification developers.


Regards,
--Alan

<= /div>

Dear Alan,

I= think this is what we do need.
How =A0does=A0RFC 6353 deal when= =A0certificates include multiple instances of the subjectAltName (refer to = Wes example,=A0multiple rfc822Names)?

Best regards
Badra

--bcaec51ba3f982ba8904ae2ba014-- From wjhns1@hardakers.net Fri Sep 30 10:57:15 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D25321F84BC for ; Fri, 30 Sep 2011 10:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 RQk2SIiYYhPr for ; Fri, 30 Sep 2011 10:57:15 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 0199221F84B7 for ; Fri, 30 Sep 2011 10:57:15 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 874413F7; Fri, 30 Sep 2011 10:59:36 -0700 (PDT) From: Wes Hardaker To: Badra References: <201109301429.KAA07229@adminfs.snmp.com> Date: Fri, 30 Sep 2011 10:59:36 -0700 In-Reply-To: (Badra's message of "Fri, 30 Sep 2011 19:05:06 +0200") Message-ID: <0l62k96hdj.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 17:57:15 -0000 >>>>> On Fri, 30 Sep 2011 19:05:06 +0200, Badra said: B> How does RFC 6353 deal when certificates include multiple instances B> of the subjectAltName (refer to Wes example, multiple rfc822Names)? First hit wins. -- Wes Hardaker SPARTA, Inc. From luchuk@snmp.com Fri Sep 30 11:48:00 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E228F21F8B73 for ; Fri, 30 Sep 2011 11:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.373, 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 OWgVklGbCjmk for ; Fri, 30 Sep 2011 11:48:00 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF7221F8B58 for ; Fri, 30 Sep 2011 11:47:59 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA23116; Fri, 30 Sep 2011 14:50:48 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id OAA14004; Fri, 30 Sep 2011 14:50:38 -0400 (EDT) Date: Fri, 30 Sep 2011 14:50:38 -0400 (EDT) From: Alan Luchuk Message-Id: <201109301850.OAA14004@adminfs.snmp.com> To: mbadra@gmail.com Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 18:48:01 -0000 Hello, >I think this is what we do need. >How does RFC 6353 deal when certificates include multiple instances of the >subjectAltName (refer to Wes example, multiple rfc822Names)? RFC 6353 has a defined mechanism for handling different fields of the subjectAltName extension (e.g.; rfc822Name, dNSName, iPAddress), but I think it is silent about handling multiple instances of the same field (e.g.; multiple instances of the rfc822Name). I've taken a quick scan over RFC 6353 again, and do not immediately notice anything about multiple instances of the same field. I'd have to re-read carefully to make sure. In the case where a certificate contains multiple instances of the same subjectAltName field, it would be easier for our implementation if a single NETCONF username was produced from a certificate. That is, the mapping code prioritizes and selects the NETCONF username, rather than producing a set of NETCONF usernames that are handed up and must be prioritized by a higher layer in the code. I would suspect this would be true for other NETCONF/TLS implementations as well. Perhaps you have posted this already, but do you have a suggested mechanism for handling multiple instances of the same field in the subjectAltName extension? If so, I would envision this as just another mapping choice, with perhaps another mapping configuration parameter. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From mbadra@gmail.com Fri Sep 30 12:03:00 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E8821F8BC3 for ; Fri, 30 Sep 2011 12:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8R7oM6cmIw+J for ; Fri, 30 Sep 2011 12:02:59 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B321C21F8BBF for ; Fri, 30 Sep 2011 12:02:59 -0700 (PDT) Received: by vws5 with SMTP id 5so2290908vws.31 for ; Fri, 30 Sep 2011 12:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZE1Opk5PWIS1qErV4LyUNaGkDrM1caOQX7dauOdLNKY=; b=cxtqmgD6hBTL7jsSOd0mgXhthI5bUwHi/IsWiEVLA/guqn8Y69swx/24yFNPfeKn/8 c2iHapuGyljYXpCApIOvsRwChC6s0xNN7mPirJJ88qyN8YlOtZ2PcX3A5Sq2RKSbieyH rbwxl1NN1YDE0XORlKFSSI/tCrmV3C7+n7ZJ4= MIME-Version: 1.0 Received: by 10.52.27.140 with SMTP id t12mr12593012vdg.156.1317409553876; Fri, 30 Sep 2011 12:05:53 -0700 (PDT) Received: by 10.220.190.76 with HTTP; Fri, 30 Sep 2011 12:05:53 -0700 (PDT) In-Reply-To: <201109301850.OAA14004@adminfs.snmp.com> References: <201109301850.OAA14004@adminfs.snmp.com> Date: Fri, 30 Sep 2011 21:05:53 +0200 Message-ID: From: Badra To: Alan Luchuk Content-Type: multipart/alternative; boundary=20cf307abe757b850704ae2d507c Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 19:03:00 -0000 --20cf307abe757b850704ae2d507c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 30, 2011 at 8:50 PM, Alan Luchuk wrote: > > Perhaps you have posted this already, but do you have a suggested mechanism > for handling multiple instances of the same field in the subjectAltName > extension? If so, I would envision this as just another mapping choice, > with perhaps another mapping configuration parameter. Well, a priority order should help here, and as Wes pointed out, first hit wins Best regards Badra --20cf307abe757b850704ae2d507c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 30, 2011 at= 8:50 PM, Alan Luchuk <luchuk@snmp.com> wrote: