aboutsummaryrefslogtreecommitdiff
path: root/doc/draft-ietf-secsh-transport-16.txt
blob: b4564f171d2dac9afe0d51fb590fa9c02af729fd (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
Network Working Group                                          T. Ylonen
Internet-Draft                                                T. Kivinen
Expires: January 12, 2004               SSH Communications Security Corp
                                                             M. Saarinen
                                                 University of Jyvaskyla
                                                                T. Rinne
                                                             S. Lehtinen
                                        SSH Communications Security Corp
                                                           July 14, 2003


                      SSH Transport Layer Protocol
                   draft-ietf-secsh-transport-16.txt

Status of this Memo

      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

      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."

      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt.

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

      This Internet-Draft will expire on January 12, 2004.

Copyright Notice

      Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

      SSH is a protocol for secure remote login and other secure network
      services over an insecure network.

      This document describes the SSH transport layer protocol which
      typically runs on top of TCP/IP.  The protocol can be used as a



Ylonen, et. al.         Expires January 12, 2004                [Page 1]

Internet-Draft        SSH Transport Layer Protocol             July 2003


      basis for a number of secure network services.  It provides strong
      encryption, server authentication, and integrity protection.  It
      may also provide compression.

      Key exchange method, public key algorithm, symmetric encryption
      algorithm, message authentication algorithm, and hash algorithm
      are all negotiated.

      This document also describes the Diffie-Hellman key exchange
      method and the minimal set of algorithms that are needed to
      implement the SSH transport layer protocol.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  Connection Setup . . . . . . . . . . . . . . . . . . . . . . .  4
   3.1 Use over TCP/IP  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.2 Protocol Version Exchange  . . . . . . . . . . . . . . . . . .  4
   3.3 Compatibility With Old SSH Versions  . . . . . . . . . . . . .  5
   3.4 Old Client, New Server . . . . . . . . . . . . . . . . . . . .  5
   3.5 New Client, Old Server . . . . . . . . . . . . . . . . . . . .  6
   4.  Binary Packet Protocol . . . . . . . . . . . . . . . . . . . .  6
   4.1 Maximum Packet Length  . . . . . . . . . . . . . . . . . . . .  7
   4.2 Compression  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . . 11
   4.6 Public Key Algorithms  . . . . . . . . . . . . . . . . . . . . 11
   5.  Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.1 Algorithm Negotiation  . . . . . . . . . . . . . . . . . . . . 14
   5.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . . 17
   5.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . . 18
   6.  Diffie-Hellman Key Exchange  . . . . . . . . . . . . . . . . . 19
   6.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . . 20
   7.  Key Re-Exchange  . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  Service Request  . . . . . . . . . . . . . . . . . . . . . . . 22
   9.  Additional Messages  . . . . . . . . . . . . . . . . . . . . . 22
   9.1 Disconnection Message  . . . . . . . . . . . . . . . . . . . . 23
   9.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . . 23
   9.3 Debug Message  . . . . . . . . . . . . . . . . . . . . . . . . 24
   9.4 Reserved Messages  . . . . . . . . . . . . . . . . . . . . . . 24
   10. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 24
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   12. Intellectual Property  . . . . . . . . . . . . . . . . . . . . 25
   13. Additional Information . . . . . . . . . . . . . . . . . . . . 25
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27



Ylonen, et. al.         Expires January 12, 2004                [Page 2]

Internet-Draft        SSH Transport Layer Protocol             July 2003


       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 29


















































Ylonen, et. al.         Expires January 12, 2004                [Page 3]

Internet-Draft        SSH Transport Layer Protocol             July 2003


   1. Introduction

      The SSH transport layer is a secure low level transport protocol.
      It provides strong encryption, cryptographic host authentication,
      and integrity protection.

      Authentication in this protocol level is host-based; this protocol
      does not perform user authentication.  A higher level protocol for
      user authentication can be designed on top of this protocol.

      The protocol has been designed to be simple, flexible, to allow
      parameter negotiation, and to minimize the number of round-trips.
      Key exchange method, public key algorithm, symmetric encryption
      algorithm, message authentication algorithm, and hash algorithm
      are all negotiated.  It is expected that in most environments,
      only 2 round-trips will be needed for full key exchange, server
      authentication, service request, and acceptance notification of
      service request.  The worst case is 3 round-trips.

   2. Conventions Used in This Document

      The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
      NOT", and "MAY" that appear in this document are to be interpreted
      as described in [RFC2119]

      The used data types and terminology are specified in the
      architecture document [SSH-ARCH]

      The architecture document also discusses the algorithm naming
      conventions that MUST be used with the SSH protocols.

   3. Connection Setup

      SSH works over any 8-bit clean, binary-transparent transport.  The
      underlying transport SHOULD protect against transmission errors as
      such errors cause the SSH connection to terminate.

      The client initiates the connection.

   3.1 Use over TCP/IP

      When used over TCP/IP, the server normally listens for connections
      on port 22.  This port number has been registered with the IANA,
      and has been officially assigned for SSH.

   3.2 Protocol Version Exchange

      When the connection has been established, both sides MUST send an



Ylonen, et. al.         Expires January 12, 2004                [Page 4]

Internet-Draft        SSH Transport Layer Protocol             July 2003


      identification string of the form "SSH-protoversion-
      softwareversion comments", followed by carriage return and newline
      characters (ASCII 13 and 10, respectively).  Both sides MUST be
      able to process identification strings without carriage return
      character.  No null character is sent.  The maximum length of the
      string is 255 characters, including the carriage return and
      newline.

      The part of the identification string preceding carriage return
      and newline is used in the Diffie-Hellman key exchange (see
      Section Section 6).

      The server MAY send other lines of data before sending the version
      string.  Each line SHOULD be terminated by a carriage return and
      newline.  Such lines MUST NOT begin with "SSH-", and SHOULD be
      encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified).
      Clients MUST be able to process such lines; they MAY be silently
      ignored, or MAY be displayed to the client user; if they are
      displayed, control character filtering discussed in [SSH-ARCH]
      SHOULD be used.  The primary use of this feature is to allow TCP-
      wrappers to display an error message before disconnecting.

      Version strings MUST consist of printable US-ASCII characters, not
      including whitespaces or a minus sign (-).  The version string is
      primarily used to trigger compatibility extensions and to indicate
      the capabilities of an implementation.  The comment string should
      contain additional information that might be useful in solving
      user problems.

      The protocol version described in this document is 2.0.

      Key exchange will begin immediately after sending this identifier.
      All packets following the identification string SHALL use the
      binary packet protocol, to be described below.

   3.3 Compatibility With Old SSH Versions

      During the transition period, it is important to be able to work
      in a way that is compatible with the installed SSH clients and
      servers that use an older version of the protocol.  Information in
      this section is only relevant for implementations supporting
      compatibility with SSH versions 1.x.

   3.4 Old Client, New Server

      Server implementations MAY support a configurable "compatibility"
      flag that enables compatibility with old versions.  When this flag
      is on, the server SHOULD identify its protocol version as "1.99".



