[Trimmed To/Cc as everyone involved in the discussion is on security- discuss]
>> Under such circumstances the user would, currently, need to fall back >> on using traditional passwords (or third party tools would need to be >> used). The risk of this password being exposed is quite small, as the >> user would probably be using Secure Shell or, in the future, an ad- >> hoc IPSec encrypted connection. > > The protocol that the user is using has nothing to do with the risk > that > the user's password will be exposed as the user is necessarily > typing it > into an untrusted system; long before the password reaches the wire > with > confidentiality protection it has been exposed to the untrusted > host in > the clear. > That should have read "The risk of this password being exposed /on the wire/ is quite small(...)" > Note too RFC4226 (HOTP: An HMAC-Based One-Time Password Algorithm). > > Interestingly enough RFC4226 does not reference RFC2289 and does not > discuss applicability of one vs. the other. Bummer. How did that > happen? At first glance this seems to describe just an alternative algorithm; it doesn't require a fundamentally different interaction (it seems it could be implemented relatively simply later as an extra mechanism besides MD4, MD5 and SHA1 within the same module, though implementing the bidirectional authentication support that's described in the RFC may require a fair bit of extra work (but it probably could be done as an OTP extension, cf. RFC2443)). > Adding support for a distributed OTP shouldn't be hard (unless we're > talking about full RADIUS or DIAMETER support). In that case I'd > expect > these module arguments like sequence=m to be stored at the server. Well, if we had an easy way of submitting these couple bits of information to a (name) server quickly this would be trivial to make work for multiple systems where the extra features (and complexity) of RADIUS/DIAMETER are unneeded... the only change in what information we store would probably be the locking timestamp, so that it includes a host identifier. > ignore_unknown should go away when I putback PSARC 2005/275 (still > working on the SMC bits). But even then I can see ignore_unknown > being > useful nonetheless, so we may want to have a deeper discussion of > ignore_unknown options to PAM modules. The advantage of ignore_unknown on a module like this is that it requires only a change in one place: as soon as the user account exists in the otp-table the otp module "takes effect", while with PSARC 2005/275 the user_attr/prof_attr for the user needs to be modified in addition to the creation of the otp-table entry. So I think that in general for circumstances where the change between one authentication approach and another is trivially changed ignore_unknown remains useful. > The OTP table sounds like a candidate for a SQLite DB :) Seems to be; I wasn't familiar with SQLite, but seen the need to update the table on each authentication (and depending on how we handle lockouts, on each authentication attempt) this may turn out to be a good datastore. > You may want an option to disable token changing (so that you may > allow > token changing locally only and not remotely, say). Mmmm. I guess the option could be used to prevent users from entering hash+seed+sequence that they may have generated on an untrusted system (thereby assuming that they'd do it properly when doing so locally). Preventing exposing the password over the wire is handled by the logic in the pam_sm_chauthtok bit, below. >> Can we and should we lock the account (completely) on the otp level? >> What about the system level? > > I say no, but our customers will say yes, and the customer is always > right... Well, there should be a way of dealing with failed authentication attempts, and with the way the stack works I don't see an alternative to doing it in the OTP module -- without modifying the pam framework. (Such a modification would allow either a module at the bottom of the stack to register as the record-keeper and "locking agent" for authentication failures, or that libpam keeps track of and acts on such failures itself). >> pam_sm_chauthtok >> ---------------- >> >> if PAM_AUTHTOK != NULL >> create hash based on PAM_AUTHTOK with random seed and >> default sequence number >> else >> conversation ask if user wants to set a new hash >> if true >> conversation for hash, sequence number, and seed >> update otp-table >> return PAM_SUCCESS >> else >> return PAM_IGNORE > > I say return an error, not PAM_IGNORE, if the user has an OTP entry > but > didn't answer the prompt. The user did answer, he just answered "no, I do not wish to change the hash, sequence number, and seed". The idea is that in the password stack we can have the following: other password ... pam_otp.so.1 other password ... pam_secure_connection.so.1 other password ... pam_authtok_get.so.1 other password ... pam_authtok_otp_check.so.1 other password ... pam_otp.so.1 On the first invocation there's no PAM_AUTHTOK, so we ask the user if he wants to set new credentials by entering a new hash, sequence number, and seed. If the user declines (answers "no") we return PAM_IGNORE. This allows the admin to add extra modules to the stack (a made up pam_secure_connection in the example above) to ensure that entering a password would not expose that password (by checking that the link is encrypted or that it's a local login). If entering a password is deemed acceptable the pam_authtok_get module is invoked, followed by one that checks if the requirements are met (passphrase length etc). The otp module is called again, which now finds a populated PAM_AUTHTOK and updates the otp-table. Now, if the user had not answered the original question we would return a pam system error (as without an answer we don't know how to proceed, so libpam shouldn't continue down the stack). If the user enters an invalid sequence/hash/seed should we return PAM_FAILURE (as we failed to update his credentials), PAM_TRYAGAIN, or something else? Bart -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/security-discuss/attachments/20061202/404b2570/attachment.html>
