On Thu, Jun 4, 2009 at 2:31 PM, Ger Hobbelt <[email protected]> wrote:
> On Thu, Jun 4, 2009 at 5:41 PM, Lucas Mocellin <[email protected]> > wrote: > > Also I'll try to explain: > > > > I have 2 types of users: supervisors and students > > > > this system is to authenticate students to perform a "online test", BUT > the > > supervisor must authorize them to do it for a given time (the test time, > > usually 1-3hours) > > > > For other reasons the systems will be: a Linux LiveCD which is booted in > any > > machine with this "authenticator client". > > > > The supervisor will authenticate and get as answer a "temporary pass" > (OTP > > time synchronized), so he will give that to the students in the same > > physical location, and the students have X seconds to authenticate their > > "LiveCDs" to be able to perform the test. > > > > So I'm having some problems with this second authentication (students), > when > > they are authenticated (student_id, student_pass, otp_pass) I thought to > > create a VPN between the student and the server and this "online test" > will > > only be available inside this VPN, so the VPN program should be > responsable > > for the "certificate validation", so I don't have to worry about. > > > > is that understandable? my english is not so good. > > > > any ideas are welcome. =) > > > Hm, sounds like you're creating an examination system for taking > tests. There are existing solutions for that, both non-profit and > commercial. Almost always integrated as part of a larger > computer-based training system. You may wish to check them out. > can you tell me which ones? I know "Vue", but it's not the case. > > Anyway, assuming you're going the DIY (do It Yourself) route. > > From what I read in your scenario, you've got everybody connected, so > you've got a network --> no problem to set up a central server which > does all the authentication, authorization and after that, the > examination, for you. See above: solutions for this exist already. DIY > means extra work. some extra information about my scenario. I do have a network, but I CANNOT trus this structure, I mean, can be *any* kind of desktops, with any OS's, and so on.. Sometimes you won't have any idea about the (infra) structure, and just know they have a CD-bootable machines with internet connection. So that's the reason we are customizing a Linux LiveCD distribution to boot this machines, and I don't have access to the gateway of this network (I don't think I said that, but just to clarify). > > > If you go DIY, you need to be aware that you are mixing concepts here, > as Michael already pointer out. > Certificates are like passports: they're used for authentication ~ > identification. I am not 'me' for 3 hours; I've been 'me' for 40 years > now and I like to remain me for another 40 if I am permitted ;-) > Nevertheless, I've traveled frequently and for a lot of countries you > need a visa, which says you're allowed to enter and MUST exit the > premises between then and then. That's authorization. > > And the latter is the major section of your initial question. > Authorization is handled through access control systems; things such > as OTPs can be used there, depending on the goals of such systems. > Nobody would ever think of issuing you a /passport/ for a few hours, > right? Hence, certificates is not the way. > yes, I got what you mean.. I'm using the "wrong" weapon. and I think you got my first idea of "why use certificates" > > > > Let me describe this in another way: > > say you've got a web server where you want to authorize a set of > individuals for a limited time (slot). > > A way to approach this may be (there are other solutions): > > > issue everybody with proper identification. That's either > username/password (the usual); in higher security settings, folks get > issued electronic 'tags' , which contain 'client certificates' which > are, for instance, usable in the SSL realm. > > Now the webserver has to be programmed / configured to request client > /authentication/ for a chosen set of web pages, i.e. when browsing > there, you'll need to have your client certificate accessible from > your browser, so it can be sent to the server. "We want to know who > you are." So far, so good. " We want to know who you are and WHERE YOU ARE". PS: they may have dynamic IP's. > > When this works (you can test this scenario with the OpenSSL tools > s_server and s_client in a rudimentary fashion), you've got > authentication covered: your server knows who's who and who's > connected where. let me explain a little bit more about my scenario: I have to be sure that the student is performing his test in the class, I mean, he can't be at home or somewhere else, so that's the reason to create the OTP time-synchronized password which is given to the students in the exact time of the test in some physical place (I know they can text to someone else, but we are considering that they are trustable). the "where you are" could be translated to "who authorized you to do this test". so in your case I should authenticate the student certificate and also this OTP time-synchronized, no problem. > > > Now on to the timeslot thing (the /authorization/ part): this is where > that 'access control system' stuff comes in: the web server (pages) > need to be programmed such that a chosen set of pages only 'show' (are > enabled) during a given timeslot for a given set of users. That's > outside the OpenSSL scope and definitely a job for the server system > folks (programmers, admins). > How you determine the start of that timeslot is up to you: your > scenario suggests a teacher being present initiates the timeslot; > another often seen scenario is where the timeslots are prepublished > and you thus know you can succesfully log on and do the things you > need to do between, say, 0900 and 1200 hours, june 4th. "Have your > identification with you when you enter during those hours and you're > good to go." > I'm using moodle (moodle.org) to perform these tests, and it has a module which control the tests with this pre-determined hours of test. this is another point, moodle controls itself the test hours, I just have to allow the user to access moodle. > > > By following this flow, you can issue a 'client certificate' to each > participant at your leasure /before the timeslot starts/. E.g.: > certificates can be issued at the start of the school year for one > year or maybe for 6 years, thus giving a certificate lifetime spanning > a study (usually 4-5 years) with a bit of slack. Student must keep his > cert private and stored in a safe place (more on that in a sec, > because you can state this easily, but you MUST provide the facilities > to enable this, or you're just breaking your system before it even > started yet.) > That client certificate is the student's /passport/. (Identification, > can be used as authentication) > For security reasons, I'd suggest using hardware tokens for this, but > I get the weird vibe somebody (not you) is trying to pull this off on > the cheap and not well aware of the impact here. Anyway, having client > certs float around in emails, or on CDs, etc. is begging for trouble > in a multiuser environment, hence those hardware tokens. > Unfortunately there is no budget to go in this way, maybe furthermore. > > Once all the students have those identification/authentication tokens, > you're ready with phase 1. > Then you can add the appropriate students to the access control > system's list, which determines who's getting to view page XYZ during > timeslot 123, once the timeslot has been started by teacher ABC (who, > of course, also has similar client cert/hardware token authentication; > he's just got different /authorization/ as she/he can enter other web > pages where things can be set up (timeslots, examinations, ...) and/or > enabled ("start examination CS201 now")). > > That's workflow mixed with access control, taken from your scenario > description. > > When students access those web pages before the timeslot starts, or > after the timeslot expires, they simply get to see an appropriate > failure message, even while they sent their authenticating client cert > across the line: "we know who you are, the ACL (access control list) > system part just doesn't let you pass into this particular zone, > because it's timeslotted. Try again at 0900 hours, june 4th / the > timeslot has expired, you cannot enter this area any more." > > When students access those pages when the time is right, they get to > see the pages, can fill the web forms or whatever, they can do what > they got to do. > Every access triggers a recheck of the authorization parameters (here: > within/without timeslot?) > > > That's the outline for a working examination system, solution #1. > > When presenting this and the 'token hardware' is making someone panic > at the time the 'cost' of that pops up in the discussion -- and cost > it will, if only a small amount -- I strongly suggest to ditch the > whole client cert thing as the risk of certificate loss / theft is too > great for such an environment and go with oldfashioned > username/password systems as you won't surpass that degree of security > yet: simply code it up that users can log in anytime, they can only > view certain pages when those have been enabled through timeslot + > teacher activation. > > > > > > As you mentioned the word VPN, you implicitly said you got network. > That's where the above will work. > If you don't have connectivity, things become a little different, but > the certificate versus password advice above remains as is. (And, yes, > this is a broad generalization, alas.) > If you don't want the examination itself to happen on a central > server, the above still applies, but needs an added level of > indirection, as it can be considered equivalent to a distributed > server scenario a la, for example, Domain Controllers in MS Windows > environments. Machine M sees individual X entering and sends request > about 'permissions' to central server. Central server responds to > server M with the given set of permissions and their [time]validity. > Server M's software thus determines what individual X is allowed to do > during this time on the machine. > > > Bottom line: one of your major tasks is finding out / setting up an > access control system which allows timeslot-enabled access to selected > areas. (authentication) Which is outside the scope of SSL. > Certificates, for servers, clients, or any other purpose/identity, are > basically to be regarded as /identification/. They also are a form of > /authentication/ as the identification may be considered secure (given > the proper context / conditions, which includes a PKI). Authorization > is an entirely different goal, which has authentication as a > [mandatory] prerequisite: after all, we need to know /who/ we're > authorizing / allowing to do X. > I know is outside of the scope of SSL, but what about the proxy certificate which the another guy talked about? I REALLY know it is not the concept, but if it works pretty good, I think it's not necessary to create an "access control system", just because of the concept, do you agree? I think that to develop this system will be expensive. thanks for your answer =) > > > > > > On a closing note: if the setting is not 'web pages', when translated > to SSL usage, it means authentication is/can be handled by SSL > (sidetrack: there's also anonymous-client connections where you > authenticate using application level protocol, such as in the case of > https:// based forums, where you log into a forum using > user+passphrase); /authorization/ is always handled in an overlay > (application layer), as SSL cannot not do this for you. > > > > -- > Met vriendelijke groeten / Best regards, > > Ger Hobbelt > > -------------------------------------------------- > web: http://www.hobbelt.com/ > http://www.hebbut.net/ > mail: [email protected] > mobile: +31-6-11 120 978 > -------------------------------------------------- > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [email protected] > Automated List Manager [email protected] >