Ylonen, et. al.         Expires January 12, 2004                [Page 5]

Internet-Draft        SSH Transport Layer Protocol             July 2003


      Clients using protocol 2.0 MUST be able to identify this as
      identical to "2.0".  In this mode the server SHOULD NOT send the
      carriage return character (ASCII 13) after the version
      identification string.

      In the compatibility mode the server SHOULD NOT send any further
      data after its initialization string until it has received an
      identification string from the client.  The server can then
      determine whether the client is using an old protocol, and can
      revert to the old protocol if required.  In the compatibility
      mode, the server MUST NOT send additional data before the version
      string.

      When compatibility with old clients is not needed, the server MAY
      send its initial key exchange data immediately after the
      identification string.

   3.5 New Client, Old Server

      Since the new client MAY immediately send additional data after
      its identification string (before receiving server's
      identification), the old protocol may already have been corrupted
      when the client learns that the server is old.  When this happens,
      the client SHOULD close the connection to the server, and
      reconnect using the old protocol.

   4. Binary Packet Protocol

   Each packet is in the following format:

     uint32    packet_length
     byte      padding_length
     byte[n1]  payload; n1 = packet_length - padding_length - 1
     byte[n2]  random padding; n2 = padding_length
     byte[m]   mac (message authentication code); m = mac_length

         packet_length
            The length of the packet (bytes), not including MAC or the
            packet_length field itself.

         padding_length
            Length of padding (bytes).

         payload
            The useful contents of the packet.  If compression has been
            negotiated, this field is compressed.  Initially,
            compression MUST be "none".




Ylonen, et. al.         Expires January 12, 2004                [Page 6]

Internet-Draft        SSH Transport Layer Protocol             July 2003


         random padding
            Arbitrary-length padding, such that the total length of
            (packet_length || padding_length || payload || padding) is a
            multiple of the cipher block size or 8, whichever is larger.
            There MUST be at least four bytes of padding.  The padding
            SHOULD consist of random bytes.  The maximum amount of
            padding is 255 bytes.

         mac
            Message authentication code.  If message authentication has
            been negotiated, this field contains the MAC bytes.
            Initially, the MAC algorithm MUST be "none".


      Note that length of the concatenation of packet length, padding
      length, payload, and padding MUST be a multiple of the cipher
      block size or 8, whichever is larger.  This constraint MUST be
      enforced even when using stream ciphers.  Note that the packet
      length field is also encrypted, and processing it requires special
      care when sending or receiving packets.

      The minimum size of a packet is 16 (or the cipher block size,
      whichever is larger) bytes (plus MAC); implementations SHOULD
      decrypt the length after receiving the first 8 (or cipher block
      size, whichever is larger) bytes of a packet.

   4.1 Maximum Packet Length

      All implementations MUST be able to process packets with
      uncompressed payload length of 32768 bytes or less and total
      packet size of 35000 bytes or less (including length, padding
      length, payload, padding, and MAC.).  The maximum of 35000 bytes
      is an arbitrary chosen value larger than uncompressed size.
      Implementations SHOULD support longer packets, where they might be
      needed, e.g.  if an implementation wants to send a very large
      number of certificates.  Such packets MAY be sent if the version
      string indicates that the other party is able to process them.
      However, implementations SHOULD check that the packet length is
      reasonable for the implementation to avoid denial-of-service
      and/or buffer overflow attacks.

   4.2 Compression

      If compression has been negotiated, the payload field (and only
      it) will be compressed using the negotiated algorithm.  The length
      field and MAC will be computed from the compressed payload.
      Encryption will be done after compression.




Ylonen, et. al.         Expires January 12, 2004                [Page 7]

Internet-Draft        SSH Transport Layer Protocol             July 2003


      Compression MAY be stateful, depending on the method.  Compression
      MUST be independent for each direction, and implementations MUST
      allow independently choosing the algorithm for each direction.

   The following compression methods are currently defined:

     none     REQUIRED        no compression
     zlib     OPTIONAL        ZLIB (LZ77) compression

      The "zlib" compression is described in [RFC1950] and in [RFC1951].
      The compression context is initialized after each key exchange,
      and is passed from one packet to the next with only a partial
      flush being performed at the end of each packet.  A partial flush
      means that the current compressed block is ended and all data will
      be output.  If the current block is not a stored block, one or
      more empty blocks are added after the current block to ensure that
      there are at least 8 bits counting from the start of the end-of-
      block code of the current block to the end of the packet payload.

      Additional methods may be defined as specified in [SSH-ARCH].

   4.3 Encryption

      An encryption algorithm and a key will be negotiated during the
      key exchange.  When encryption is in effect, the packet length,
      padding length, payload and padding fields of each packet MUST be
      encrypted with the given algorithm.

      The encrypted data in all packets sent in one direction SHOULD be
      considered a single data stream.  For example, initialization
      vectors SHOULD be passed from the end of one packet to the
      beginning of the next packet.  All ciphers SHOULD use keys with an
      effective key length of 128 bits or more.

      The ciphers in each direction MUST run independently of each
      other, and implementations MUST allow independently choosing the
      algorithm for each direction (if multiple algorithms are allowed
      by local policy).

   The following ciphers are currently defined:

     3des-cbc         REQUIRED          three-key 3DES in CBC mode
     blowfish-cbc     RECOMMENDED       Blowfish in CBC mode
     twofish256-cbc   OPTIONAL          Twofish in CBC mode,
                                        with 256-bit key
     twofish-cbc      OPTIONAL          alias for "twofish256-cbc" (this
                                        is being retained for
                                        historical reasons)



Ylonen, et. al.         Expires January 12, 2004                [Page 8]

Internet-Draft        SSH Transport Layer Protocol             July 2003


     twofish192-cbc   OPTIONAL          Twofish with 192-bit key
     twofish128-cbc   RECOMMENDED       Twofish with 128-bit key
     aes256-cbc       OPTIONAL          AES (Rijndael) in CBC mode,
                                        with 256-bit key
     aes192-cbc       OPTIONAL          AES with 192-bit key
     aes128-cbc       RECOMMENDED       AES with 128-bit key
     serpent256-cbc   OPTIONAL          Serpent in CBC mode, with
                                        256-bit key
     serpent192-cbc   OPTIONAL          Serpent with 192-bit key
     serpent128-cbc   OPTIONAL          Serpent with 128-bit key
     arcfour          OPTIONAL          the ARCFOUR stream cipher
     idea-cbc         OPTIONAL          IDEA in CBC mode
     cast128-cbc      OPTIONAL          CAST-128 in CBC mode
     none             OPTIONAL          no encryption; NOT RECOMMENDED

      The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-
      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 168 bits are actually used).  To
      implement CBC mode, outer chaining MUST be used (i.e., there is
      only one initialization vector).  This is a block cipher with 8
      byte blocks.  This algorithm is defined in [SCHNEIER]

      The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit
      keys [SCHNEIER].  This is a block cipher with 8 byte blocks.

      The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC
      mode, with 256 bit keys as described [TWOFISH].  This is a block
      cipher with 16 byte blocks.

      The "twofish192-cbc" cipher.  Same as above but with 192-bit key.

      The "twofish128-cbc" cipher.  Same as above but with 128-bit key.

      The "aes256-cbc" cipher is AES (Advanced Encryption Standard),
      formerly Rijndael, in CBC mode.  This version uses 256-bit key.

      The "aes192-cbc" cipher.  Same as above but with 192-bit key.

      The "aes128-cbc" cipher.  Same as above but with 128-bit key.

      The "serpent256-cbc" cipher in CBC mode, with 256-bit key as
      described in the Serpent AES submission.

      The "serpent192-cbc" cipher.  Same as above but with 192-bit key.

      The "serpent128-cbc" cipher.  Same as above but with 128-bit key.



Ylonen, et. al.         Expires January 12, 2004                [Page 9]

Internet-Draft        SSH Transport Layer Protocol             July 2003


      The "arcfour" is the Arcfour stream cipher with 128 bit keys.  The
      Arcfour cipher is believed to be compatible with the RC4 cipher
      [SCHNEIER].  RC4 is a registered trademark of RSA Data Security
      Inc.  Arcfour (and RC4) has problems with weak keys, and should be
      used with caution.

      The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER].
      IDEA is patented by Ascom AG.

      The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode
      [RFC2144].

      The "none" algorithm specifies that no encryption is to be done.
      Note that this method provides no confidentiality protection, and
      it is not recommended.  Some functionality (e.g.  password
      authentication) may be disabled for security reasons if this
      cipher is chosen.

      Additional methods may be defined as specified in [SSH-ARCH].

   4.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 exchange.  Initially, no MAC will be in effect, and its length
      MUST be zero.  After key exchange, the selected MAC will be
      computed before encryption from the concatenation of packet data:

     mac = MAC(key, sequence_number || unencrypted_packet)

      where unencrypted_packet is the entire packet without MAC (the
      length fields, payload and padding), and sequence_number is an
      implicit packet sequence number represented as uint32.  The
      sequence number is initialized to zero for the first packet, and
      is incremented after every packet (regardless of whether
      encryption or MAC is in use).  It is never reset, even if
      keys/algorithms are renegotiated later.  It wraps around to zero
      after every 2^32 packets.  The packet sequence number itself is
      not included in the packet sent over the wire.

      The MAC algorithms for each direction MUST run independently, and
      implementations MUST allow choosing the algorithm independently
      for both directions.

      The MAC bytes resulting from the MAC algorithm MUST be transmitted



Ylonen, et. al.         Expires January 12, 2004               [Page 10]

Internet-Draft        SSH Transport Layer Protocol             July 2003


      without encryption as the last part of the packet.  The number of
      MAC bytes depends on the algorithm chosen.

   The following MAC algorithms are currently defined:

     hmac-sha1    REQUIRED        HMAC-SHA1 (digest length = key
                                  length = 20)
     hmac-sha1-96 RECOMMENDED     first 96 bits of HMAC-SHA1 (digest
                                  length = 12, key length = 20)
     hmac-md5     OPTIONAL        HMAC-MD5 (digest length = key
                                  length = 16)
     hmac-md5-96  OPTIONAL        first 96 bits of HMAC-MD5 (digest
                                  length = 12, key length = 16)
     none         OPTIONAL        no MAC; NOT RECOMMENDED

      The "hmac-*" algorithms are described in [RFC2104] The "*-n" MACs
      use only the first n bits of the resulting value.

      The hash algorithms are described in [SCHNEIER].

      Additional methods may be defined as specified in [SSH-ARCH].

   4.5 Key Exchange Methods

      The key exchange method specifies how one-time session keys are
      generated for encryption and for authentication, and how the
      server authentication is done.

   Only one REQUIRED key exchange method has been defined:

     diffie-hellman-group1-sha1       REQUIRED

      This method is described later in this document.

      Additional methods may be defined as specified in [SSH-ARCH].

   4.6 Public Key Algorithms

      This protocol has been designed to be able to operate with almost
      any public key format, encoding, and algorithm (signature and/or
      encryption).

      There are several aspects that define a public key type:
      o  Key format: how is the key encoded and how are certificates
         represented.  The key blobs in this protocol MAY contain
         certificates in addition to keys.
      o  Signature and/or encryption algorithms.  Some key types may not
         support both signing and encryption.  Key usage may also be



