Subject: I-D ACTION:draft-ietf-secsh-userauth-19.txt

From: [email-masked]
Date: Thu, 20 May 2004 16:02:06 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Authentication Protocol
	Author(s)	: T. Ylonen, C. Lonvick
	Filename	: draft-ietf-secsh-userauth-19.txt
	Pages		: 29
	Date		: 2004-5-20
	
SSH is a protocol for secure remote login and other secure network
   services over an insecure network.  This document describes the SSH
   authentication protocol framework and public key, password, and
   host-based client authentication methods.  Additional authentication
   methods are described in separate documents.  The SSH authentication
   protocol runs on top of the SSH transport layer protocol and provides
   a single authenticated tunnel for the SSH connection protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-19.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-userauth-19.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-userauth-19.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: der Mouse <[email-masked]>
Date: Fri, 21 May 2004 05:31:47 -0400 (EDT)

> http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-19.txt

Is it just me, or has this accidentally had a copy of
draft-ietf-secsh-transport-18.txt appended to it?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 21 May 2004 06:44:14 -0700 (PDT)

Hi Folks,

First, I'd also like to thank Darren for getting these IDs to this state.
I think that we're close to finishing them so please work with me to get
these things finalized.

The most current set of IDs (in the ID repository) are almost identical to
the prior set submitted by Darren.  In those IDs, Darren cleared up many
of the IESG comments.  When Darren turned things over to me, he gave me
copies of the previous IDs as well.  Just to make sure that we've
addressed most of the IESG comments, I've used htmlwdiff to show the
differences between older and current drafts.  For example, in the ARCH
ID, the comments were addressed between 14 and 15.  I made minor changes
to 15 and submitted it as 16.  Therefore, the changes to address the IESG
comments (made by Darren) will be shown in the differences between 14 and
16.

In each of these "diffs" documents, I've also inserted "Issues" which are
the IESG comments and what I believe to be pointers to the resolutions to
them.  For example, in ARCH, I've inserted (in blue)
  ISSUE 20: IESG - Architecture - Authors
with the specific comment from the IESG.  The markup (red strikeout, green
insertion) should show the resolution.  I would like the WG to review
these and send me notes to indicate that the "Issue" I identified have
indeed been resolved.  If one of these "Issues" has not been resolved,
I'll add it to the Issue Tracker and we'll work on it in later drafts.

The prior, current and diff documents are here:
  http://www.employees.org/~lonvick/ssh/

The most recently created documents are:
http://www.employees.org/~lonvick/ssh/draft-ietf-secsh-architecture-16.txt
http://www.employees.org/~lonvick/ssh/draft-ietf-secsh-assignednumbers-06.txt
http://www.employees.org/~lonvick/ssh/draft-ietf-secsh-connect-19.txt
http://www.employees.org/~lonvick/ssh/draft-ietf-secsh-transport-18.txt
http://www.employees.org/~lonvick/ssh/draft-ietf-secsh-userauth-19.txt
These are similar to what are in the ID repository with some slight
differences (date, some authorship stuff, etc.) but the content is the
same.

The prior set of documents are here.  These did not have any resolutions
to IESG comments.
http://www.employees.org/~lonvick/ssh/draft-ietf-secsh-architecture-14.txt
http://www.employees.org/~lonvick/ssh/draft-ietf-secsh-assignednumbers-04.txt
http://www.employees.org/~lonvick/ssh/draft-ietf-secsh-connect-17.txt
http://www.employees.org/~lonvick/ssh/draft-ietf-secsh-transport-16.txt
http://www.employees.org/~lonvick/ssh/draft-ietf-secsh-userauth-17.txt

The "diffs" are here:
http://www.employees.org/~lonvick/ssh/architecture-14-16.html
http://www.employees.org/~lonvick/ssh/assignednumbers-04-06.html
http://www.employees.org/~lonvick/ssh/connect-17-19.html
http://www.employees.org/~lonvick/ssh/transport-16-18.html
http://www.employees.org/~lonvick/ssh/userauth-17-19.html

Please look them over and send a note back either saying
 - Chris, "ISSUE 20: IESG - Architecture - Authors" appears to be
   resolved.
or
 - Chris, "ISSUE 19: IESG - Transport - ShouldMust" doesn't appear
   to be resolved.
If I get comments that they're resolved then they won't be entered into
the Issue Tracking system.  One note, the pages and sections referenced by
the IESG comments will be using the red (struck) page and section numbers,
not the new, green ones.

Thanks,
Chris

---

From: Damien Miller <[email-masked]>
Date: Sun, 23 May 2004 15:58:10 +1000

Section 7.1 is seriously broken by these changes. The new text reads:

> The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key
>    exchange with SHA-1 as HASH, and Oakley group 14 [RFC3526] (2048-bit
>    MODP Group).  It is included below in hexadecimal and decimal.

"diffie-hellman-group1-sha1" isn't rfc3526 group 14, it is rfc2904
group 2. This group represented by this name can't change without
breaking compatibility with every SSH2 implementation that uses it.

Worse, the changed wording doesn't even agree with the numeric group
immediately below it, which remains rfc2904/group2.

The right way to change would be to recommend the use of DH-GEX or
adopt Peter Gutmann's "diffie-hellman-groupN-sha1" proposal to make
a "diffie-hellman-group14-sha1" (though I'd prefer a shorter name,
while we are making changes).

To retain interoperability with the current installed base, support
for the current group would have to stay a MUST regardless.

-d

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 24 May 2004 12:49:09 -0400

On Sunday, May 23, 2004 15:58:10 +1000 Damien Miller <[email-masked]> 
wrote:

> group 2.

