| *** Terho (d58473c2@gateway/web/freenode/ip.213.132.115.194) has joined #wikid | 07:52 | |
| Terho | BTW WiKIDCA certificate is valid until Apr 10th 2013. | 07:54 |
|---|---|---|
| *** Terho has quit (Quit: Page closed) | 08:08 | |
| *** nowen (~nowen@adsl-74-176-163-56.asm.bellsouth.net) has joined #wikid | 13:42 | |
| *** TomT___ (~Tom___@66.150.156.1) has joined #wikid | 17:57 | |
| TomT___ | Hey Nick | 17:57 |
| TomT___ | are you there? | 17:57 |
| nowen | yes | 17:57 |
| nowen | thx for that doc | 17:58 |
| TomT___ | i guess first, did you get my email with the asa config | 17:58 |
| nowen | yes - thanks for that | 18:00 |
| TomT___ | cool | 18:19 |
| TomT___ | Is there a way I can skip the option to check for a pin on the device? | 18:19 |
| nowen | the option to check for a pin? | 18:20 |
| TomT___ | yes | 18:20 |
| TomT___ | i tried setting the value of the pin to 0 | 18:20 |
| nowen | no | 18:20 |
| TomT___ | but the client still wanted me to punch in a pin | 18:20 |
| nowen | that would not be two-factor auth ;) | 18:20 |
| TomT___ | not by itself. | 18:20 |
| TomT___ | but the cert is something that user has. | 18:21 |
| TomT___ | or in this case the token | 18:21 |
| TomT___ | and the lan credentials is something that the user knows. | 18:21 |
| TomT___ | and therefore, two factor. | 18:21 |
| TomT___ | i guess im looking at this from a very specific use case | 18:21 |
| TomT___ | but it would be sort of nice if there was a way to disable | 18:21 |
| nowen | but we use the PIN to prove possession of the private keys. not PIN/OTP transaction, no proof of private key | 18:22 |
| nowen | we cannot do it | 18:22 |
| TomT___ | okay then. | 18:22 |
| TomT___ | sort of lost by your statement "prove possession of the private keys" | 18:27 |
| TomT___ | the client generates its own priv/pub keypair | 18:27 |
| TomT___ | so wouldnt the private key be on the client anyhow? and thus, possession? | 18:27 |
| nowen | the OTP is encrypted bu the tokens public key, meaning that only the private key on the token can decrypt it | 18:28 |
| nowen | only by validating the OTP do we know that the user has the private key | 18:28 |
| TomT___ | i get that, but why have the client punch in the pin? | 18:29 |
| TomT___ | so client sends request and pub key to server | 18:29 |
| TomT___ | server encrypts the config data and pub key with client pub key | 18:30 |
| TomT___ | client is the only one who can decrypt the data | 18:30 |
| nowen | because the PIN is encrypted by the server's pub key, and it is only way to know you are talking to the right server | 18:30 |
| nowen | there is not connection to the process without the OTP. It is not like a certificate in the browser | 18:32 |
| TomT___ | i guess the part i just dont get. | 18:33 |
| TomT___ | thats the part i just dont get. | 18:33 |
| TomT___ | i punch in a pin on the client | 18:34 |
| TomT___ | your saying the client encrypts the pin with the server pub key | 18:34 |
| nowen | correct | 18:35 |
| TomT___ | server gets the payload and decrypts with private key | 18:35 |
| TomT___ | now server has the pin. | 18:35 |
| TomT___ | server checks the pin against the pin stored in some sort of local database | 18:35 |
| TomT___ | once pin is validated, server encrypts the passcode using public key of said client and ships the payload back | 18:35 |
| TomT___ | is that pretty much it? | 18:36 |
| nowen | correct. there are some other crypto detail that probably aren't important | 18:36 |
| TomT___ | okay, so with that very high-level explanation | 18:37 |
| TomT___ | what im saying is. | 18:37 |
| TomT___ | i dont understand what value the pin adds. | 18:37 |
| TomT___ | give me a moment to think | 18:38 |
| TomT___ | this has to be something obvious | 18:38 |
| TomT___ | nope. not getting it | 18:38 |
| TomT___ | as far as my feeblemind can think of, i dont see why the client cant just make an encrypted request | 18:39 |
| TomT___ | and have the server spit back a passcode encrypted with the pub key of the client. | 18:39 |
| nowen | what is in the request? | 18:39 |
| TomT___ | that would be a secure transfer. | 18:39 |
| TomT___ | "hi i want a passcode" | 18:39 |
| TomT___ | and server responds "okay. passcode=[passcode]" | 18:40 |
| nowen | ok - so that might work for your situation where you want to use a lan password, but for none of our other customers | 18:40 |
| nowen | thus, we will not do it | 18:40 |
| TomT___ | oh yeah. | 18:40 |
| TomT___ | oh no. im not saying not rewriting stuff | 18:40 |
| TomT___ | just would be nice to have an option of doing that, if the customer is aware of this issue. | 18:41 |
| TomT___ | i get why you put in the idea of the PIN | 18:42 |
| TomT___ | if they were planning on just using the token as a replacement of an extranet password | 18:42 |
| TomT___ | or whatever purpose. | 18:42 |
| TomT___ | but im assuming im not the first to bring this up | 18:42 |
| TomT___ | and im you sound pretty adamant with your response. | 18:43 |
| nowen | you are the first :) | 18:43 |
| TomT___ | really? wow | 18:43 |
| TomT___ | so odd | 18:43 |
| nowen | what you're asking reduces security | 18:43 |
| TomT___ | i get that. | 18:43 |
| TomT___ | for sure. | 18:43 |
| TomT___ | but for corporations who already use another system for authenticating users and simply want a bolt on | 18:44 |
| TomT___ | in terms of bolting on a second factor | 18:44 |
| TomT___ | instead of replacement | 18:44 |
| TomT___ | they may not need the requirement of a pin | 18:45 |
| TomT___ | you get what im saying? | 18:45 |
| TomT___ | i like this platform. | 18:45 |
| TomT___ | I like it alot. | 18:45 |
| TomT___ | but i can see people having a migrane over a pin. even if i tell them to use their ATM code as suggested | 18:46 |
| nowen | people have migraines over passwords, not PINs | 18:46 |
| TomT___ | haha. well i can tell you they have migraines over anything they have to remember with IT | 18:46 |
| TomT___ | alright, its not end all deal breaker, but all im saying is it would be nice to have the flex to disable with the understanding of the inherent issues with security. | 18:48 |
| TomT___ | for example, using this as a complete RSA token replacement. | 18:48 |
| nowen | that is what our customers are doing with it | 18:50 |
| TomT___ | i want to be a customer too.... doesnt that count for anything? lol | 18:53 |
| nowen | :) | 18:53 |
| TomT___ | like if someone sets the pin requirement to zero, then <H1>Hey -- youre doing something that disables two-factor security on this system and requires special consideration unless you like being compromised. Do not do this unless you know wtf you are doing</H1> | 18:55 |
| *** TomT___ has quit () | 20:02 | |
| *** Tom___ has quit (Quit: Page closed) | 20:30 | |
| *** prowlah (~prowlah@unaffiliated/prowlah) has joined #wikid | 22:59 | |
| prowlah | hey nowen | 22:59 |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!