Ylonen, et. al.         Expires January 12, 2004               [Page 11]

Internet-Draft        SSH Transport Layer Protocol             July 2003


         restricted by policy statements in e.g.  certificates.  In this
         case, different key types SHOULD be defined for the different
         policy alternatives.
      o  Encoding of signatures and/or encrypted data.  This includes
         but is not limited to padding, byte order, and data formats.

   The following public key and/or certificate formats are currently defined:

   ssh-dss              REQUIRED     sign    Simple DSS
   ssh-rsa              RECOMMENDED  sign    Simple RSA
   x509v3-sign-rsa      OPTIONAL     sign    X.509 certificates (RSA key)
   x509v3-sign-dss      OPTIONAL     sign    X.509 certificates (DSS key)
   spki-sign-rsa        OPTIONAL     sign    SPKI certificates (RSA key)
   spki-sign-dss        OPTIONAL     sign    SPKI certificates (DSS key)
   pgp-sign-rsa         OPTIONAL     sign    OpenPGP certificates (RSA key)
   pgp-sign-dss         OPTIONAL     sign    OpenPGP certificates (DSS key)

      Additional key types may be defined as specified in [SSH-ARCH].

      The key type MUST always be explicitly known (from algorithm
      negotiation or some other source).  It is not normally included in
      the key blob.

      Certificates and public keys are encoded as follows:

     string   certificate or public key format identifier
     byte[n]  key/certificate data

      The certificate part may have be a zero length string, but a
      public key is required.  This is the public key that will be used
      for authentication; the certificate sequence contained in the
      certificate blob can be used to provide authorization.

      Public key / certifcate formats that do not explicitly specify a
      signature format identifier MUST use the public key / certificate
      format identifier as the signature identifier.

   Signatures are encoded as follows:
     string    signature format identifier (as specified by the
               public key / cert format)
     byte[n]   signature blob in format specific encoding.


   The "ssh-dss" key format has the following specific encoding:

     string    "ssh-dss"
     mpint     p
     mpint     q



Ylonen, et. al.         Expires January 12, 2004               [Page 12]

Internet-Draft        SSH Transport Layer Protocol             July 2003


     mpint     g
     mpint     y

   Here the p, q, g, and y parameters form the signature key blob.

      Signing and verifying using this key format is done according to
      the Digital Signature Standard [FIPS-186] using the SHA-1 hash.  A
      description can also be found in [SCHNEIER].

   The resulting signature is encoded as follows:

     string    "ssh-dss"
     string    dss_signature_blob

      dss_signature_blob is encoded as a string containing r followed by
      s (which are 160 bits long integers, without lengths or padding,
      unsigned and in network byte order).

   The "ssh-rsa" key format has the following specific encoding:

     string    "ssh-rsa"
     mpint     e
     mpint     n

   Here the e and n parameters form the signature key blob.

      Signing and verifying using this key format is done according to
      [SCHNEIER] and [PKCS1] using the SHA-1 hash.

   The resulting signature is encoded as follows:

     string    "ssh-rsa"
     string    rsa_signature_blob

      rsa_signature_blob is encoded as a string containing s (which is
      an integer, without lengths or padding, unsigned and in network
      byte order).

      The "spki-sign-rsa" method indicates that the certificate blob
      contains a sequence of SPKI certificates.  The format of SPKI
      certificates is described in [RFC2693].  This method indicates
      that the key (or one of the keys in the certificate) is an RSA-
      key.

      The "spki-sign-dss".  As above, but indicates that the key (or one
      of the keys in the certificate) is a DSS-key.

      The "pgp-sign-rsa" method indicates the certificates, the public



Ylonen, et. al.         Expires January 12, 2004               [Page 13]

Internet-Draft        SSH Transport Layer Protocol             July 2003


      key, and the signature are in OpenPGP compatible binary format
      ([RFC2440]).  This method indicates that the key is an RSA-key.

      The "pgp-sign-dss".  As above, but indicates that the key is a
      DSS-key.

   5. Key Exchange

      Key exchange begins by each side sending lists of supported
      algorithms.  Each side has a preferred algorithm in each category,
      and it is assumed that most implementations at any given time will
      use the same preferred algorithm.  Each side MAY guess which
      algorithm the other side is using, and MAY send an initial key
      exchange packet according to the algorithm if appropriate for the
      preferred method.

      Guess is considered wrong, if:
      o  the kex algorithm and/or the host key algorithm is guessed
         wrong (server and client have different preferred algorithm),
         or
      o  if any of the other algorithms cannot be agreed upon (the
         procedure is defined below in Section Section 5.1).

      Otherwise, the guess is considered to be right and the
      optimistically sent packet MUST be handled as the first key
      exchange packet.

      However, if the guess was wrong, and a packet was optimistically
      sent by one or both parties, such packets MUST be ignored (even if
      the error in the guess would not affect the contents of the
      initial packet(s)), and the appropriate side MUST send the correct
      initial packet.

      Server authentication in the key exchange MAY be implicit.  After
      a key exchange with implicit server authentication, the client
      MUST wait for response to its service request message before
      sending any further data.

   5.1 Algorithm Negotiation

   Key exchange begins by each side sending the following packet:

     byte      SSH_MSG_KEXINIT
     byte[16]  cookie (random bytes)
     string    kex_algorithms
     string    server_host_key_algorithms
     string    encryption_algorithms_client_to_server
     string    encryption_algorithms_server_to_client



Ylonen, et. al.         Expires January 12, 2004               [Page 14]

Internet-Draft        SSH Transport Layer Protocol             July 2003


     string    mac_algorithms_client_to_server
     string    mac_algorithms_server_to_client
     string    compression_algorithms_client_to_server
     string    compression_algorithms_server_to_client
     string    languages_client_to_server
     string    languages_server_to_client
     boolean   first_kex_packet_follows
     uint32    0 (reserved for future extension)

      Each of the algorithm strings MUST be a comma-separated list of
      algorithm names (see ''Algorithm Naming'' in [SSH-ARCH]).  Each
      supported (allowed) algorithm MUST be listed in order of
      preference.

      The first algorithm in each list MUST be the preferred (guessed)
      algorithm.  Each string MUST contain at least one algorithm name.


         cookie
            The cookie MUST be a random value generated by the sender.
            Its purpose is to make it impossible for either side to
            fully determine the keys and the session identifier.

         kex_algorithms
            Key exchange algorithms were defined above.  The first
            algorithm MUST be the preferred (and guessed) algorithm.  If
            both sides make the same guess, that algorithm MUST be used.
            Otherwise, the following algorithm MUST be used to choose a
            key exchange method: iterate over client's kex algorithms,
            one at a time.  Choose the first algorithm that satisfies
            the following conditions:
            +  the server also supports the algorithm,
            +  if the algorithm requires an encryption-capable host key,
               there is an encryption-capable algorithm on the server's
               server_host_key_algorithms that is also supported by the
               client, and
            +  if the algorithm requires a signature-capable host key,
               there is a signature-capable algorithm on the server's
               server_host_key_algorithms that is also supported by the
               client.
            +  If no algorithm satisfying all these conditions can be
               found, the connection fails, and both sides MUST
               disconnect.

         server_host_key_algorithms
            List of the algorithms supported for the server host key.
            The server lists the algorithms for which it has host keys;
            the client lists the algorithms that it is willing to



Ylonen, et. al.         Expires January 12, 2004               [Page 15]

Internet-Draft        SSH Transport Layer Protocol             July 2003


            accept.  (There MAY be multiple host keys for a host,
            possibly with different algorithms.)

            Some host keys may not support both signatures and
            encryption (this can be determined from the algorithm), and
            thus not all host keys are valid for all key exchange
            methods.

            Algorithm selection depends on whether the chosen key
            exchange algorithm requires a signature or encryption
            capable host key.  It MUST be possible to determine this
            from the public key algorithm name.  The first algorithm on
            the client's list that satisfies the requirements and is
            also supported by the server MUST be chosen.  If there is no
            such algorithm, both sides MUST disconnect.

         encryption_algorithms
            Lists the acceptable symmetric encryption algorithms in
            order of preference.  The chosen encryption algorithm to
            each direction MUST be the first algorithm  on the client's
            list that is also on the server's list.  If there is no such
            algorithm, both sides MUST disconnect.

            Note that "none" must be explicitly listed if it is to be
            acceptable.  The defined algorithm names are listed in
            Section Section 4.3.

         mac_algorithms
            Lists the acceptable MAC algorithms in order of preference.
            The chosen MAC algorithm MUST be the first algorithm on the
            client's list that is also on the server's list.  If there
            is no such algorithm, both sides MUST disconnect.

            Note that "none" must be explicitly listed if it is to be
            acceptable.  The MAC algorithm names are listed in Section
            Figure 1.

         compression_algorithms
            Lists the acceptable compression algorithms in order of
            preference.  The chosen compression algorithm MUST be the
            first algorithm on the client's list that is also on the
            server's list.  If there is no such algorithm, both sides
            MUST disconnect.

            Note that "none" must be explicitly listed if it is to be
            acceptable.  The compression algorithm names are listed in
            Section Section 4.2.




Ylonen, et. al.         Expires January 12, 2004               [Page 16]

Internet-Draft        SSH Transport Layer Protocol             July 2003


         languages
            This is a comma-separated list of language tags in order of
            preference [RFC1766].  Both parties MAY ignore this list.
            If there are no language preferences, this list SHOULD be
            empty.

         first_kex_packet_follows
            Indicates whether a guessed key exchange packet follows.  If
            a guessed packet will be sent, this MUST be TRUE.  If no
            guessed packet will be sent, this MUST be FALSE.

            After receiving the SSH_MSG_KEXINIT packet from the other
            side, each party will know whether their guess was right.
            If the other party's guess was wrong, and this field was
            TRUE, the next packet MUST be silently ignored, and both
            sides MUST then act as determined by the negotiated key
            exchange method.  If the guess was right, key exchange MUST
            continue using the guessed packet.

      After the KEXINIT packet exchange, the key exchange algorithm is
      run.  It may involve several packet exchanges, as specified by the
      key exchange method.

   5.2 Output from Key Exchange

      The key exchange produces two values: a shared secret K, and an
      exchange hash H.  Encryption and authentication keys are derived
      from these.  The exchange hash H from the first key exchange is
      additionally used as the session identifier, which is a unique
      identifier for this connection.  It is used by authentication
      methods as a part of the data that is signed as a proof of
      possession of a private key.  Once computed, the session
      identifier is not changed, even if keys are later re-exchanged.


      Each key exchange method specifies a hash function that is used in
      the key exchange.  The same hash algorithm MUST be used in key
      derivation.  Here, we'll call it HASH.


      Encryption keys MUST be computed as HASH of a known value and K as
      follows:
      o  Initial IV client to server: HASH(K || H || "A" || session_id)
         (Here K is encoded as mpint and "A" as byte and session_id as
         raw data."A" means the single character A, ASCII 65).
      o  Initial IV server to client: HASH(K || H || "B" || session_id)
      o  Encryption key client to server: HASH(K || H || "C" ||
         session_id)



Ylonen, et. al.         Expires January 12, 2004               [Page 17]

Internet-Draft        SSH Transport Layer Protocol             July 2003


      o  Encryption key server to client: HASH(K || H || "D" ||
         session_id)
      o  Integrity key client to server: HASH(K || H || "E" ||
         session_id)
      o  Integrity key server to client: HASH(K || H || "F" ||
         session_id)

      Key data MUST be taken from the beginning of the hash output.  128
      bits (16 bytes) SHOULD be used for algorithms with variable-length
      keys.  For other algorithms, as many bytes as are needed are taken
      from the beginning of the hash value.  If the key length in longer
      than the output of the HASH, the key is extended by computing HASH
      of the concatenation of K and H and the entire key so far, and
      appending the resulting bytes (as many as HASH generates) to the
      key.  This process is repeated until enough key material is
      available; the key is taken from the beginning of this value.  In
      other words:

     K1 = HASH(K || H || X || session_id)   (X is e.g. "A")
     K2 = HASH(K || H || K1)
     K3 = HASH(K || H || K1 || K2)
     ...
     key = K1 || K2 || K3 || ...

      This process will lose entropy if the amount of entropy in K is
      larger than the internal state size of HASH.

   5.3 Taking Keys Into Use

      Key exchange ends by each side sending an SSH_MSG_NEWKEYS message.
      This message is sent with the old keys and algorithms.  All
      messages sent after this message MUST use the new keys and
      algorithms.


      When this message is received, the new keys and algorithms MUST be
      taken into use for receiving.


      This message is the only valid message after key exchange, in
      addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE
      messages.  The purpose of this message is to ensure that a party
      is able to respond with a disconnect message that the other party
      can understand if something goes wrong with the key exchange.
      Implementations MUST NOT accept any other messages after key
      exchange before receiving SSH_MSG_NEWKEYS.

     byte      SSH_MSG_NEWKEYS



