From info at arin.net Thu Apr 16 10:40:51 2020 From: info at arin.net (ARIN) Date: Thu, 16 Apr 2020 10:40:51 -0400 Subject: [ARIN-consult] ACSP Consultation: Advanced Security Features for ARIN Online Message-ID: <44186363-6a6c-78e4-fe0b-fe9e68392798@arin.net> Security for ARIN Online accounts as it exists today is described on our website, and includes optional Two-factor Authentication, API keys, and Pretty Good Privacy (PGP) Authentication. More information about these security features can be found at: https://www.arin.net/reference/materials/security/ Over the last several years, we have received multiple ARIN Consultation and Suggestion Process (ACSP) requests and fielded many customer suggestions about ways ARIN might improve security for our online customer accounts. These suggestions include: ?? * 2017.1: Two-factor functionality improvement: https://www.arin.net/participate/community/acsp/suggestions/2017-1/ ?? * 2018.22: Align ARIN password policy with current NIST SP800-63 recommendations: https://www.arin.net/participate/community/acsp/suggestions/2018-22/ ??? * 2019.14: Implement FIDO2 (WebAuthn) for ARIN Online: https://www.arin.net/participate/community/acsp/suggestions/2019-14/ Based on this community input as well as suggestions received through other channels, we are opening a consultation to solicit feedback on a number of potential security improvements that are under consideration. We are specifically interested in your thoughts on a number of specific suggestions, listed below: ?? * ARIN uses challenge questions to verify users who are seeking to restore access to their ARIN Online user account and to complete other actions. It has been suggested that we eliminate the use of challenge questions for customer account verification in favor of other security measures. ?? * Utilizing a personal passcode and/or SMS push codes to a mobile device for password resets and other account actions ?? * Changing password length and entry requirements to better align with NIST SP800-63 recommendations ?? * Requiring the use of Two-factor Authentication (2FA) on all accounts, or allowing Admin Points of Contact (POCs) to control permissions on access to their Organization Records to only allow access from associated POCs who have 2FA on their user accounts The feedback you provide during this consultation will help inform how we move forward with improvements to the security of ARIN Online and customer account access. We also are interested in hearing about other ideas to improve the security of ARIN Online interactions that are not listed above. Thank you for your participation in the ARIN Consultation and Suggestion Process. Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult This consultation will remain open through 5:00 PM ET on Friday, 15 May 2020. Regards, The American Registry for Internet Numbers (ARIN) From mcr at sandelman.ca Thu Apr 16 12:25:40 2020 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 16 Apr 2020 12:25:40 -0400 Subject: [ARIN-consult] ACSP Consultation: Advanced Security Features for ARIN Online In-Reply-To: <44186363-6a6c-78e4-fe0b-fe9e68392798@arin.net> References: <44186363-6a6c-78e4-fe0b-fe9e68392798@arin.net> Message-ID: <11730.1587054340@localhost> ARIN wrote: > These suggestions include: > ?? * 2017.1: Two-factor functionality improvement: > https://www.arin.net/participate/community/acsp/suggestions/2017-1/ I would find remember this browser for 30 useful. I would like to know which browsers have this enabled, and be able to clear it. > ?? * 2018.22: Align ARIN password policy with current NIST SP800-63 > recommendations: > https://www.arin.net/participate/community/acsp/suggestions/2018-22/ YES, YES, YES! PLEASE. > ??? * 2019.14: Implement FIDO2 (WebAuthn) for ARIN Online: > https://www.arin.net/participate/community/acsp/suggestions/2019-14/ This is a very good idea. Please go in this direction. > Based on this community input as well as suggestions received through > other channels, we are opening a consultation to solicit feedback on a > number of potential security improvements that are under consideration. > We are specifically interested in your thoughts on a number of specific > suggestions, listed below: > ?? * ARIN uses challenge questions to verify users who are seeking to > restore access to their ARIN Online user account and to complete other > actions. It has been suggested that we eliminate the use of challenge > questions for customer account verification in favor of other security > measures. I'm unclear what the other security measures would be. > ?? * Utilizing a personal passcode and/or SMS push codes to a mobile > device for password resets and other account actions I'm unclear if this is intended to be one of them? I'm unclear if a personal passcode is something that would be in cleartext in the database, like the idiots at the banks do. > ?? * Requiring the use of Two-factor Authentication (2FA) on all > accounts, or allowing Admin Points of Contact (POCs) to control > permissions on access to their Organization Records to only allow access > from associated POCs who have 2FA on their user accounts I think start with "allowing", even "encouraging" Maybe even "encouraging" by eventually charging a premium if you don't have it. Also, it would be good to mark PoCs that do not have it in a public way, so that one can know that the POC might not be compromised more easily. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From john at comfortconsulting.com Thu Apr 16 12:52:16 2020 From: john at comfortconsulting.com (John Comfort) Date: Thu, 16 Apr 2020 09:52:16 -0700 Subject: [ARIN-consult] ACSP Consultation: Advanced Security Features for ARIN Online In-Reply-To: <11730.1587054340@localhost> References: <44186363-6a6c-78e4-fe0b-fe9e68392798@arin.net> <11730.1587054340@localhost> Message-ID: Implementation of 2FA/MFA should fully support multiple authenticator manufacturers (Google, MS, RSA, DUO, etc.). On Thu, Apr 16, 2020 at 9:25 AM Michael Richardson wrote: > > ARIN wrote: > > These suggestions include: > > > * 2017.1: Two-factor functionality improvement: > > https://www.arin.net/participate/community/acsp/suggestions/2017-1/ > > I would find remember this browser for 30 useful. > I would like to know which browsers have this enabled, and be able to > clear it. > > > * 2018.22: Align ARIN password policy with current NIST SP800-63 > > recommendations: > > https://www.arin.net/participate/community/acsp/suggestions/2018-22/ > > YES, YES, YES! PLEASE. > > > * 2019.14: Implement FIDO2 (WebAuthn) for ARIN Online: > > https://www.arin.net/participate/community/acsp/suggestions/2019-14/ > > This is a very good idea. Please go in this direction. > > > Based on this community input as well as suggestions received through > > other channels, we are opening a consultation to solicit feedback on > a > > number of potential security improvements that are under > consideration. > > We are specifically interested in your thoughts on a number of > specific > > suggestions, listed below: > > > * ARIN uses challenge questions to verify users who are seeking to > > restore access to their ARIN Online user account and to complete > other > > actions. It has been suggested that we eliminate the use of challenge > > questions for customer account verification in favor of other > security > > measures. > > I'm unclear what the other security measures would be. > > > * Utilizing a personal passcode and/or SMS push codes to a mobile > > device for password resets and other account actions > > I'm unclear if this is intended to be one of them? > I'm unclear if a personal passcode is something that would be in cleartext > in > the database, like the idiots at the banks do. > > > * Requiring the use of Two-factor Authentication (2FA) on all > > accounts, or allowing Admin Points of Contact (POCs) to control > > permissions on access to their Organization Records to only allow > access > > from associated POCs who have 2FA on their user accounts > > I think start with "allowing", even "encouraging" > Maybe even "encouraging" by eventually charging a premium if you don't > have it. > Also, it would be good to mark PoCs that do not have it in a public way, so > that one can know that the POC might not be compromised more easily. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN > Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the > ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athompso at athompso.net Thu Apr 16 13:16:28 2020 From: athompso at athompso.net (Adam Thompson) Date: Thu, 16 Apr 2020 12:16:28 -0500 Subject: [ARIN-consult] ACSP Consultation: Advanced Security Features for ARIN Online In-Reply-To: <11730.1587054340@localhost> References: <44186363-6a6c-78e4-fe0b-fe9e68392798@arin.net> <11730.1587054340@localhost> Message-ID: <6b05047f40e6d2872a36b79d38aebb0b@athompso.net> On 2020-04-16 11:25, Michael Richardson wrote: > > ?? * Requiring the use of Two-factor Authentication (2FA) on all > > accounts, or allowing Admin Points of Contact (POCs) to control > > permissions on access to their Organization Records to only allow > access > > from associated POCs who have 2FA on their user accounts > > I think start with "allowing", even "encouraging" > Maybe even "encouraging" by eventually charging a premium if you don't > have it. > Also, it would be good to mark PoCs that do not have it in a public > way, so > that one can know that the POC might not be compromised more easily. I'm OK with "encourage", but not "require". There are still WAY too many orgs (and individuals) for who 2FA is either impossible, or a disaster in the making. Heck, I've managed to permanently lock myself out of nearly every 2FA-enabled account I've ever had, and I'm not clueless - I'm just a klutz with phones, dropping them in ways that manage to circumvent even OtterBox-level protection. Remember: everyone's threat model is different. One of my historically-validated top risks is damaging or losing the 2FA token. -Adam Thompson athompso at athompso.net From richardj at arin.net Thu Apr 16 13:45:42 2020 From: richardj at arin.net (Richard Jimmerson) Date: Thu, 16 Apr 2020 17:45:42 +0000 Subject: [ARIN-consult] ACSP Consultation: Advanced Security Features for ARIN Online In-Reply-To: References: <44186363-6a6c-78e4-fe0b-fe9e68392798@arin.net> <11730.1587054340@localhost> Message-ID: <4705E646-EDED-43E7-95BF-B4BADA3FD7E1@arin.net> Hello John and ARIN Consult ? Thank you for participating in this security consultation. Implementation of 2FA/MFA should fully support multiple authenticator manufacturers (Google, MS, RSA, DUO, etc.). I am posting here to note ARIN?s current 2FA implementation to aid in the discussion. We currently support third-party mobile authenticators that meet the requirements of RFC 6238. More details about our current implementation are available here: https://www.arin.net/reference/materials/security/twofactor/ We are open to feedback on this topic, in addition to the other security feature considerations as part of this consultation. Best regards, Richard Jimmerson COO at ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.buhrmaster at gmail.com Thu Apr 16 14:05:06 2020 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 16 Apr 2020 18:05:06 +0000 Subject: [ARIN-consult] ACSP Consultation: Advanced Security Features for ARIN Online In-Reply-To: <44186363-6a6c-78e4-fe0b-fe9e68392798@arin.net> References: <44186363-6a6c-78e4-fe0b-fe9e68392798@arin.net> Message-ID: On Thu, Apr 16, 2020 at 2:42 PM ARIN wrote: > Please provide comments to arin-consult at arin.net. > These suggestions include: ...... I would prefer if the FIDO2/WebauthN option be included in the available options (it is a W3C recommendation, and seems to be broadly accepted by most of the major players and implemented by most of the major browser/platform vendors). Personally, I look forward to the day I can just use a security key, or an on-device authenticator, rather needing a password manager (even if that day may be beyond my useful service life). > Requiring the use of Two-factor Authentication (2FA) on all > accounts, or allowing Admin Points of Contact (POCs) to control > permissions on access to their Organization Records to only allow access > from associated POCs who have 2FA on their user accounts An org's admin should have the discretion to determine their orgs specific requirements. There is no one size that fits all. That might include the ability for a poc associated with the account to change a password via SMS, although if a poc is shared between orgs I can see some interesting cases and opportunities. From Matthew.Wilder at telus.com Thu Apr 16 14:39:17 2020 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Thu, 16 Apr 2020 18:39:17 +0000 Subject: [ARIN-consult] ACSP Consultation: Advanced Security Features for ARIN Online In-Reply-To: References: <44186363-6a6c-78e4-fe0b-fe9e68392798@arin.net> Message-ID: <1ea0003a6a0d4a60a6b4b2f3f9cc38c6@BTWP000343.corp.ads> On Thu, Apr 16, 2020 at 11:31 PM Gary Buhrmaster wrote: > > Requiring the use of Two-factor Authentication (2FA) on all accounts, > > or allowing Admin Points of Contact (POCs) to control permissions on > > access to their Organization Records to only allow access from > > associated POCs who have 2FA on their user accounts > An org's admin should have the discretion to determine their orgs specific > requirements. There is no one size that fits all. That might include the > ability for a poc associated with the account to change a password via > SMS, although if a poc is shared between orgs I can see some interesting > cases and opportunities. As the requestor of this feature, your description is more precisely what I intended than what I managed to say. The idea is that some organizations with multiple POCs may want to have some means of ensuring that all POCs associated with their organization meet a required security level. This was not meant to be prescriptive across the board, but to present an option at an OrgID level. To be extra extra clear, I am in full agreement with Adam's opinion: "I'm OK with "encourage", but not "require". That's the idea I was really shooting for. Cheers! Matthew Wilder _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From bill at herrin.us Thu Apr 16 15:13:35 2020 From: bill at herrin.us (William Herrin) Date: Thu, 16 Apr 2020 12:13:35 -0700 Subject: [ARIN-consult] ACSP Consultation: Advanced Security Features for ARIN Online In-Reply-To: <44186363-6a6c-78e4-fe0b-fe9e68392798@arin.net> References: <44186363-6a6c-78e4-fe0b-fe9e68392798@arin.net> Message-ID: On Thu, Apr 16, 2020 at 7:40 AM ARIN wrote: > Based on this community input as well as suggestions received through > other channels, we are opening a consultation to solicit feedback on a > number of potential security improvements that are under consideration. > We are specifically interested in your thoughts on a number of specific > suggestions, listed below: > > * ARIN uses challenge questions to verify users who are seeking to > restore access to their ARIN Online user account and to complete other > actions. It has been suggested that we eliminate the use of challenge > questions for customer account verification in favor of other security > measures. YES. PLEASE. Challenge questions were a crap idea in the first place. Lots of folks did it and still do it, but it's a crap idea all the same. NIST SP 800-63 rev 3 does a fine job explaining why it's a crap idea so I won't beat a dead horse. > * Utilizing a personal passcode and/or SMS push codes to a mobile > device for password resets and other account actions Do folks need to urgently reset their password? Fedex has an interesting process where they send you a code via postal mail. It takes a couple days but it's not so readily exploitable as email/sms. I read a newspaper story recently where some guy lost millions in bitcoin when someone took over his phone number. The phone company he sued made it crystal clear in legal filings that they don't promise or consider their management practices for customer accounts to be secure enough to be used for single-factor authentication, such as for a password reset. > * Changing password length and entry requirements to better align > with NIST SP800-63 recommendations YES. PLEASE. 800-63 rev 3 was a sudden outbreak of common sense when it came to password selection. > * Requiring the use of Two-factor Authentication (2FA) on all > accounts, or allowing Admin Points of Contact (POCs) to control > permissions on access to their Organization Records to only allow access > from associated POCs who have 2FA on their user accounts NO. Default to this, yes. Encourage it. But ultimately let the registrant determine the appropriate level of security for their account. Many of your registrants go years between contacts more substantial than paying the annual fee. What will you use for the "what-you-have" factor that you can reasonably expect to be valid years from now? SMS push when not everyone keeps the same cell phone number that long? An SSL client cert that routinely expires? > * 2018.22: Align ARIN password policy with current NIST SP800-63 > recommendations: > https://www.arin.net/participate/community/acsp/suggestions/2018-22/ Rev 3 specifically. Rev 2 was trash. Within reason, yes. A registrant who wants to secure his account to the rev3 standard should be able to do so. Someone shouldn't be able to come in the side and reset his auth in a non-compatible way. > * 2019.14: Implement FIDO2 (WebAuthn) for ARIN Online: > https://www.arin.net/participate/community/acsp/suggestions/2019-14/ This is flavor-of-the-month. There will be something better next year. And the year after that. Is it a good one? Enough better than what you're doing now to be worthwhile? I don't know. But it's very flavor-of-the-month. Regards, Bil Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From rs at seastrom.com Thu Apr 16 17:46:29 2020 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 16 Apr 2020 17:46:29 -0400 Subject: [ARIN-consult] ACSP Consultation: Advanced Security Features for ARIN Online In-Reply-To: References: <44186363-6a6c-78e4-fe0b-fe9e68392798@arin.net> Message-ID: > On Apr 16, 2020, at 3:13 PM, William Herrin wrote: > >> * 2019.14: Implement FIDO2 (WebAuthn) for ARIN Online: >> https://www.arin.net/participate/community/acsp/suggestions/2019-14/ > > This is flavor-of-the-month. There will be something better next year. > And the year after that. Is it a good one? Enough better than what > you're doing now to be worthwhile? I don't know. But it's very > flavor-of-the-month. Respectfully disagree on all counts. FIDO has been around since 2013. The reason it feels like ?flavor of the month? to you is the recent mindset tipping point which has resulted in more or less universal browser support (made it into Safari including mobile with iOS 13.3; Chrome and Firefox have supported it for much longer) and OpenSSH 8.2. At least two of the big public clouds support it. login.gov has been supporting it since September 2018 - https://fidoalliance.org/webinar-deployment-case-study-login-gov-fido2/ As was noted elsewhere in this thread, ARIN already supports RFC 6238 (TOTP) MFA. which is coming up 9 years since its informational RFC was published. Not to take away from TOTP, which is far better than no second factor, but there are multiple technological advantages to FIDO2 by comparison, chief among them being hard token reusability across multiple services. Expanding the supported list of supported MFA schemes to include FIDO2, and sunsetting the creation of new SMS-as-second-factor accounts (while continuing to support it and perhaps laying in an EOL date) is precisely the kind of evolution-to-suit-the-times thing that we should do periodically. -r -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Thu Apr 16 18:47:18 2020 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 16 Apr 2020 18:47:18 -0400 Subject: [ARIN-consult] ACSP Consultation: Advanced Security Features for ARIN Online In-Reply-To: References: <44186363-6a6c-78e4-fe0b-fe9e68392798@arin.net> Message-ID: <7704.1587077238@localhost> William Herrin wrote: >> * Utilizing a personal passcode and/or SMS push codes to a mobile >> device for password resets and other account actions > Do folks need to urgently reset their password? Fedex has an > interesting process where they send you a code via postal mail. It > takes a couple days but it's not so readily exploitable as email/sms. I think that this is something that should be investigated. I have github and google backup codes printed and in a paper file. I have no such thing for ARIN, and last time my phone bought it, I discovered I had to password reset. I now have realized that I can *print* the QR code used to initialize the phone app and keep that too. -------------- next part -------------- -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: