Proxy certificates aren't appropriate for this application. I was simply giving an example of why certificate expirations in hours are reasonable things to support.
-Kyle H On Thu, Jun 4, 2009 at 4:13 PM, Lucas Mocellin<[email protected]> wrote: > > > 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] > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