Ylonen, et. al.         Expires January 12, 2004               [Page 18]

Internet-Draft        SSH Transport Layer Protocol             July 2003


   6. Diffie-Hellman Key Exchange

      The Diffie-Hellman key exchange provides a shared secret that can
      not be determined by either party alone.  The key exchange is
      combined with a signature with the host key to provide host
      authentication.


      In the following description (C is the client, S is the server; p
      is a large safe prime, g is a generator for a subgroup of GF(p),
      and q is the order of the subgroup; V_S is S's version string; V_C
      is C's version string; K_S is S's public host key; I_C is C's
      KEXINIT  message and I_S S's KEXINIT message which have been
      exchanged before this part begins):


      1.  C generates a random number x (1 < x < q) and computes e = g^x
          mod p.  C sends "e" to S.

      2.  S generates a random number y (0 < y < q) and computes f = g^y
          mod p.  S receives "e".  It computes K = e^y mod p, H =
          hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these
          elements are encoded according to their types; see below), and
          signature s on H with its private host key.  S sends "K_S || f
          || s" to C.  The signing operation may involve a second
          hashing operation.

      3.  C verifies that K_S really is the host key for S (e.g.  using
          certificates or a local database).  C is also allowed to
          accept the key without verification; however, doing so will
          render the protocol insecure against active attacks (but may
          be desirable for practical reasons in the short term in many
          environments).  C then computes K = f^x mod p, H = hash(V_C ||
          V_S || I_C || I_S || K_S || e || f || K), and verifies the
          signature s on H.

      Either side MUST NOT send or accept e or f values that are not in
      the range [1, p-1].  If this condition is violated, the key
      exchange fails.


      This is implemented with the following messages.  The hash
      algorithm for computing the exchange hash is defined by the method
      name, and is called HASH.  The public key algorithm for signing is
      negotiated with the KEXINIT messages.

   First, the client sends the following:




Ylonen, et. al.         Expires January 12, 2004               [Page 19]

Internet-Draft        SSH Transport Layer Protocol             July 2003


     byte      SSH_MSG_KEXDH_INIT
     mpint     e


   The server responds with the following:

     byte      SSH_MSG_KEXDH_REPLY
     string    server public host key and certificates (K_S)
     mpint     f
     string    signature of H

      The hash H is computed as the HASH hash of the concatenation of
      the following:

     string    V_C, the client's version string (CR and NL excluded)
     string    V_S, the server's version string (CR and NL excluded)
     string    I_C, the payload of the client's SSH_MSG_KEXINIT
     string    I_S, the payload of the server's SSH_MSG_KEXINIT
     string    K_S, the host key
     mpint     e, exchange value sent by the client
     mpint     f, exchange value sent by the server
     mpint     K, the shared secret

      This value is called the exchange hash, and it is used to
      authenticate the key exchange.  The exchange hash SHOULD be kept
      secret.


      The signature algorithm MUST be applied over H, not the original
      data.  Most signature algorithms include hashing and additional
      padding.  For example, "ssh-dss" specifies SHA-1 hashing; in that
      case, the data is first hashed with HASH to compute H, and H is
      then hashed with SHA-1 as part of the signing operation.

   6.1 diffie-hellman-group1-sha1

      The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman
      key exchange with SHA-1 as HASH, and the following group:

      The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894
      Pi + 129093 ).  Its hexadecimal value is:

         FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
         29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
         EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
         E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
         EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
         FFFFFFFF FFFFFFFF.



Ylonen, et. al.         Expires January 12, 2004               [Page 20]

Internet-Draft        SSH Transport Layer Protocol             July 2003


      In decimal, this value is:

         179769313486231590770839156793787453197860296048756011706444
         423684197180216158519368947833795864925541502180565485980503
         646440548199239100050792877003355816639229553136239076508735
         759914822574862575007425302077447712589550957937778424442426
         617334727629299387668709205606050270810842907692932019128194
         467627007.

      The generator used with this prime is g = 2.  The group order q is
      (p - 1) / 2.

      This group was taken from the ISAKMP/Oakley specification, and was
      originally generated by Richard Schroeppel at the University of
      Arizona.  Properties of this prime are described in [Orm96].

   7. Key Re-Exchange

      Key re-exchange is started by sending an SSH_MSG_KEXINIT packet
      when not already doing a key exchange (as described in Section
      Section 5.1).  When this message is received, a party MUST respond
      with its own SSH_MSG_KEXINIT message except when the received
      SSH_MSG_KEXINIT already was a reply.  Either party MAY initiate
      the re-exchange, but roles MUST NOT be changed (i.e., the server
      remains the server, and the client remains the client).


      Key re-exchange is performed using whatever encryption was in
      effect when the exchange was started.  Encryption, compression,
      and MAC methods are not changed before a new SSH_MSG_NEWKEYS is
      sent after the key exchange (as in the initial key exchange).  Re-
      exchange is processed identically to the initial key exchange,
      except for the session identifier that will remain unchanged.  It
      is permissible to change some or all of the algorithms during the
      re-exchange.  Host keys can also change.  All keys and
      initialization vectors are recomputed after the exchange.
      Compression and encryption contexts are reset.


      It is recommended that the keys are changed after each gigabyte of
      transmitted data or after each hour of connection time, whichever
      comes sooner.  However, since the re-exchange is a public key
      operation, it requires a fair amount of processing power and
      should not be performed too often.


      More application data may be sent after the SSH_MSG_NEWKEYS packet
      has been sent; key exchange does not affect the protocols that lie



