Requiring multiple auth mechanisms

[Jefferson Ogata]

I looked around for a while, but couldn't find any code for requiring multiple 
authentication mechanisms in openssh. So I wrote an implemention.

I thought at first I should change the PasswordAuthentication, 
PubkeyAuthentication, etc. keywords to allow no/yes/required. But there's some 
funky stuff in auth2.c with respect to keyboard interactive auth that would make 
this kind of gnarly, semantics-wise.

I also thought about providing a new keyword to specify a list of required 
authentication mechanisms. But then you have to make sure those mechanisms are 
also enabled, and it's easy to write conflicting configurations. In addition, if 
a list of required auth mechs is given, then enabling mechanisms that are not 
required is pointless, because they won't be sufficient.

So my final decision, for the sake of simplicity, was to add a 
"NumRequiredAuthMethods" keyword, which defaults to 1. If you set it to 2, the 
client must pass at least two of the enabled auth methods. I'm using the term 
"methods" here because I'm only counting general auth methods as defined in 
auth2.c's "authmethods" array, namely publickey, password, keyboard-interactive, 
and hostbased. So there may be multiple types of keyboard-interactive auth, but 
keyboard-interactive only counts as a single method.

So, for example, if you have PasswordAuthentication and PubkeyAuthentication 
enabled, and set NumRequiredAuthMethods to 2, you will have to pass both types. 
But PAMAuthenticationViaKbdInt and ChallengeResponseAuthentication are the same 
authentication method (keyboard-interactive), so if you want to require 2 
classes, you'll have to have at least one of the other methods enabled as well.

I don't know much about some of the supported authentication types, particularly 
pam, so I'm not totally sure my approach makes sense for everyone's needs. My 
particular need was to require both public key and S/KEY factors so that 
one-time passwords can be combined with a strong electronic authenticator. I 
don't trust my users not to end up trojaned with a keylogger, so I need OTP, but 
I also want a public key in case someone loses his S/KEY cheat sheet.

The attached patch is designed for Red Hat's openssh-3.1p1-14 SRPM (add as 
Patch14, use -p1 on patch line in %prep). It should work against openssh-3.8 
with slight tweaks (authmethods changed in auth2.c). If people need a patch 
against 3.8, I can build it; just ask.

I would really appreciate it if anyone with interest could vet this for stupid 
mistakes.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-3.1p1-multipleauth.patch
Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040407/64a39780/attachment.ksh