RFC2904 is "AAA Authorization Framework"; it does not define any groups.
It took me a while to figure out what the typo was; the correct reference 
is to RFC2409 section 6.2.

> This group represented by this name can't change without

Agreed.

> immediately below it, which remains rfc2904/group2.

Agreed.  The wording should be fixed:

- Oakley group 14 [RFC3526] (2048-bit MODP Group).
+ Oakley group 2 [RFC2409] (section 6.2).

Additionally, IMHO the group should _not_ be copied in the document. 
Verify that the value in RFC2409 is correct, and incorporate it by 
reference.  This precludes any possibility of confusion arising as a result 
of an incorrect value appearing in our document.

> while we are making changes).

I was under the impression that we had already been over this issue, and 
that we were going to recommend implementation of DH-GEX, and that that 
satisfied the IESG's concern.

> for the current group would have to stay a MUST regardless.

I agree.  I would not object to also making DH-GEX a MUST.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Derek Fawcus <[email-masked]>
Date: Mon, 24 May 2004 22:05:09 +0100

> I agree.  I would not object to also making DH-GEX a MUST.

Well I would - sort of.

I've no problem with diffie-hellman-group-exchange-sha1 being a MUST
(i.e. REQUIRED),  but it seems silly to have both as MUST.

I'd say if DH-GEX is made a MUST,  then diffie-hellman-group1-sha1 should
be reduced to a SHOULD (i.e. RECOMMENDED).

DF

---

From: [email-masked] (Niels Möller)
Date: 24 May 2004 23:37:55 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> I was under the impression that we had already been over this issue,
> and that we were going to recommend implementation of DH-GEX, and that
> that satisfied the IESG's concern.

I think it would make a lot of sense to add one or two larger fixed
groups, besides DH-GEX. Main argument is that it's simpler (=> less
opportunity for implementation bugs, which is important for any
security protocol) than DH-GEX. The choice between a large fix group
and DH-GEX depends on what you think is most dangerous: Expensive
discrete log table attacks on a fix group, or additional protocol
complexity.

(This is the same position as I had last time this was discussed. I
don't remember if there were ever was a consencus).

Regards,
/Niels

---

From: Markus Friedl <[email-masked]>
Date: Tue, 25 May 2004 00:07:16 +0200

> be reduced to a SHOULD (i.e. RECOMMENDED).

I'd say that changing things now makes not sense at all.

It's been a while since last call, but it seems
nobody cares.

---

From: Damien Miller <[email-masked]>
Date: Wed, 26 May 2004 02:35:55 +1000

> is to RFC2409 section 6.2.

Sorry, my bad. Apologies.

> satisfied the IESG's concern.

Yes, I thought that all of these outstanding issues (DH-GEX, X.509 key
formats, etc.) were to be addressed by issuing separate drafts and that
we had arrived at a rough consensus to not delay the current drafts any
more.

-d

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 25 May 2004 11:46:21 -0700 (PDT)

Hi Folks,

I've just sent updated IDs to the ID Editor.  I evidently made a faux pas
by submitting all of the IDs bundled in a single email rather than
individually.  She asked me to resubmit them individually to straighten
out the problem of having transport appended to userauth.  (My apologies
to the ID Editor for that.)  I had been editing them to get the references
worked out (xml2rfc likes things _just_ so) and correcting some spelling
and grammar so I just updated everything.  There are no substantiative
changes between this set and the last.

I appreciate the ongoing discussions and I'll incorporate the group
consensus into the next set of revisions.

Unfortunately the server I had been using to display the diffs between
versions is unexpectedly going away.  I'm looking around for a new home
now so please bear with me and I'll start posting diffs again.  (Anyone
care to volunteer some space? :-)

Thanks,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 25 May 2004 20:07:42 -0700 (PDT)

Hi,

I'm still doing some reference cleanup and found that both Arch and
Transport reference FIPS 186 (1994).  Should those both reference FIPS
186-1 (1998) instead?

Thanks,
Chris

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 26 May 2004 10:55:56 -0400

[FIPS 186-X is the federal digital signature standard.]

As best as I can tell from some quick googling, it looks like:

FIPS 186 specified DSA.
FIPS 186-1 added RSA as an additional approved algorithm.
FIPS 186-2 added ECC as an additional approved algorithm.

And if that wasn't enough, there's now a "FIPS 186-2 with Change
Notice 1 dated October 5, 2001"

Note that the ssh documents and protocol use "dss" to refer to "dsa",
which was unambiguous until 186-1 came out..

I have not found any mention of changes to DSA in -1 or -2, but "186-2
+ Change Notice 1" mentions some adjustments to recommended DSA key
lengths and random number generation techniques.

Highlights:

    Section 4 of FIPS 186-2 specifies that the prime modulus p of DSA is
    defined for the range of prime integers 2^(L-1) < p < 2^L , where 512 <
    L < 1024 and L is a multiple of 64. This change notice specifies that
    L should assume only the value 1024 for DSA as specified in FIPS
    186-2, i.e., the prime modulus p should be defined in the range 
    2^1023 < p < 2^1024 .

(cut & pasted from PDF page 73 / document page 71 with correction of
formulas)

and:

    Recently, an unpublished attack on DSA3 was found that relies on the
    non-uniformity of the pseudorandom number generators (PRNGs) specified
    in Appendix 3 of the standard. The attack has a workfactor of 2^64 and
    requires 2^22 known signatures. This attack can be defended against by
    either limiting the number of signatures created using a specific key
    pair to no more than 2 million signatures while using the PRNGs
    specified in FIPS 186-2, or by modifying the PRNGs.

references:

http://csrc.nist.gov/cryptval/dss.htm
http://csrc.nist.gov/cryptval/dss/fr000215.html

							- Bill