Ylonen, et. al.         Expires January 12, 2004               [Page 21]

Internet-Draft        SSH Transport Layer Protocol             July 2003


      above the SSH transport layer.

   8. Service Request

      After the key exchange, the client requests a service.  The
      service is identified by a name.  The format of names and
      procedures for defining new names are defined in [SSH-ARCH].


      Currently, the following names have been reserved:

     ssh-userauth
     ssh-connection

      Similar local naming policy is applied to the service names, as is
      applied to the algorithm names; a local service should use the
      "servicename@domain" syntax.

     byte      SSH_MSG_SERVICE_REQUEST
     string    service name

      If the server rejects the service request, it SHOULD send an
      appropriate SSH_MSG_DISCONNECT message and MUST disconnect.


      When the service starts, it may have access to the session
      identifier generated during the key exchange.


      If the server supports the service (and permits the client to use
      it), it MUST respond with the following:

     byte      SSH_MSG_SERVICE_ACCEPT
     string    service name

      Message numbers used by services should be in the area reserved
      for them (see Section 6 in [SSH-ARCH]).  The transport level will
      continue to process its own messages.


      Note that after a key exchange with implicit server
      authentication, the client MUST wait for response to its service
      request message before sending any further data.

   9. Additional Messages

      Either party may send any of the following messages at any time.




Ylonen, et. al.         Expires January 12, 2004               [Page 22]

Internet-Draft        SSH Transport Layer Protocol             July 2003


   9.1 Disconnection Message

     byte      SSH_MSG_DISCONNECT
     uint32    reason code
     string    description [RFC2279]
     string    language tag [RFC1766]

      This message causes immediate termination of the connection.  All
      implementations MUST be able to process this message; they SHOULD
      be able to send this message.

      The sender MUST NOT send or receive any data after this message,
      and the recipient MUST NOT accept any data after receiving this
      message.  The description field gives a more specific explanation
      in a human-readable form.  The error code gives the reason in a
      more machine-readable format (suitable for localization), and can
      have the following values:

     #define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT      1
     #define SSH_DISCONNECT_PROTOCOL_ERROR                   2
     #define SSH_DISCONNECT_KEY_EXCHANGE_FAILED              3
     #define SSH_DISCONNECT_RESERVED                         4
     #define SSH_DISCONNECT_MAC_ERROR                        5
     #define SSH_DISCONNECT_COMPRESSION_ERROR                6
     #define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE            7
     #define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED   8
     #define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE          9
     #define SSH_DISCONNECT_CONNECTION_LOST                 10
     #define SSH_DISCONNECT_BY_APPLICATION                  11
     #define SSH_DISCONNECT_TOO_MANY_CONNECTIONS            12
     #define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER          13
     #define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE  14
     #define SSH_DISCONNECT_ILLEGAL_USER_NAME               15

      If the description string is displayed, control character
      filtering discussed in [SSH-ARCH] should be used to avoid attacks
      by sending terminal control characters.

   9.2 Ignored Data Message

     byte      SSH_MSG_IGNORE
     string    data

      All implementations MUST understand (and ignore) this message at
      any time (after receiving the protocol version).  No
      implementation is required to send them.  This message can be used
      as an additional protection measure against advanced traffic
      analysis techniques.



Ylonen, et. al.         Expires January 12, 2004               [Page 23]

Internet-Draft        SSH Transport Layer Protocol             July 2003


   9.3 Debug Message

     byte      SSH_MSG_DEBUG
     boolean   always_display
     string    message [RFC2279]
     string    language tag [RFC1766]

      All implementations MUST understand this message, but they are
      allowed to ignore it.  This message is used to pass the other side
      information that may help debugging.  If always_display is TRUE,
      the message SHOULD be displayed.  Otherwise, it SHOULD NOT be
      displayed unless debugging information has been explicitly
      requested by the user.


      The message doesn't need to contain a newline.  It is, however,
      allowed to consist of multiple lines separated by CRLF (Carriage
      Return - Line Feed) pairs.


      If the message string is displayed, terminal control character
      filtering discussed in [SSH-ARCH] should be used to avoid attacks
      by sending terminal control characters.

   9.4 Reserved Messages

      An implementation MUST respond to all unrecognized messages with
      an SSH_MSG_UNIMPLEMENTED message in the order in which the
      messages were received.  Such messages MUST be otherwise ignored.
      Later protocol versions may define other meanings for these
      message types.

     byte      SSH_MSG_UNIMPLEMENTED
     uint32    packet sequence number of rejected message


   10. Summary of Message Numbers

      The following message numbers have been defined in this protocol:

     #define SSH_MSG_DISCONNECT             1
     #define SSH_MSG_IGNORE                 2
     #define SSH_MSG_UNIMPLEMENTED          3
     #define SSH_MSG_DEBUG                  4
     #define SSH_MSG_SERVICE_REQUEST        5
     #define SSH_MSG_SERVICE_ACCEPT         6

     #define SSH_MSG_KEXINIT                20



Ylonen, et. al.         Expires January 12, 2004               [Page 24]

Internet-Draft        SSH Transport Layer Protocol             July 2003


     #define SSH_MSG_NEWKEYS                21

     /* Numbers 30-49 used for kex packets.
        Different kex methods may reuse message numbers in
        this range. */

     #define SSH_MSG_KEXDH_INIT             30
     #define SSH_MSG_KEXDH_REPLY            31


   11. Security Considerations

      This protocol provides a secure encrypted channel over an insecure
      network.  It performs server host authentication, key exchange,
      encryption, and integrity protection.  It also derives a unique
      session id that may be used by higher-level protocols.

      Full security considerations for this protocol are provided in
      Section 8 of [SSH-ARCH]

   12. Intellectual Property

      The IETF takes no position regarding the validity or scope of any
      intellectual property or other rights that might be claimed to
      pertain to the implementation or use of the technology described
      in this document or the extent to which any license under such
      rights might or might not be available; neither does it represent
      that it has made any effort to identify any such rights.
      Information on the IETF's procedures with respect to rights in
      standards-track and standards-related documentation can be found
      in BCP-11.  Copies of claims of rights made available for
      publication and any assurances of licenses to be made available,
      or the result of an attempt made to obtain a general license or
      permission for the use of such proprietary rights by implementers
      or users of this specification can be obtained from the IETF
      Secretariat.

      The IETF has been notified of intellectual property rights claimed
      in regard to some or all of the specification contained in this
      document.  For more information consult the online list of claimed
      rights.

   13. Additional Information

      The current document editor is: Darren.Moffat@Sun.COM.  Comments
      on this internet draft should be sent to the IETF SECSH working
      group, details at: http://ietf.org/html.charters/secsh-
      charter.html



