Great Circle Associates Firewalls
(May 1995)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: encrypted telnet sessions
From: Michael Richardson <mcr @ milkyway . com>
Organization: Milkyway Networks Corporation
Date: Mon, 29 May 1995 15:12:39 -0400
To: firewalls @ greatcircle . com
In-reply-to: <199505270004 . UAA14751 @ mail . fh . rbus>
Newsgroups: milkyway.mail.firewalls

In article <199505270004 .
 UAA14751 @
 mail .
 fh .
 rbus> you write:
>1. Are there Windows clients available for this scheme.

  Considering that STEL has barely gotten released, and is likely to
undergo many changes (many want it to just work with telnet options
not a custom protocol, and others want it to give up the /bin/login
functions completely), I think this is probably premature.
  stel is not a viable mainstream solution, YET.

>>A mechanism I proposed several years ago is even simpler: with a standard
>>challange-response card system the challenge is presented and the token
>>used to provide what would normally be used as a one-time-password. Instead,
>>the response is used as the key for entering session negotiation.
>     ~~~~~~~~
>I think I've misunderstood this.
>
>I follow:
>I send token from card in response to challenge from destination host. 
>
>Then I'm confused:
>What are you refering to as the 'response'? The number/words from the local 
>card/PC *or* the response returned by the destination host (the 'challenge')
>after a username is given? Or something else? Or is the 'token' the

  What padgett suggest works fine for cards that do encryption of some
kind to produce the response. I can not see how this works for
something like S/Key, since the remote host doesn't know the correct
answer, only what it should MD4/5 to.
  The "key" is the "password" that would otherwise authenticate the
user. You just prove your identity by encrypting something with the
key and demonstrating that it works. I can see how it might work with
traditional Unix passwords if you are willing to exchange the salt,
however, the host still needs the plaintext password to use as a key.

>That is to say: 
>Login: jdoe
>challenge: aoeur345loidf...
>
>I punch in aoeur345loidf... and off we go.
 
  Yup.

>What if someone not jdoe punches this into his PC program.  Does the
>host determine the validity of the response after all the data comes
>encrypted?

  Depends on the PC program. Many "tokens" (S/Key, DES Gold,
CryptoCard, SecureId) have passwords that need to be typed in before
they will respond to the challenge. (S/Key has a secret key, others
have PIN numbers)



-- 
   :!mcr!:            |     <A HREF="http://www.milkyway.com/";>Milkyway Networks Corporation</A>
   Michael Richardson |   Makers of the Black Hole firewall 
 NCF: aa714 || xx714  | +1 613 566-4574 ... mcr @
 milkyway .
 com
 Home: <A HREF="http://www.sandelman.ocunix.on.ca/People/Michael_Richardson/Bio.html";>mcr @
 sandelman .
 ocunix .
 on .
 ca</A>. PGP key available.


References:
Indexed By Date Previous: Re: NT as a Firewall
From: paul @ hawksbill . sprintmrn . com (Paul Ferguson)
Next: Would you trust a virtual private network?
From: blymn @ awadi . com . AU (Brett Lymn)
Indexed By Thread Previous: re: encrypted telnet sessions
From: cwerner @ fh . us . bosch . com (Christopher L. Werner)
Next: Re: encrypted telnet sessions
From: nsayer @ quack . kfu . com (Nick Sayer)

Google
 
Search Internet Search www.greatcircle.com