headers
Martin Widin | 2 Apr 1997 13:47
Picon
Picon

draft-ietf-secsh-transport-00.txt

There was apparently some a problem in sending this draft (message
size limit was too low on the ietf-ssh list).

    Tatu

Network Working Group                           Tatu Ylonen <ylo <at> ssh.fi>
INTERNET-DRAFT                               SSH Communications Security
draft-ietf-secsh-transport-00.txt                         March 22, 1997
Expires: September 1, 1997

                      SSH Transport Layer Protocol

Status of This memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast),
or ftp.isi.edu (US West Coast).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Widin | 2 Apr 1997 13:47
Picon
Picon

draft-ietf-secsh-transport-00.txt

          blowfish-cbc     optional          Blowfish in CBC mode

The 3des-cbc encryption is three-key triple-DES (encrypt-decrypt-


Tatu Ylonen <ylo <at> ssh.fi>                                        Äpage 7Å

INTERNET-DRAFT                                            March 22, 1997

encrypt), where the first 8 bytes of the key are used for the first
encryption, the next 8 bytes for the decryption, and the following 8
bytes for the final encryption.  This requires 24 bytes of key data (of
which the parity bits are not actually used).  To implement CBC mode,
there is only one initialization vector.

For ciphers with variable-length keys, 128 bit keys are used.

The ARCFOUR cipher is compatible with the RC4 cipher; RC4 is a trademark
of RSA Data Security, Inc.

Descriptions of all of these ciphers can be found e.g. from Bruce
Schneier: Applied Cryptography, 2nd ed., John Wiley and Sons, 1996.

5.4.  Data Integrity

Data integrity is protected by including with each packet a message
authentication code (MAC) that is computed from a shared secret, packet
sequence number, and the contents of the packet.

The message authentication algorithm and key are negotiated during key
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Widin | 2 Apr 1997 13:47
Picon
Picon

draft-ietf-secsh-transport-00.txt

to the server.  Note that the negotiated algorithms are not explicitly
passed, as the algorithms given in Section ``Algorithm Negotiation''
fully determine the algorithms.

The resulting data is encrypted first with the time-variant server key,
and the result then with the server host key.  The resulting double-
encrypted value is then sent to the server.  Note that public-key
encryption probably involves padding, depending on the algorithm.

            vlint32   SSH_MSG_KEXDE_SESSIONKEY
            string    double-encrypted session key

Upon receiving this message, the server uses its private host and server
keys to decrypt the session key.  It computes a corresponding SHA hash,
and compares the hash values.  If the hash does not match, the server
disconnects with the appropriate message.  If the hash matches, the
server responds with an SSH_MSG_NEWKEYS message and takes the keys into
use.

6.2.4.  Deriving Encryption and Integrity Keys

As a result of the key exchange, the parties have a 256-bit shared
secret.  Various keys are computed from this secret and the exchange
hash.  The session identifier is used to make it impossible for either
party to alone determine the keys.

Each key is computed as HASH of the concatenation of the session
identifier and 16 bytes of secret data.  The secret data is different
for each key, and is taken from the 32-byte shared secret as follows:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Forssen | 4 Apr 1997 17:13
Picon

Securid advanced operations

The current userauth draft does not support any other securid
authetification than the simple case that the user supplies the code.
Securid can sometimes require the next token code as well. Or it can be
in new-pin mode which involves multiple interactions with the user. Are
there any good reasons why the protocol doesn't support these? Or have I
missed something in the specifications?

	/MaF
Permalink | Reply | 1 comment |
headers
Michael Richardson | 4 Apr 1997 18:28
Picon

Re: Securid advanced operations


T>>>>> "Martin" == Martin Forssen <maf <at> carlstedt.se> writes:
    Martin> he current userauth draft does not support any other
    Martin> securid authetification than the simple case that the user
    Martin> supplies the code.  Securid can sometimes require the next
    Martin> token code as well. Or it can be in new-pin mode which

  The simple reason is that these modes are not well understood by
many developers... I went through this realization about how the
new-pin mode and the reauth mode worked only after discussing securid
integration to a product with a securid SE.

  One technical reason, is that the protocol is client driven. If it
were more server driven, then the server could keep sending prompts
(instead of just accepts/denies) to the user until it was satisfied
with the response.

   :!mcr!:            |  Network security consulting and 
   Michael Richardson |      contract programming
 WWW: <A
HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr <at> sandelman.ottawa.on.ca</A>.
PGP key available.
Permalink | Reply | 0 comments |
headers
Michael Richardson | 5 Apr 1997 18:25
Picon

Re: Securid advanced operations


>>>>> "Tatu" == Tatu Ylonen <ylo <at> ssh.fi> writes:
    Tatu> Can you give concrete suggestions how it should be changed
    Tatu> to be better suited for most purposes?

  I think the server should say:

  Please authenticate with the following item: the client can decline
