Please put FIDO2 next after Hypervisor support
https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins

Richard Maher wrote:

> Please put FIDO2 next after Hypervisor support
> https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins

bluetooth support on a multi-user O/S ?

On Friday, May 6, 2022 at 1:30:41 AM UTC-4, Andy Burns wrote:
> Richard Maher wrote:
>
> > Please put FIDO2 next after Hypervisor support
> > https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins
> bluetooth support on a multi-user O/S ?

Since a dog only has 1 head, that make FIDO a third as good as Kerberos?

On 5/6/22 01:30, Andy Burns wrote:
> Richard Maher wrote:
>
>> Please put FIDO2 next after Hypervisor support
>> https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins
>
>
> bluetooth support on a multi-user O/S ?

What does multi-user have to do with it?

bill

On 2022-05-06, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 5/6/22 01:30, Andy Burns wrote:
>> Richard Maher wrote:
>>
>>> Please put FIDO2 next after Hypervisor support
>>> https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins
>>
>>
>> bluetooth support on a multi-user O/S ?

Well VMS does have (somewhat limited) USB support. :-)

>
> What does multi-user have to do with it?
>

More that multiple people use a VMS server that is not physically
close to them and uses a variety of means to connect to it, only
some of which could be used with bluetooth based authentication.

The Register has an article about this (make sure you read the user comments):

https://www.theregister.com/2022/05/05/microsoft-apple-google-fido/

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Thursday, May 5, 2022 at 11:15:46 PM UTC-4, Richard Maher wrote:
> Please put FIDO2 next after Hypervisor support
> https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins
Personally I prefer Steve Gibson's SQRL solution which is also passwordless. But I do realize that the momentum of FIDO and the backing of Apple, Google, and Microsoft will put SQRL into the dustbin along with Betamax tapes.

https://www.grc.com/sqrl/sqrl.htm

On 2022-05-06 05:30:36 +0000, Andy Burns said:

> Richard Maher wrote:
>
>> Please put FIDO2 next after Hypervisor support
>> https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins
>>
>
> bluetooth support on a multi-user O/S ?

Maybe "Bluetooth on a server-focused operating system?" is a better
statement of your concern here?

Why? macOS, Linux, and various other multi-user systems all offer
Bluetooth connectivity.

The following reply mixes both two-factor and password-less, which are
related in various ways and do require a communications path with the
client, but are different.

As for FIDO, US DoD CAC support, or otherwise, and for two-factor
authentication and alternatives-to-passwords for logins, OpenVMS
two-factor authentication support is an add-on, and Kerberos
single-sign-on has long been a rarely-used option.

Kerberized telnet has been around for a while, IIRC. Yes, kerberized
telnet. Yes, that's hilarious to at least some of us. Moving on...

In general, it's quite possible to do two-factor remotely from/for a
server, but this does best require support from the client device for
ease of use. Or requires adding prompts. Entirely through the password
input field, if you're so inclined and can't otherwise get a third
input prompt. But getting OpenVMS servers to support FIDO password-less
is going to absolutely require server modifications as well as a client
with the necessary support.

For two-factor, iOS and iPadOS include an integrated authenticator, and
add-on authenticators are available for most (all?) common mobile
devices. Various platforms integrate also ssh connections with
mobile-device authenticators, though not usually via Bluetooth.

For ssh connections, OpenSSH 8.2p1 and later does have support for
FIDO2, and OpenSSH 8.8 is ported to OpenVMS x86-64. Whether that FIDO2
support has been integrated with OpenVMS, and is enough to meet the
OP's rather under-specified FIDO requirements? For those using ssh
connections already, certificates can provide that now, without
requiring FIDO. Haven't checked to see if the OpenVMS OpenSSH server
can pull public certificates from LDAP, but some ssh setups can—though
given LDAP integration is weak on OpenVMS, probably not.

--
Pure Personal Opinion | HoffmanLabs LLC

Bill Gunshannon wrote:

