From alexb at ripe.net Wed Dec 4 12:57:26 2013 From: alexb at ripe.net (Alex Band) Date: Wed, 4 Dec 2013 12:57:26 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access Message-ID: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> Dear colleagues, In our RIPE NCC Access authentication system, we offer the ability to log in using an X.509 identity certificate instead of a username and password. This functionality was transferred from the legacy authentication system we used to have, without evaluating the value of this feature at the time. Since then, we have encountered several implementation, user interface and support issues surrounding this feature, while it is used by less than 0.7% of the users with a RIPE NCC Access account. Most importantly, the functionality does not actually offer any additional security. This is something that is provided by true two-factor authentication. We would like to propose to put this functionality in maintenance mode, meaning that it would be provided as it is without a service guarantee. Alternatively, it could be removed altogether. This would free us of a maintenance and support burden, meaning that we can spend these resources on other valuable services. If the membership approves, the RIPE NCC could investigate ways to implement true two-factor authentication for RIPE NCC Access. We look forward to hearing your feedback. Kind regards, Alex Band Product Manager RIPE NCC From sander at steffann.nl Wed Dec 4 13:58:59 2013 From: sander at steffann.nl (Sander Steffann) Date: Wed, 4 Dec 2013 13:58:59 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> Message-ID: <9CD3DD5C-16E3-451E-A5C3-80DB2EE2DD4D@steffann.nl> Hi, > We would like to propose to put this functionality in maintenance mode, meaning that it would be provided as it is without a service guarantee. Alternatively, it could be removed altogether. This would free us of a maintenance and support burden, meaning that we can spend these resources on other valuable services. I wouldn't mind if it was removed completely. > If the membership approves, the RIPE NCC could investigate ways to implement true two-factor authentication for RIPE NCC Access. Yes, that would be a much better thing to invest resources in. Cheers, Sander From wolfgang.tremmel at de-cix.net Wed Dec 4 14:28:44 2013 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Wed, 4 Dec 2013 14:28:44 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: <9CD3DD5C-16E3-451E-A5C3-80DB2EE2DD4D@steffann.nl> References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> <9CD3DD5C-16E3-451E-A5C3-80DB2EE2DD4D@steffann.nl> Message-ID: <62D7F5A0-45E4-480E-AB51-567C26753562@de-cix.net> On 04.12.2013, at 13:58, Sander Steffann wrote: > >> We would like to propose to put this functionality in maintenance mode, meaning that it would be provided as it is without a service guarantee. Alternatively, it could be removed altogether. This would free us of a maintenance and support burden, meaning that we can spend these resources on other valuable services. > > I wouldn't mind if it was removed completely. get rid of it! > >> If the membership approves, the RIPE NCC could investigate ways to implement true two-factor authentication for RIPE NCC Access. > > Yes, that would be a much better thing to invest resources in. > +1, mobile phone short message service comes into my mind best regards, Wolfgang -- Wolfgang Tremmel Director Customer Support DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net Phone +49 69 1730902 26 | Mobile +49 171 8600816 | Fax +49 69 4056 2716 | wolfgang.tremmel at de-cix.net Geschaeftsfuehrer Harald A. Summa | Registergericht AG Koeln HRB 51135 From ggiannou at gmail.com Wed Dec 4 14:32:45 2013 From: ggiannou at gmail.com (George Giannousopoulos) Date: Wed, 4 Dec 2013 15:32:45 +0200 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> Message-ID: Hi, Not using it, so I won't miss it. Two factor auth is on the right direction, so I support it. Regards, George On Wed, Dec 4, 2013 at 1:57 PM, Alex Band wrote: > Dear colleagues, > > In our RIPE NCC Access authentication system, we offer the ability to log > in using an X.509 identity certificate instead of a username and password. > This functionality was transferred from the legacy authentication system we > used to have, without evaluating the value of this feature at the time. > > Since then, we have encountered several implementation, user interface and > support issues surrounding this feature, while it is used by less than 0.7% > of the users with a RIPE NCC Access account. Most importantly, the > functionality does not actually offer any additional security. This is > something that is provided by true two-factor authentication. > > We would like to propose to put this functionality in maintenance mode, > meaning that it would be provided as it is without a service guarantee. > Alternatively, it could be removed altogether. This would free us of a > maintenance and support burden, meaning that we can spend these resources > on other valuable services. > > If the membership approves, the RIPE NCC could investigate ways to > implement true two-factor authentication for RIPE NCC Access. > > We look forward to hearing your feedback. > > Kind regards, > > Alex Band > Product Manager > RIPE NCC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stolpe at resilans.se Wed Dec 4 14:45:33 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Wed, 4 Dec 2013 14:45:33 +0100 (CET) Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: <9CD3DD5C-16E3-451E-A5C3-80DB2EE2DD4D@steffann.nl> References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> <9CD3DD5C-16E3-451E-A5C3-80DB2EE2DD4D@steffann.nl> Message-ID: On Wed, 4 Dec 2013, Sander Steffann wrote: > Hi, > >> We would like to propose to put this functionality in maintenance mode, >> meaning that it would be provided as it is without a service guarantee. >> Alternatively, it could be removed altogether. This would free us of a >> maintenance and support burden, meaning that we can spend these >> resources on other valuable services. > > I wouldn't mind if it was removed completely. +1. Do we know if these users rely solely on X.509 or do they have other options? Cheers, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From alexb at ripe.net Wed Dec 4 15:25:02 2013 From: alexb at ripe.net (Alex Band) Date: Wed, 4 Dec 2013 15:25:02 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> <9CD3DD5C-16E3-451E-A5C3-80DB2EE2DD4D@steffann.nl> Message-ID: Hi Daniel, On 4 Dec 2013, at 14:45, Daniel Stolpe wrote: > On Wed, 4 Dec 2013, Sander Steffann wrote: > >> Hi, >> >>> We would like to propose to put this functionality in maintenance mode, meaning that it would be provided as it is without a service guarantee. Alternatively, it could be removed altogether. This would free us of a maintenance and support burden, meaning that we can spend these resources on other valuable services. >> >> I wouldn't mind if it was removed completely. > > +1. > > Do we know if these users rely solely on X.509 or do they have other options? Everybody who has an X.509 certificate for RIPE NCC Access login also has a username and password. You can use either method to log in at all times. Cheers, Alex From pk at DENIC.DE Wed Dec 4 14:54:09 2013 From: pk at DENIC.DE (Peter Koch) Date: Wed, 4 Dec 2013 14:54:09 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> Message-ID: <20131204135409.GC5690@x28.adm.denic.de> On Wed, Dec 04, 2013 at 12:57:26PM +0100, Alex Band wrote: > Most importantly, the functionality does not actually offer any additional security. could you please elaborate on this assessment? > This is something that is provided by true two-factor authentication. Sure, _true_ two-factor authentication. I'd assume that since it's only .7%, the X.509 users (of which I am not one) are or have already been targetted directly? -Peter From rogerj at gmail.com Wed Dec 4 16:10:49 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Wed, 4 Dec 2013 16:10:49 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> <9CD3DD5C-16E3-451E-A5C3-80DB2EE2DD4D@steffann.nl> Message-ID: On Wed, Dec 4, 2013 at 2:45 PM, Daniel Stolpe wrote: > On Wed, 4 Dec 2013, Sander Steffann wrote: > >> Hi, >> >>> We would like to propose to put this functionality in maintenance mode, >>> meaning that it would be provided as it is without a service guarantee. >>> Alternatively, it could be removed altogether. This would free us of a >>> maintenance and support burden, meaning that we can spend these resources on >>> other valuable services. >> >> >> I wouldn't mind if it was removed completely. > > > +1. > > Do we know if these users rely solely on X.509 or do they have other > options? I'm only using x509... or think I somehow can remember my password if I try very hard ... and no I haven't been contacted about this before this mail on the subject. ... and really, I don't care That much if it's true two-factor or not, it's the easy of use that is the important factor for me. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From richih.mailinglist at gmail.com Wed Dec 4 16:24:48 2013 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 4 Dec 2013 16:24:48 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> Message-ID: On Wed, Dec 4, 2013 at 12:57 PM, Alex Band wrote: > We would like to propose to put this functionality in maintenance mode, meaning that it would be provided as it is without a service guarantee. Alternatively, it could be removed altogether. This would free us of a maintenance and support burden, meaning that we can spend these resources on other valuable services. > > If the membership approves, the RIPE NCC could investigate ways to implement true two-factor authentication for RIPE NCC Access. +1 -- Richard From randy at psg.com Wed Dec 4 18:51:48 2013 From: randy at psg.com (Randy Bush) Date: Wed, 04 Dec 2013 18:51:48 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: <62D7F5A0-45E4-480E-AB51-567C26753562@de-cix.net> References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> <9CD3DD5C-16E3-451E-A5C3-80DB2EE2DD4D@steffann.nl> <62D7F5A0-45E4-480E-AB51-567C26753562@de-cix.net> Message-ID: > +1, mobile phone short message service comes into my mind for those of us who are not very local this would be costly randy From job.snijders at hibernianetworks.com Wed Dec 4 19:00:21 2013 From: job.snijders at hibernianetworks.com (Job Snijders) Date: Wed, 4 Dec 2013 19:00:21 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> <9CD3DD5C-16E3-451E-A5C3-80DB2EE2DD4D@steffann.nl> <62D7F5A0-45E4-480E-AB51-567C26753562@de-cix.net> Message-ID: <20131204180021.GS399@Eleanor.local> On Wed, Dec 04, 2013 at 06:51:48PM +0100, Randy Bush wrote: > > +1, mobile phone short message service comes into my mind > > for those of us who are not very local this would be costly Indeed, I'd prefer sometimg like HOTP [1] or TOTP [2]. That way it is cheaper, and I don't depend on a cellphone provider and can use a wide variety of clients on both my cellphone and workstation. Kind regards, Job [1] - http://www.ietf.org/rfc/rfc4226.txt [2] - http://tools.ietf.org/html/rfc6238 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 873 bytes Desc: not available URL: From mansaxel at besserwisser.org Wed Dec 4 21:33:45 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 4 Dec 2013 21:33:45 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> Message-ID: <20131204203344.GJ19980@besserwisser.org> Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access Date: Wed, Dec 04, 2013 at 12:57:26PM +0100 Quoting Alex Band (alexb at ripe.net): > Dear colleagues, > > In our RIPE NCC Access authentication system, we offer the ability to log in using an X.509 identity certificate instead of a username and password. This functionality was transferred from the legacy authentication system we used to have, without evaluating the value of this feature at the time. The only method I use in authenticating towards RIPE NCC systems is PGP signaures on email sent to the autobot. This new-fangled web interface bothers me not. Go ahead and remove X.509, especially if it can be replaced with multifactor auth. As was already mentioned, the phone system is not the most optimal way to do multi-factor. Use HOTP/TOTP, as also was suggested. (But if you ever consider up^W^Wdowngrading from PGP-signed email, I'll raise hell. And behave very badly on the whisky BOF.) /M?ns, not representing a LIR. If it matters. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Quick, sing me the BUDAPEST NATIONAL ANTHEM!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From Piotr.Strzyzewski at polsl.pl Wed Dec 4 21:42:33 2013 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 4 Dec 2013 21:42:33 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> Message-ID: <20131204204233.GA26266@hydra.ck.polsl.pl> On Wed, Dec 04, 2013 at 12:57:26PM +0100, Alex Band wrote: > In our RIPE NCC Access authentication system, we offer the ability to > log in using an X.509 identity certificate instead of a username and > password. This functionality was transferred from the legacy > authentication system we used to have, without evaluating the value of > this feature at the time. > > Since then, we have encountered several implementation, user interface > and support issues surrounding this feature, while it is used by less > than 0.7% of the users with a RIPE NCC Access account. Most > importantly, the functionality does not actually offer any additional > security. This is something that is provided by true two-factor > authentication. > > We would like to propose to put this functionality in maintenance > mode, meaning that it would be provided as it is without a service > guarantee. Alternatively, it could be removed altogether. This would > free us of a maintenance and support burden, meaning that we can spend > these resources on other valuable services. Ok for me. > If the membership approves, the RIPE NCC could investigate ways to > implement true two-factor authentication for RIPE NCC Access. I'm glad to hear that. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From alexb at ripe.net Thu Dec 5 10:11:09 2013 From: alexb at ripe.net (Alex Band) Date: Thu, 5 Dec 2013 10:11:09 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: <20131204135409.GC5690@x28.adm.denic.de> References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> <20131204135409.GC5690@x28.adm.denic.de> Message-ID: <292B845B-E276-4C3C-9C95-D00284B58905@ripe.net> Hi Peter, On 4 Dec 2013, at 14:54, Peter Koch wrote: > On Wed, Dec 04, 2013 at 12:57:26PM +0100, Alex Band wrote: > >> Most importantly, the functionality does not actually offer any additional security. > > could you please elaborate on this assessment? The way this system is implemented, an LIR Portal user with admin rights can issue X.509 certificates to users. However, they cannot be forced to use it. Also, a passphrase is optional, meaning that it?s not really two-factor. The result is ? as some have pointed out in this thread ? that the feature is often used for convenience (i.e. not having to enter a password) rather than offering enhanced security. >> This is something that is provided by true two-factor authentication. > > Sure, _true_ two-factor authentication. > > I'd assume that since it's only .7%, the X.509 users (of which I am not one) are > or have already been targetted directly? No not yet. We first wanted to gauge how the Community feels about the current RIPE NCC Access authentication options and get feedback from both X.509 certificate users and those that don't have them to see if this is functionality we should continue to offer, or whether we should replace it with something better. Depending on the outcome, we would contact all users with a certificate, letting them know what the plan is. I should add that I have already been contacted offline by several users who indicated that they would be fine with seeing it go, especially if it's replaced it with a better solution. Cheers, Alex From jogi at mur.at Thu Dec 5 10:31:10 2013 From: jogi at mur.at (=?UTF-8?B?Sm9naSBIb2Ztw7xsbGVy?=) Date: Thu, 05 Dec 2013 10:31:10 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> Message-ID: <52A047DE.8030301@mur.at> Dear all, Am 2013-12-04 12:57, schrieb Alex Band: > We would like to propose to put this functionality in maintenance > mode, meaning that it would be provided as it is without a service > guarantee. Alternatively, it could be removed altogether. This would > free us of a maintenance and support burden, meaning that we can > spend these resources on other valuable services. Totally agree. As far as I am concerned you could remove this feature altogether. > If the membership approves, the RIPE NCC could investigate ways to > implement true two-factor authentication for RIPE NCC Access. Nice. Regards! -- j.hofm?ller aka Thesix >-<#!&$@@@? http://users.mur.at/thesix/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: OpenPGP digital signature URL: From lutz at iks-jena.de Thu Dec 5 10:42:42 2013 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Thu, 5 Dec 2013 09:42:42 +0000 (UTC) Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access References: <292B845B-E276-4C3C-9C95-D00284B58905@ripe.net> Message-ID: * Alex Band wrote: > The way this system is implemented, an LIR Portal user with admin rights > can issue X.509 certificates to users. However, they cannot be forced to > use it. Also, a passphrase is optional, meaning that it?s not really > two-factor. Whatever you smoke, stop it! Using certificates to authenticate is not and never was a two-factor method. The authentication scheme only proofs the possing of a private key. In which form the key is stored locally is outside of the scheme. You simply can't check this property. From shane at time-travellers.org Fri Dec 6 14:27:40 2013 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 6 Dec 2013 14:27:40 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> Message-ID: <20131206142740.67fa99fe@luna.home.time-travellers.org> Alex, On Wed, 4 Dec 2013 12:57:26 +0100 Alex Band wrote: > Since then, we have encountered several implementation, user > interface and support issues surrounding this feature, while it is > used by less than 0.7% of the users with a RIPE NCC Access account. > Most importantly, the functionality does not actually offer any > additional security. This is something that is provided by true > two-factor authentication. I'm curious how much access is actually done via X.509? That is to say, the 0.7% of users may be the most active ones, meaning that - for example - 25% of all RIPE NCC Access is done via X.509 authentication. (Or indeed it may be the opposite, with 0.1% of authentication done via X.509 certificates.) I think it is worthwhile getting this information before deciding one way or the other. Cheers, -- Shane From davidm at futureinquestion.net Fri Dec 6 18:25:37 2013 From: davidm at futureinquestion.net (David Monosov) Date: Fri, 06 Dec 2013 18:25:37 +0100 Subject: [ncc-services-wg] Authentication Proposal for RIPE NCC Access In-Reply-To: <20131204180021.GS399@Eleanor.local> References: <56A780C5-3EE4-4788-A162-2911B4DF2F07@ripe.net> <9CD3DD5C-16E3-451E-A5C3-80DB2EE2DD4D@steffann.nl> <62D7F5A0-45E4-480E-AB51-567C26753562@de-cix.net> <20131204180021.GS399@Eleanor.local> Message-ID: <52A20891.8010403@futureinquestion.net> Dear ncc-services-wg, Job, I'd like to second this; HOTP and/or TOTP are an excellent choice. Implementations are available for a wide range of mobile platforms. Google Authenticator, for example, supports both on iOS and Android. Many other open and closed source implementations exist for Blackberry, Symbian, and J2ME. Avoid SMS and robo-caller solutions; many places engineers find themselves working from in the real world (data-centers, optical regeneration containers, ...) have no mobile telephony reception. -- Respectfully yours, David Monosov On 12/04/2013 07:00 PM, Job Snijders wrote: > On Wed, Dec 04, 2013 at 06:51:48PM +0100, Randy Bush wrote: >>> +1, mobile phone short message service comes into my mind >> >> for those of us who are not very local this would be costly > > Indeed, I'd prefer sometimg like HOTP [1] or TOTP [2]. That way it is > cheaper, and I don't depend on a cellphone provider and can use a wide > variety of clients on both my cellphone and workstation. > > Kind regards, > > Job > > [1] - http://www.ietf.org/rfc/rfc4226.txt [2] - > http://tools.ietf.org/html/rfc6238 > From alexb at ripe.net Wed Dec 11 10:26:36 2013 From: alexb at ripe.net (Alex Band) Date: Wed, 11 Dec 2013 10:26:36 +0100 Subject: [ncc-services-wg] IPv6 support in the IP Analyser API Message-ID: Dear colleagues, We are incrementally adding support for IPv6 in the IP Analyser toolset. The first piece of functionality that we deployed is the API. You can read more about this feature at: https://www.ripe.net/data-tools/developer-documentation/the-lir-portal-ip-analyser-api Please do not hesitate to contact us if you have any feedback or questions. Kind regards, Alex Band Product Manager RIPE NCC From alexb at ripe.net Wed Dec 11 12:51:11 2013 From: alexb at ripe.net (Alex Band) Date: Wed, 11 Dec 2013 12:51:11 +0100 Subject: [ncc-services-wg] Proposed Implementation for Two-Factor Authentication Message-ID: Dear colleagues, Firstly, I would like to thank all who provided feedback on our authentication proposal for RIPE NCC Access. Many responded to the request for feedback, both publicly and privately, which is very encouraging to see. Based on your input, and the fact that this functionality is very rarely used, we would like to propose the following: 1. Discontinue X.509 identity certificate login from 1 February 2014 - All users who currently have a certificate will be contacted individually - Users will only use their RIPE NCC Access username and password to log in from 1 February 2014 - Note: a lost password can be recovered at https://access.ripe.net/forgot-password 2. Build an implementation for two-factor authentication for RIPE NCC Access, supporting at least: - HMAC-Based One-Time Password (HOTP) - Time-Based One-Time Password (TOTP) We would like to plan the development effort and scheduling before the end of the year and inform you about our roadmap once the project plan is in place. Please let us know if you have any comments or questions. Kind regards, Alex Band Product Manager RIPE NCC From gilles.massen at restena.lu Thu Dec 12 09:01:20 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Thu, 12 Dec 2013 09:01:20 +0100 Subject: [ncc-services-wg] Proposed Implementation for Two-Factor Authentication In-Reply-To: References: Message-ID: <52A96D50.7080600@restena.lu> Hello Alex, On 12/11/2013 12:51 PM, Alex Band wrote: > 2. Build an implementation for two-factor authentication for RIPE NCC > Access, supporting at least: - HMAC-Based One-Time Password (HOTP) - > Time-Based One-Time Password (TOTP) Good idea, I completely agree. I would like to suggest you to investigate also the possiblity of a 2 layer access. For example, at this point I find it quite annoying that the the authentication times out after an hour (?) - especially when playing with low-impact stuff like RIPE Atlas. So requiring an OTP once an hour will be very inconvenient. A possible way: keep username/password for 'simple' services (ideally with a longer timeout), ask additionally for the OTP only when a more sensitive service is accessed (like lirportal). Best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From nick at netability.ie Sun Dec 15 15:31:26 2013 From: nick at netability.ie (Nick Hilliard) Date: Sun, 15 Dec 2013 14:31:26 +0000 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <5273DC04.9090004@netability.ie> References: <5273DC04.9090004@netability.ie> Message-ID: <52ADBD3E.8060309@netability.ie> Hello, It looks like there are only a couple of days before the end of last call on this proposal. There are still several issues which I've brought up throughout the proposal which haven't been answered, even though some of them have been brought up several times on the mailing list. I.e. none of them are new, but none of them has been dealt with either. Excluding my concerns with section 2.6 where I respect the community consensus but still strongly disagree with, these issues include from my email of 2013-11-01: > Serious issues: > Section 3.0 needs to include a term in the contract to state that the > services provided by the RIPE NCC to the legacy resource holder are defined > by RIPE community policy and may be amended from time to time, according to > ripe community policy. [...] > Section 2.4 is redundant. We have a well established precedent under the > terms of 2007-01 for engaging with sponsoring LIRs and this seems to work > well in practice. Creating this policy option merely adds cost to the RIPE > NCC's bottom line for no gain. > > Nits: > > Section 3.0: "a statement that the RIPE NCC is not entitled to deregister > the resources for whatever purpose unless so instructed by the resource > holder". This statement is advisory only and it needs to be made clear > that the sponsoring LIR does not have power to make a legally binding > statement of this form. This actually applies to all four statements in > section 3.0. Nick From ingrid at ripe.net Tue Dec 17 13:14:55 2013 From: ingrid at ripe.net (Ingrid Wijte) Date: Tue, 17 Dec 2013 13:14:55 +0100 Subject: [ncc-services-wg] New RIPE NCC PGP Key Message-ID: <52B0403F.1080801@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, On Monday, 6 January 2014 we will start using our 2014 key to sign e-mails from our ticketing system. The new key has been signed by the old key as described in the key-management policy on our web site: https://www.ripe.net/lir-services/resource-management/contact/pgp-authentication The old key remains valid until Wednesday, 29 January 2014. If you have any questions about this, please contact . Kind Regards, Ingrid Wijte RIPE NCC From bijal.sanghani at euro-ix.net Mon Dec 23 12:29:46 2013 From: bijal.sanghani at euro-ix.net (Bijal Sanghani) Date: Mon, 23 Dec 2013 11:29:46 +0000 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <52ADBD3E.8060309@netability.ie> References: <5273DC04.9090004@netability.ie> <52ADBD3E.8060309@netability.ie> Message-ID: <8DB3DE6D-FC5A-40C8-BBE1-3C1D40FA652F@euro-ix.net> Hi Nick, We've asked the RIPE NCC for some clarity on your comments regarding section 3.0 in the policy proposal, please see Athina's reply below: === There are two elements we would like to clarify with this regards: - Who defines the services provided by the RIPE NCC to legacy resource holders - The inclusion of possible amendments to the NCC services provided to legacy resources as a term of the contract. 1. Who defines the services provided by the RIPE NCC to legacy resource holders The policy proposal (section 1.1) outlines the registration services generally provided by the RIPE NCC: "Registration Services - Services provided by the RIPE NCC in its capacity as a Regional Internet Registry, including the following and such additional services as may be identified from time to time as registry services: - Maintenance of data relating to Internet Resources by the NCC in their Internet Resource registry; - Access to these data for update by or on behalf of the respective holder; - Public availability of registration data; - Certification of these data; and - Delegation of reverse DNS to the registered DNS servers." Furthermore in section 4.0 the proposal clarifies the services available to legacy holders, depending on the type of contractual relationship a legacy holder wants to have with the RIPE NCC. About future RIPE NCC services, whether they will be considered as Registration services available to legacy resources, we believe that this should be a decision to be made not just by the RIPE community but by the RIPE NCC membership as well, because the membership is the one deciding on the RIPE NCC services in general. This view is also reflected in the RIPE NCC?s impact analysis (section A): ?This definition gives a non-exclusive list of services. Other services, both current and future, may also be considered Registration Services. This proposal does not specify the process according to which a service (other than those listed) is identified as Registration Services. Therefore, the RIPE NCC will make this decision after consultation with the membership and RIPE Community.? 2. The inclusion of possible amendments to the NCC services provided to legacy resources as a term of the contract. Section 3.0 of the proposal requires that the contractual agreement includes: - ?the obligation for both parties to comply with this policy and with other RIPE policies which relate to Legacy Internet Resources.? - "specification of the service or services offered in respect of each resource identified". Accordingly: - legacy holders will have to agree that they comply with the RIPE policies anyway - the proposal requires that each legacy holder specifies the services they want for their resources. So not every registration services available to legacy resources will be automatically included to their contract unless they specifically ask for it. Therefore we believe that an addition of a term that includes automatically new services to the contract with legacy holders would contradict the other term of the proposal (about the specification of the services in respect of each resource identified). === I hope this addresses the concerns you raised below. Best regards, Bijal On 15 Dec 2013, at 14:31, Nick Hilliard wrote: > Hello, > > It looks like there are only a couple of days before the end of last call > on this proposal. There are still several issues which I've brought up > throughout the proposal which haven't been answered, even though some of > them have been brought up several times on the mailing list. > > I.e. none of them are new, but none of them has been dealt with either. > > Excluding my concerns with section 2.6 where I respect the community > consensus but still strongly disagree with, these issues include from my > email of 2013-11-01: > >> Serious issues: >> Section 3.0 needs to include a term in the contract to state that the >> services provided by the RIPE NCC to the legacy resource holder are defined >> by RIPE community policy and may be amended from time to time, according to >> ripe community policy. > [...] >> Section 2.4 is redundant. We have a well established precedent under the >> terms of 2007-01 for engaging with sponsoring LIRs and this seems to work >> well in practice. Creating this policy option merely adds cost to the RIPE >> NCC's bottom line for no gain. >> >> Nits: >> >> Section 3.0: "a statement that the RIPE NCC is not entitled to deregister >> the resources for whatever purpose unless so instructed by the resource >> holder". This statement is advisory only and it needs to be made clear >> that the sponsoring LIR does not have power to make a legally binding >> statement of this form. This actually applies to all four statements in >> section 3.0. > > Nick > > From nick at netability.ie Mon Dec 23 13:07:20 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 23 Dec 2013 12:07:20 +0000 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <8DB3DE6D-FC5A-40C8-BBE1-3C1D40FA652F@euro-ix.net> References: <5273DC04.9090004@netability.ie> <52ADBD3E.8060309@netability.ie> <8DB3DE6D-FC5A-40C8-BBE1-3C1D40FA652F@euro-ix.net> Message-ID: <52B82778.9000006@netability.ie> On 23/12/2013 11:29, Bijal Sanghani wrote: > We've asked the RIPE NCC for some clarity on your comments regarding > section 3.0 in the policy proposal, please see Athina's reply below: [...] > ?This definition gives a non-exclusive list of services. Other services, > both current and future, may also be considered Registration Services. > This proposal does not specify the process according to which a service > (other than those listed) is identified as Registration Services. > Therefore, the RIPE NCC will make this decision after consultation with > the membership and RIPE Community.? [...] > Therefore we believe that an addition of a term that includes > automatically new services to the contract with legacy holders would > contradict the other term of the proposal (about the specification of > the services in respect of each resource identified). ok, i see the reasoning behind this and withdraw my concerns about sections 3.0 and 2.4. Nick