to do so. The server can then go onwards and ask for other types if it
desires. 

  The order is server chosen, not client chosen. This gets around
possibly strange things where you need to pass kerberos tickets to get
access to ~/.ssh, but then want to do RSA authentication. HOWEVER, if
there were a firewall in front of the intended target host, then you
might want to do RSA authentication (for the firewall), and then pass
the ticket to the intended target host, and *then* do password
authentication (or RSA, again).

  The server always gives a positive or negative response. A positive
response does not constitute the end of authentication.
  For interactive type tokens, the server should be able to do things
like:
	send the following string to the user as a prompt, tell me the response
	
  The strings could be numbered (so the client can, if they understand
things, e.g. s/key or opie do the computation itself), but any strings
that are not understood are passed to a human. The client declining to
authenticate like that if it can't get a human to cooperate.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tatu Ylonen | 5 Apr 1997 18:51
Picon
Picon

Re: Securid advanced operations

>   Please authenticate with the following item: the client can decline
> to do so. The server can then go onwards and ask for other types if it
> desires. 

It can already do this: it just lists one authentication method as the
possible continuation.

>   The order is server chosen, not client chosen. This gets around
> possibly strange things where you need to pass kerberos tickets to get
> access to ~/.ssh, but then want to do RSA authentication. HOWEVER, if
> there were a firewall in front of the intended target host, then you
> might want to do RSA authentication (for the firewall), and then pass
> the ticket to the intended target host, and *then* do password
> authentication (or RSA, again).

As far as I understand, the server can already do it with the current
proposal.

>   The server always gives a positive or negative response. A positive
> response does not constitute the end of authentication.

One could reasonably argue that the server should give some indication
when one part of authentication has been successfully performed.

Can you think of benefits that this would give?

>   For interactive type tokens, the server should be able to do things
> like:
> 	send the following string to the user as a prompt, tell me the response
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Richardson | 5 Apr 1997 21:30
Picon

Re: Securid advanced operations


>>>>> "Tatu" == Tatu Ylonen <ylo <at> ssh.fi> writes:
    Tatu> It can already do this: it just lists one authentication
    Tatu> method as the possible continuation.

  I didn't get this from my first reading. I believe that you agreed
to change this though

    Tatu> As far as I understand, the server can already do it with
    Tatu> the current proposal.

  Can the *client*? Putting the smarts in the server just makes sense
to me. 

    Tatu> One could reasonably argue that the server should give some
    Tatu> indication when one part of authentication has been
    Tatu> successfully performed.

    Tatu> Can you think of benefits that this would give?

  Yes. It allows the client to give know that the authentication
succeeded, and not simply give up. 

    >> For interactive type tokens, the server should be able to do
    >> things like: send the following string to the user as a prompt,
    >> tell me the response

    Tatu> This doesn't work very beautifully in a windows environment,
    Tatu> unless you do all authentication within the terminal window.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew G. Morgan | 11 Apr 1997 18:25

Re: draft-ietf-secsh-userauth-01.txt (fwd)

Hi,

I guess I sent this to Tatu a long while back.  I've had no acknowledgment
so I suppose it got drowned in his mail folder...  In case anyone has any
further comments, I am posting it to both the PAM and the itef-secsh
lists...

Cheers

Andrew

I wrote:
> Subject: Re: draft-ietf-secsh-userauth-01.txt (fwd)
> To: ylo <at> ssh.fi (Tatu Ylonen)
> Date: Sat, 29 Mar 1997 13:15:45 -0800 (PST)
> 
> Hi,
> 
> Tatu Ylonen wrote:
> > I'm not very very familiar with the way PAM works.
> 
> I maintain Linux-PAM so I guess I'm in a position to clarify things(!)
> 
> I've had a chance to read over your Draft RFC and I see that your
> User-authentication protocols are specifically trying to address things that
> PAM tries to abstract: I am sure that it will be possible to add 'PAM' style
> authentication to the list of supported protocols...
> 
> Aside from "how to write a PAM application", which is what the source code I
> pointed to in my previous post was all about.  To implement PAM you will
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tatu Ylonen | 14 Apr 1997 03:25
Picon
Picon

Re: draft-ietf-secsh-userauth-01.txt (fwd)

> I guess I sent this to Tatu a long while back.  I've had no acknowledgment
> so I suppose it got drowned in his mail folder...  In case anyone has any
> further comments, I am posting it to both the PAM and the itef-secsh
> lists...

Sorry about the delay.  Yes, it's still waiting for processing in my
mailbox.  (I was at the IETF last week, and have hardly read my mail
during that time.)

    Tatu
Permalink | Reply | 0 comments |

Gmane