> Andy Burns wrote:
>
>> bluetooth support on a multi-user O/S ?
>
> What does multi-user have to do with it?

how does it know which user is controlling the radio, which security token
belongs to which user, etc?

but who runs a web browser on VMS now? I suspect there's only one person here
that does

Stephen Hoffman wrote:

> Maybe "Bluetooth on a server-focused operating system?" is a better statement of
> your concern here?
>
> Why? macOS, Linux, and various other multi-user systems all offer Bluetooth
> connectivity.

But there's an expectation that the primary/sole console "owns" the bluetooth
devices ...

On 6/05/2022 1:30 pm, Andy Burns wrote:
> Richard Maher wrote:
>
>> Please put FIDO2 next after Hypervisor support
>> https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins
>>
>
>
> bluetooth support on a multi-user O/S ?

FFS what a bunch of arseholes :-(

Bluetooth is on the "client" the "device" part of "multi-device". Your
VMS code needs to be able to contact the authenticator of the public key
who will ask the client device for something like an attestation. Via
CTAP protocol.

See
https://stackoverflow.com/questions/66624283/can-i-use-phone-as-webauthn-security-key-with-windows-10-sign-in-options
for background.

This link https://developer.apple.com/videos/play/wwdc2021/10106/ is
<30mins long, starts slow but quickly hits the spot. At 15:15 I really
started to get my jollies with the new stuff and went to bed. I'm about
to watch the rest now but guess that if your phone is bluetooth away
from your client device then all you have to do his give your
fingerprint etc on phone and it's done!!! Biometric info or private key
*NEVER* leaves the phone!!!!!!!!!!!!

VMS will *never* be a client device!

To be clear, I want to convert my code to VMS COBOL calling language
agnostic RSA, JWT, et al RTL routines that are probably there in JAVA now: -
// GET: api/<fido>
[HttpGet]
public string GetKey()
{
SigningCredentials credentials = new
SigningCredentials(_securityKey, SecurityAlgorithms.HmacSha256);
JwtSecurityToken token = new JwtSecurityToken(_domain,
_domain, expires: DateTime.Now.AddSeconds(120), signingCredentials:
credentials);

return "{\"Token\": \"" + _jsth.WriteToken(token) + "\"}";
}

[HttpPost]
[System.Diagnostics.CodeAnalysis.SuppressMessage("Interoperability",
"CA1416:Validate platform compatibility", Justification = "DSA Works on
Windows only which is fine.")]
public string VerifyAssertion([FromBody] Assertion assertion)
{
if (assertion == null || assertion.Id == null ||
assertion.AuthenticatorData == null || assertion.ClientDataJSON == null
|| assertion.Signature == null)
{
// assertion.UserHandle is null for Samsung phone

return FAIL_STATUS;
}

if (assertion.Id != tempDB.Id)
{
return FAIL_STATUS;
}

if (!ValidateClient(assertion.ClientDataJSON, "webauthn.get"))
{
return FAIL_STATUS;
}

byte[] authData =
Convert.FromBase64String(assertion.AuthenticatorData);
var creds = ValidateAuthData(authData);
if (creds == null)
{
return FAIL_STATUS;
}

creds.Id = tempDB.Id;
creds.PublicKeyJwk = tempDB.PublicKeyJwk;

byte[] hashValClientData;
try
{
hashValClientData =
_hash.ComputeHash(Encoding.Latin1.GetBytes(assertion.ClientDataJSON));
}
catch (Exception e)
{
return FAIL_STATUS;
}

PublicKey pubKey;
try
{
pubKey =
JsonConvert.DeserializeObject<PublicKey>(creds.PublicKeyJwk);
}
catch (Exception ex)
{
return FAIL_STATUS;
}

byte[] data = new byte[authData.Length +
hashValClientData.Length];
Buffer.BlockCopy(authData, 0, data, 0, authData.Length);
Buffer.BlockCopy(hashValClientData, 0, data,
authData.Length, hashValClientData.Length);

byte[] sig = Convert.FromBase64String(assertion.Signature);

if (pubKey.kty == "EC")
{
byte[] ECDsaSig = convertFromASN1(sig);

var point = new ECPoint
{
X = Convert.FromBase64String(pubKey.x),
Y = Convert.FromBase64String(pubKey.y),
};

var ecparams = new ECParameters
{
Q = point,
Curve = ECCurve.NamedCurves.nistP256
};
try
{
using (ECDsa dsa = ECDsa.Create(ecparams))
{
if (dsa.VerifyData(data, ECDsaSig,
HashAlgorithmName.SHA256))
{
Console.WriteLine("The signature is valid.");
}
else
{
Console.WriteLine("The signature is not
valid.");
return FAIL_STATUS;
}
}
}
catch (Exception e)
{
return FAIL_STATUS;
}
}
else
{
RSA rsa = RSA.Create();
rsa.ImportParameters(
new RSAParameters()
{
Modulus = Convert.FromBase64String(pubKey.n),
Exponent = Convert.FromBase64String(pubKey.e),
}
);

if (rsa.VerifyData(data, sig, HashAlgorithmName.SHA256,
RSASignaturePadding.Pkcs1))
{
Console.WriteLine("The signature is valid.");
}
else
{
Console.WriteLine("The signature is not valid.");
return FAIL_STATUS;
}
}

if (creds.SignCount < tempDB.SignCount)
{
Console.WriteLine("SignCount = " + creds.SignCount + "
expected > " + tempDB.SignCount);
return FAIL_STATUS;
}

tempDB.SignCount = creds.SignCount;
return PASS_STATUS;
}

On 7/05/2022 10:08 am, Richard Maher wrote:
> On 6/05/2022 1:30 pm, Andy Burns wrote:
>> Richard Maher wrote:
>>
>>> Please put FIDO2 next after Hypervisor support
>>> https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins
>>>
>>>
>>
>>
>> bluetooth support on a multi-user O/S ?
>
> FFS what a bunch of arseholes :-(
>
> Bluetooth is on the "client" the "device" part of "multi-device". Your
> VMS code needs to be able to contact the authenticator of the public key
> who will ask the client device for something like an attestation. Via
> CTAP protocol.
>
> See
> https://stackoverflow.com/questions/66624283/can-i-use-phone-as-webauthn-security-key-with-windows-10-sign-in-options
> for background.
>
> This link https://developer.apple.com/videos/play/wwdc2021/10106/ is
> <30mins long, starts slow but quickly hits the spot. At 15:15 I really
> started to get my jollies with the new stuff and went to bed. I'm about
> to watch the rest now but guess that if your phone is bluetooth away
> from your client device then all you have to do his give your
> fingerprint etc on phone and it's done!!! Biometric info or private key
> *NEVER* leaves the phone!!!!!!!!!!!!
>

Ok it looks like if you use Apple iCloud KeyChain the keys are "synched"
with the cloud. I'd rather have to register new devices if I lost them all.

And, as usual, looks like Apple won't recognize non-Apple devices :-(

On 5/6/2022 10:08 PM, Richard Maher wrote:

> VMS will *never* be a client device!

Why not? I can imagine it.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/6/22 23:42, Dave Froble wrote:
> On 5/6/2022 10:08 PM, Richard Maher wrote:
>
>> VMS will *never* be a client device!
>
> Why not?  I can imagine it.
>

I guess it depends on your definition of "client device".
Some of us run VMS not as a server. Does that make it a
"client device"? I am sure there are production environments
where VMS is used not as a server but for other tasks. Would
that make them "client devices"? Or does it have to be in my
smart phone to be "client device"?

bill

On 2022-05-07 02:29:47 +0000, Richard Maher said:

> Ok it looks like if you use Apple iCloud KeyChain the keys are
> "synched" with the cloud. I'd rather have to register new devices if I
> lost them all.

iCloud Keychain requires an existing iCloud Keychain client be logged
into the same Apple ID, and to further explicitly "approve" a
newly-added client attempting to access iCloud Keychain, yes.

https://support.apple.com/en-us/HT204085

OpenSSH supports FIDO, though whether the OpenVMS port also supports
that? The other spot where this'd probably be involved (within Maher
World) is support (hypothetically) added within the web server or
application server.

> And, as usual, looks like Apple won't recognize non-Apple devices :-(

Some few servcies (e.g. mail) aren't, but many of the various iCloud
services are tied to Apple devices, and iCloud Keychain is entirely
tied to Apple devices, yes.

Keychain is a store of trusted notes, passwords, private keys, and
related, and operates locally on Apple devices, and can be shared via
iCloud.

OpenVMS has no direct analog to Keychain, using SYSUAF, passwords
stored in various places (e.g. in cleartext in the DECnet database),
LDAP, and certificates either stored in various directories or
app-embedded.

iCloud Keychain is an entirely different approach, but providing some
general similarities to LDAP password authentication for hosts bound to
a directory server.

For those interested in general information on security on Apple
platforms, and for the jargon that Apple uses:

online reading: https://support.apple.com/guide/security/welcome/web
offline reading:
https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/apple-platform-security-guide.pdf

For those that would like to get out of dealing with website account
management entirely, and prior to FIDO or some other approach:

https://developer.apple.com/sign-in-with-apple/

It'll be interesting to see how FIDO, Sign in with Apple, and other
services effect existing sites using Microsoft Active Directory and
Microsoft Azure and CAC for user authentication. Though for those
OpenVMS folks still using SYSUAF not having added LDAP or two-factor or
such, prolly not much.

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/7/2022 8:58 AM, Bill Gunshannon wrote:
> On 5/6/22 23:42, Dave Froble wrote:
>> On 5/6/2022 10:08 PM, Richard Maher wrote:
>>
>>> VMS will *never* be a client device!
>>
>> Why not?  I can imagine it.
>
> I guess it depends on your definition of "client device".
> Some of us run VMS not as a server.  Does that make it a
> "client device"?  I am sure there are production environments
> where VMS is used not as a server but for other tasks. Would
> that make them "client devices"?  Or does it have to be in my
> smart phone to be "client device"?

One question is the definition. I believe most have some intuitive
understanding though not necessarily precise definition of what
a server is and what a "client" (desktop, tablet, phone) is and
what embedded is.

Another question is whether we are talking about every
VMS system in existence, all commercial in production
systems or just where the vast majority of VMS business is
(now and future). I am sure there are places where VMS are
used in ways that would surprise me. But I am also sure
that 95++% of VSI business is for very traditional
server usage.

Arne

On 5/6/2022 10:08 PM, Richard Maher wrote:
> To be clear, I want to convert my code to VMS COBOL calling language
> agnostic RSA, JWT, et al RTL routines that are probably there in JAVA
> now: -
>        // GET: api/<fido>
>         [HttpGet]
>         public string GetKey()
>         {
>             SigningCredentials credentials = new
> SigningCredentials(_securityKey, SecurityAlgorithms.HmacSha256);
>             JwtSecurityToken token = new JwtSecurityToken(_domain,
> _domain, expires: DateTime.Now.AddSeconds(120), signingCredentials:
> credentials);
>
>             return "{\"Token\": \"" + _jsth.WriteToken(token) + "\"}";
>         }
>
>         [HttpPost]
>
> [System.Diagnostics.CodeAnalysis.SuppressMessage("Interoperability",
> "CA1416:Validate platform compatibility", Justification = "DSA Works on
> Windows only which is fine.")]
>         public string VerifyAssertion([FromBody] Assertion assertion)
>         {
>             if (assertion == null || assertion.Id == null ||
> assertion.AuthenticatorData == null || assertion.ClientDataJSON == null
> || assertion.Signature == null)
>             {
>                 // assertion.UserHandle is null for Samsung phone
>
>                 return FAIL_STATUS;
>             }
>
>             if (assertion.Id != tempDB.Id)
>             {
>                 return FAIL_STATUS;
>             }
>
>             if (!ValidateClient(assertion.ClientDataJSON, "webauthn.get"))
>             {
>                 return FAIL_STATUS;
>             }
>
>             byte[] authData =
> Convert.FromBase64String(assertion.AuthenticatorData);
>             var creds = ValidateAuthData(authData);
>             if (creds == null)
>             {
>                 return FAIL_STATUS;
>             }
>
>             creds.Id = tempDB.Id;
>             creds.PublicKeyJwk = tempDB.PublicKeyJwk;
>
>             byte[] hashValClientData;
>             try
>             {
>                 hashValClientData =
> _hash.ComputeHash(Encoding.Latin1.GetBytes(assertion.ClientDataJSON));
>             }
>             catch (Exception e)
>             {
>                 return FAIL_STATUS;
>             }
>
>             PublicKey pubKey;
>             try
>             {
>                 pubKey =
> JsonConvert.DeserializeObject<PublicKey>(creds.PublicKeyJwk);
>             }
>             catch (Exception ex)
>             {
>                 return FAIL_STATUS;
>             }
>
>             byte[] data = new byte[authData.Length +
> hashValClientData.Length];
>             Buffer.BlockCopy(authData, 0, data, 0, authData.Length);
>             Buffer.BlockCopy(hashValClientData, 0, data,
> authData.Length, hashValClientData.Length);
>
>             byte[] sig = Convert.FromBase64String(assertion.Signature);
>
>             if (pubKey.kty == "EC")
>             {
>                 byte[] ECDsaSig = convertFromASN1(sig);
>
>                 var point = new ECPoint
>                 {
>                     X = Convert.FromBase64String(pubKey.x),
>                     Y = Convert.FromBase64String(pubKey.y),
>                 };
>
>                 var ecparams = new ECParameters
>                 {
>                     Q = point,
>                     Curve = ECCurve.NamedCurves.nistP256
>                 };
>                 try
>                 {
>                     using (ECDsa dsa = ECDsa.Create(ecparams))
>                     {
>                         if (dsa.VerifyData(data, ECDsaSig,
> HashAlgorithmName.SHA256))
>                         {
>                             Console.WriteLine("The signature is valid.");
>                         }
>                         else
>                         {
>                             Console.WriteLine("The signature is not
> valid.");
>                             return FAIL_STATUS;
>                         }
>                     }
>                 }
>                 catch (Exception e)
>                 {
>                     return FAIL_STATUS;
>                 }
>             }
>             else
>             {
>                 RSA rsa = RSA.Create();
>                 rsa.ImportParameters(
>                     new RSAParameters()
>                     {
>                         Modulus = Convert.FromBase64String(pubKey.n),
>                         Exponent = Convert.FromBase64String(pubKey.e),
>                     }
>                 );
>
>                 if (rsa.VerifyData(data, sig, HashAlgorithmName.SHA256,
> RSASignaturePadding.Pkcs1))
>                 {
>                     Console.WriteLine("The signature is valid.");
>                 }
>                 else
>                 {
>                     Console.WriteLine("The signature is not valid.");
>                     return FAIL_STATUS;
>                 }
>             }
>
>             if (creds.SignCount < tempDB.SignCount)
>             {
>                 Console.WriteLine("SignCount = " + creds.SignCount + "
> expected > " + tempDB.SignCount);
>                 return FAIL_STATUS;
>             }
>
>             tempDB.SignCount = creds.SignCount;
>             return PASS_STATUS;
>         }

I am pretty sure that could be converted to Java running on VMS I64
(and in the future VMS x84-64). VMS Alpha Java 5 may be too old.

Java has the basic encryption stuff. Java has the annotation based
RESTful web services either JAX-RS based (like Jersey or RestEasy)
or Spring MVC. Java got the JWT libs.

I don't think Cobol is the right language to do this in.

Arne