Ylonen, et. al.         Expires January 12, 2004               [Page 25]

Internet-Draft        SSH Transport Layer Protocol             July 2003


References

      [FIPS-186]      Federal Information Processing Standards
                      Publication, ., "FIPS PUB 186, Digital Signature
                      Standard", May 1994.

      [Orm96]         Orman, H., "The Okaley Key Determination Protcol
                      version1, TR97-92", 1996.

      [RFC2459]       Housley, R., Ford, W., Polk, W. and D. Solo,
                      "Internet X.509 Public Key Infrastructure
                      Certificate and CRL Profile", RFC 2459, January
                      1999.

      [RFC1034]       Mockapetris, P., "Domain names - concepts and
                      facilities", STD 13, RFC 1034, Nov 1987.

      [RFC1766]       Alvestrand, H., "Tags for the Identification of
                      Languages", RFC 1766, March 1995.

      [RFC1950]       Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
                      Format Specification version 3.3", RFC 1950, May
                      1996.

      [RFC1951]       Deutsch, P., "DEFLATE Compressed Data Format
                      Specification version 1.3", RFC 1951, May 1996.

      [RFC2279]       Yergeau, F., "UTF-8, a transformation format of
                      ISO 10646", RFC 2279, January 1998.

      [RFC2104]       Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
                      Keyed-Hashing for Message Authentication", RFC
                      2104, February 1997.

      [RFC2119]       Bradner, S., "Key words for use in RFCs to
                      Indicate Requirement Levels", BCP 14, RFC 2119,
                      March 1997.

      [RFC2144]       Adams, C., "The CAST-128 Encryption Algorithm",
                      RFC 2144, May 1997.

      [RFC2440]       Callas, J., Donnerhacke, L., Finney, H. and R.
                      Thayer, "OpenPGP Message Format", RFC 2440,
                      November 1998.

      [RFC2693]       Ellison, C., Frantz, B., Lampson, B., Rivest, R.,
                      Thomas, B. and T. Ylonen, "SPKI Certificate
                      Theory", RFC 2693, September 1999.



Ylonen, et. al.         Expires January 12, 2004               [Page 26]

Internet-Draft        SSH Transport Layer Protocol             July 2003


      [SCHNEIER]      Schneier, B., "Applied Cryptography Second
                      Edition: protocols algorithms and source in code
                      in C", 1996.

      [TWOFISH]       Schneier, B., "The Twofish Encryptions Algorithm:
                      A 128-Bit Block Cipher, 1st Edition", March 1999.

      [SSH-ARCH]      Ylonen, T., "SSH Protocol Architecture", I-D
                      draft-ietf-architecture-14.txt, July 2003.

      [SSH-TRANS]     Ylonen, T., "SSH Transport Layer Protocol", I-D
                      draft-ietf-transport-16.txt, July 2003.

      [SSH-USERAUTH]  Ylonen, T., "SSH Authentication Protocol", I-D
                      draft-ietf-userauth-17.txt, July 2003.

      [SSH-CONNECT]   Ylonen, T., "SSH Connection Protocol", I-D draft-
                      ietf-connect-17.txt, July 2003.

      [SSH-NUMBERS]   Lehtinen, S. and D. Moffat, "SSH Protocol Assigned
                      Numbers", I-D draft-ietf-secsh-assignednumbers-
                      03.txt, July 2003.


Authors' Addresses

   Tatu Ylonen
   SSH Communications Security Corp
   Fredrikinkatu 42
   HELSINKI  FIN-00100
   Finland

   EMail: ylo@ssh.com


   Tero Kivinen
   SSH Communications Security Corp
   Fredrikinkatu 42
   HELSINKI  FIN-00100
   Finland

   EMail: kivinen@ssh.com


   Markku-Juhani O. Saarinen
   University of Jyvaskyla





Ylonen, et. al.         Expires January 12, 2004               [Page 27]

Internet-Draft        SSH Transport Layer Protocol             July 2003


   Timo J. Rinne
   SSH Communications Security Corp
   Fredrikinkatu 42
   HELSINKI  FIN-00100
   Finland

   EMail: tri@ssh.com


   Sami Lehtinen
   SSH Communications Security Corp
   Fredrikinkatu 42
   HELSINKI  FIN-00100
   Finland

   EMail: sjl@ssh.com



































Ylonen, et. al.         Expires January 12, 2004               [Page 28]

Internet-Draft        SSH Transport Layer Protocol             July 2003


Full Copyright Statement

      Copyright (C) The Internet Society (2003).  All Rights Reserved.

      This document and translations of it may be copied and furnished
      to others, and derivative works that comment on or otherwise
      explain it or assist in its implementation may be prepared,
      copied, published and distributed, in whole or in part, without
      restriction of any kind, provided that the above copyright notice
      and this paragraph are included on all such copies and derivative
      works.  However, this document itself may not be modified in any
      way, such as by removing the copyright notice or references to the
      Internet Society or other Internet organizations, except as needed
      for the purpose of developing Internet standards in which case the
      procedures for copyrights defined in the Internet Standards
      process must be followed, or as required to translate it into
      languages other than English.

      The limited permissions granted above are perpetual and will not
      be revoked by the Internet Society or its successors or assigns.

      This document and the information contained herein is provided on
      an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
      ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
      IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
      THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

      Funding for the RFC Editor function is currently provided by the
      Internet Society.



















Ylonen, et. al.         Expires January 12, 2004               [Page 29]