Subject: Secure Shell: Milestone Update.

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 16 Mar 2005 21:03:56 -0500

As mentioned in our meeting session last week, our milestones are
extremely stale because we've been quasi-inactive until issues out of
our control were resolved

Now that the core drafts have apparently been unwedged, I propose to
update our active milestones as follows:

DELETE:

Drop            Agent draft ready for last call
Drop            Publish draft on X.509v3/pkix support

Update:

Apr 05          GSSAPI draft ready for last call
Apr 05          Resurrect and last-call newmodes
Apr 05          Resurrect and last-call secsh-break
Apr 05          File transfer draft ready for last call
May 05          IESG approval of core drafts

We have a large number of nearly complete extensions drafts which
expired while the core drafts were wedged.  Most just require a little
wordsmithing and process tweaking before they can move forward.  I'd
like to get those done soon so that we can *really* go inactive.

I'm proposing to toss two much-requested items over the side because
we've had several attempts at writing them fizzle due to lack of
energy.  The appearance of a volunteer to write them with a committed
completion date could well bring them back but I'm not holding my
breath.

On the other hand, in reviewing RFC2026's requirements for Draft
Standard,
it is apparent that we are pretty much already there:

   A specification from which at least two independent and interoperable
   implementations from different code bases have been developed, and
   for which sufficient successful operational experience has been
   obtained, may be elevated to the "Draft Standard" level. 

The one thing we are missing is, of course:

   A specification shall remain at the Proposed Standard level for at
   least six (6) months.

The fine print:

   The Working Group chair is responsible for documenting the specific
   implementations which qualify the specification for Draft or Internet
   Standard status along with documentation about testing of the
   interoperation of these implementations.  The documentation must
   include information about the support of each of the individual
   options and features.  This documentation should be submitted to the
   Area Director with the protocol action request. (see Section 6)

*IF* I can find a volunteer willing to produce the above documentation
for two (or more) SSHv2 implementations, I'll be inclined to add an
additional:

Jan 06		Submit documentation to Security AD required to advance 		secure
shell protocol core to Draft Standard.

Comments?  I'd like to send these in by next week.

					- Bill

---

From: Jon Bright <[email-masked]>
Date: Thu, 17 Mar 2005 08:36:12 +0100

> completion date could well bring them back but I'm not holding my

How much work is needed on the Agent draft?  I'd be prepared to put some 
time into it rather than see it die, but I don't know what its most 
recent status was.  I know I've managed to create an interoperable 
implementation from an old version I found...

-- 
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com

---

From: Jacob Nevins <[email-masked]>
Date: Thu, 17 Mar 2005 12:51:14 +0000

> Apr 05          File transfer draft ready for last call
  [...]
> like to get those done soon so that we can *really* go inactive.

I notice there's been no mention of the publickeyfile draft. I'm not
aware of anything seriously wrong with this document, although I'm not
intimately familiar with it. Is there sufficient interest to get it
cleaned up for publication?

Skimming through draft-ietf-secsh-publickeyfile-05, the only concern I
immediately have is the unspecified "interim periods" and "transition
periods", such as in the following:

| 3.3  Key File Header
     [...]
|    Existing implementations may not correctly handle unrecognized
|    fields. During a transition period, implementations SHOULD generate
|    key file headers that contain only a Subject field followed by a
|    Comment field.

and

| 3.3.2  Comment Header
     [...]
|    Currently, common practice is to quote the Header-value of the
|    Comment, and some existing implementations fail if these quotes are
|    omitted.
| 
|    Compliant implementations MUST function correctly if the quotes are
|    omitted.
| 
|    During an interim period implementations MAY include the quotes. If
|    the first and last characters of the Header-value are matching
|    quotes, implementations SHOULD remove them before using the value.

Are implementations for which these would cause trouble still worth
humouring, or can these be relegated to historical notes or deleted
entirely?

If not, we need to replace the "interim periods" with something else.

---

From: Jacob Nevins <[email-masked]>
Date: Thu, 17 Mar 2005 13:01:20 +0000

> implementation from an old version I found...

From a skim of draft-ietf-secsh-agent-02, at least:

| The client can add a new private key to the agent with the following
| message. Using this message over the net has security implications, and
| the implementation SHOULD warn the user before decryption or sending the
| private key. (XXX how does ssh-add detect this condition?)

| XXX Additional key-types (for private keys), for example "ssh-rsa-
| encrypted"?

|    /* Argument is string defining the allowed forwarding steps for
|       this key. XXX define this. */
|    #define SSH_AGENT_CONSTRAINT_FORWARDING_PATH        100

---

From: der Mouse <[email-masked]>
Date: Thu, 17 Mar 2005 08:41:19 -0500 (EST)

>    The Working Group chair is responsible for documenting the
>    specific implementations which qualify the specification for Draft
>    or Internet Standard status along with documentation about testing
>    of the interoperation of these implementations.

> *IF* I can find a volunteer willing to produce the above
> documentation for two (or more) SSHv2 implementations,

Well, I have an independent implementation of much of it which I'd be
happy to do interop testing of if anyone else would care to collaborate
on it.  My code is known to work as a client for basic use (remote
login, simple remote commands) against some small number of OpenSSH
servers (that being what ships with modern NetBSD), but I'd like to
test it against some other implementations.  (I can do OpenSSH client
against my server - I just haven't yet.)

Whether this can happen "by next week" is doubtful....

/~\ 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: Bill Sommerfeld <[email-masked]>
Date: Thu, 17 Mar 2005 09:38:05 -0500

> Whether this can happen "by next week" is doubtful....

to clarify:

If we want to propose to the IESG that we keep the WG active in order to
promptly progress to Draft, I need signs that people are willing to do
the required work.  
Multiple volunteers for this would be good.

Because of the required six month "soak time" at Proposed, anyone
interested in doing this work will have a minimum of six months to get
this done.

							- Bill

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 17 Mar 2005 08:01:33 -0700

Oskari Saarenmaa is co-authoring the x.509 draft with me.
He has a first cut that he is reviewing, and then we will
publish the (extremely short) draft.

Thanks,

Joseph

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 17 Mar 2005 12:00:50 -0500

> publish the (extremely short) draft.

i'll restore the milestones if you can promise a publication date for
the draft.

---

From: Jon Bright <[email-masked]>
Date: Thu, 17 Mar 2005 18:24:32 +0100

> Well, I have an independent implementation of much of it which I'd be

I have an independent client implementation.  I'd be happy to do and 
document interop testing.  What level of documentation is needed?

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 17 Mar 2005 14:11:48 -0500

> document interop testing.  What level of documentation is needed?

See the "Implementation reports" filed in:

http://www.ietf.org/IESG/implementation.html

Some of these are very informal, but as with everything else in the IETF
there has been increasing formality over time.  There's some history
here; see, in particular,
http://www.iab.org/appeals/snmpv2smi-appeal.html, which caused RFC2026
to specifically call for feature-by-feature testing.

In our case, the protocol is large and complex and has a large number of
optional and occasionally-used features.  I think the way to go would
be:

 1) go through the documents, coming up with a list of distinct
features.
Post this feature list to the WG for review.

 2) based on this list, send out an implementation survey asking, for
each feature:
	- have you implemented it?
	- has it successfully interoperated with another implementation
		(and, if so, who?)

Separate client and server surveys may be appropriate.

 3) collect survey responses

 4) figure out which features don't have coverage, and either prod
implementors to fill in the gap or decide the gap isn't a problem    
(stripping/deprecating the feature).

Some working groups have held interoperability tests, either
at/concurrent with IETF meetings, independently, or at other events. 
Given that many of our implementors have very limited travel/expense
budgets, pairwise interoperability testing over the internet by mutual
arrangement may be the best bet.

---

From: Jon Bright <[email-masked]>
Date: Thu, 17 Mar 2005 20:21:15 +0100

> http://www.ietf.org/IESG/implementation.html

OK, that doesn't seem too onerous.

> to specifically call for feature-by-feature testing.

If no-one else volunteers, I'll see if I can work up a list of features 
in the next few days.

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 17 Mar 2005 17:02:06 -0500

> | XXX Additional key-types (for private keys), for example "ssh-rsa-

Besides the XXX questions, there's a broader architectural question
involved with agent forwarding.

Namely, the SSH_AGENT_ADD_KEY request involves sending a valuable
private signature key with normally unbounded lifetime over the wire
protected only by SSH's underlying cryptographic channel.  This exposes
the private key far more than most protocols, and
precludes use of hardware tokens (such as smart cards) which allow
cryptographic operations to be requested without providing all users
with a copy of the key.

A couple possible alternatives:

 1) Some sort of proxy key arrangement such that the private keys don't
move and instead the signing requests move to the key rather than the
key move to the "root" agent.

 2) Some sort of ticket/certificate style arragement where the long term
key at a remote agent client is used to sign a certificate "delgating"
to a temporary agent key for a limited time.

 3) if the agent is the only trusted one and the remote system is not
trusted to see the cleartext private key, the key could be stored
remotely in encrypted form and decrypted
by the agent (using a passphrase or other means).  (very different use
model.)

There's also the "mission creep" question of whether the agent should
act as a proxy for other forms of authentication (gssapi/kerberos/...)

							- Bill

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 17 Mar 2005 15:52:00 -0700

> key move to the "root" agent.

Outside of the implementation specific issue of how to tell
the 'root' agent about key material, I believe the agent
protocol can operate in this mode.

If an implementation provides some other way to tell the agent
about key material and how to access it, the ADD_KEY command
is not necessary.

For example, the agent running on my local machine could be told
about my smart cards and private keys (through some implementation
specific means.)

Then, agent clients would send "SSH_AGENT_PRIVATE_KEY_OP" with
"sign" as the operation to the agent, which eventually gets
forwarded to my local agent, where it access the smart card
to make the signature.

Thanks,

Joseph

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 17 Mar 2005 20:03:17 -0500

> cleaned up for publication?

I suspect there may be and I'll be happy to add a May 05 milestone for
it when the current document editor responds to the mail I just sent.

---

From: der Mouse <[email-masked]>
Date: Thu, 17 Mar 2005 21:18:57 -0500 (EST)

> [T]here's a broader architectural question involved with agent
> forwarding.

> protected only by SSH's underlying cryptographic channel.

True, as far as it goes.

> This exposes the private key far more than most protocols,

True.

> and precludes use of hardware tokens (such as smart cards) which
> allow cryptographic operations to be requested without providing all
> users with a copy of the key.

False, fortunately.

There is no reason why SSH_AGENT_ADD_KEY has to be the only mechanism
for rendering the agent capable of handling a PRIVATE_KEY_OP request.
An agent could easily have some private channel to a smartcard; such an
agent might well come up with the appropriate key already installed, or
might have it appear mid-run (as if some other client had added it, as
far as all clients are concerned).

It is probably beyond our scope to try to define how such an agent
might talk to its smartcard or whatever, or how it would be configured
to do so - but there is nothing in what we've got that prevents it from
being done if someone cares to.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 17 Mar 2005 20:21:42 -0700

> i'll restore the milestones if you can promise a publication date for

Well, how about I send a draft tomorrow or Monday, and if I manage
to come through w/ that you can restore the milestone :-)

Thanks,

Joseph

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Mar 2005 23:28:44 -0500

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:

    Bill>  1) go through the documents, coming up with a list of
    Bill> distinct features.  Post this feature list to the WG for
    Bill> review.

I've never advanced something to draft before, so I'll be new at this
too.  It will be a bit of a race to see whether ssh or Kerberos deals
with this documentation challenge first.

My understanding is that the construction of the feature list is the
most challenging part of the process.  You want to avoid having too
many features; treating each MUST/SHOULD/mAY as a feature is clearly
too much effort and in many cases results in untestable features.
However if your feature list is too course you risk appeal or a
discuss vote at the IESG.

I've talked to Russ about this and received some advice I'll pass
along.

Avoid getting yourself into a situation where you need to test a MUST
NOT.  For example, it would be difficult to verify conformance if you
listed "MUST NOT crash on badly formed input," as a feature.  In
general, if testing something to go to draft requires you to write
code to generate invalid input or to create a can't happen situation
then you are doing something wrong and probably doing too much work.

--Sam

---

From: Simon Tatham <[email-masked]>
Date: Fri, 18 Mar 2005 10:37:29 +0000

> by the agent (using a passphrase or other means).  (very different use

The PuTTY team has had quite a lot of requests for a use model like
this, because it provides other desirable features such as the
ability to store all your keys encrypted until they're first needed
and ask for their passphrases as required.

The slightly fiddly bit is that there's currently no standard for
the format of an encrypted private key, and every implementation I
know of has its own format and would probably be reluctant to switch
to a standard one. Therefore I was planning to implement this (if
and when I get round to it at all) by means of a user-defined-
extension mechanism in the agent protocol, rather than attempting to
suggest a standardised form.
-- 
Simon Tatham         "My heart bleeds.
<[email-masked]>    (That's how it works.)"   -- Gareth Taylor

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 18 Mar 2005 08:13:59 -0500

On Thu, 2005-03-17 at 23:28, Sam Hartman wrote:
>  You want to avoid having too

though clearly major features which are known to have caused interop
difficulty in the past (rekey comes to mind) should be on the list as
distinct test points.

> then you are doing something wrong and probably doing too much work.

That sounds like very good advice.  Such tests are often valuable but
are probably better left as regression/stress/abuse tests. 

							- Bill

---

From: [email-masked] (Niels Möller)
Date: 18 Mar 2005 14:44:00 +0100

> and ask for their passphrases as required.

This leads to an interesting twist of password authentication.

Setup: User creates a keypair, and encrypts the private half using a
passphrase. (This naturally has to be done on a trusted machine). User
transfers public key and encrypted private key to one or more servers.

Login: Client asks server for encrypted private key. User types in
passphrase to decrypt it. Key is used to sign the session id, just
like for plain publickey authentication.

At a first look, the security properties seem quite similar to plain
password authentication, but with the important difference that the
server never, not even temporarily, has access to the clear text
passphrase, and that it should be reasonable safe to use the same
passphrase with several mutually untrusting servers.

I think I've read a few papers on session setup, where the scenario is
that the user sits at a (trusted) terminal, but has no keys,
certificates, hostkeys or any other personal information stored
locally. However, the user knows a secret passphrase. The objective is
to make use of this passphrase to download private keys, certificates
etc from the server in a secure way, with as little trust as possible
put on the server.

But for login, I think it would be even better with something in the
srp/speke class of password authentication. Important objectives are:
Use passphrase also to authenticate the server (so we can bootstrap
without hostkeys). And don't transmit anything on the wire that allows
an eavesdropper or MITM to mount a dictionary attack. It's REALLY a
shame almost everything in that area seem to be patented.

(I think
http://www.watersprings.org/pub/id/draft-perlman-strong-pass-00.txt
was written in an attempt to get around patents, but there are broad
patents in the area that might cover even this fairly unique
construction).

Regards,
/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 18 Mar 2005 09:43:49 -0500

> shame almost everything in that area seem to be patented.

The patent isn't the issue -- it's the license terms offered.

compare: http://www.ietf.org/ietf/IPR/WU-SRP
with: http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt

Given that many important implementations of ssh are free-as-in-beer, 
anything but royalty-free license terms is not worth our time.

The patents in this space have been very frustrating to a number of IETF
WG's.

					- Bill

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 Mar 2005 16:32:05 -0500

> far as all clients are concerned).

This is not just theoretical.  I have been using a smartcard-enabled ssh 
agent for over a year, using off-the-shelf components from OpenSSH, OpenSC, 
and PCSC-Lite.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 Mar 2005 16:37:37 -0500

> like for plain publickey authentication.

This seems like an interesting model, and quite possibly the subject of a 
draft describing a new userauth method.  Whether that's something this WG 
would want to accept as a work item, I don't know -- we seem to already 
have a lot of documents on our plate that aren't getting enough attention.

My main concern at the moment is that the approach you describe would make 
it fairly easy to obtain a copy of the encrypted private key on which to 
perform an offline dictionary attack...

I suppose I could also insert a plug here for the gssapi-with-mic userauth 
method, used in conjunction with the Kerberos GSSAPI mechanism.  It is 
entirely reasonable for an ssh client to prompt a user to obtain Kerberos 
tickets by typing a password, then use the resulting tickets to 
authenticate to the ssh server.  In fact, I believe there are 
configurations in use today which work this way, when the user doesn't 
already have tickets.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 Mar 2005 16:39:13 -0500

> with this documentation challenge first.

Ooh, a race.  That sounds fun! :-)

-- Jeff (Kerberos WG chair)

---

From: [email-masked] (Niels Möller)
Date: 21 Mar 2005 09:50:29 +0100

> with: http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt

I guess Phoenix haven't cared to indicate which claims of their patent
6,226,383 are infringed by SRP or by
http://www.watersprings.org/pub/id/draft-perlman-strong-pass-00.txt? I
think the inventor, David Jablon, is or used to be a member of this
wg. Would you mind clarifying?

To me, the first claim of US patent 6,226,383 is really bizarre. It is
of the form

  [...desirable properties for a key exhange protocol based on a
  shared secret S, including dictionary attack...]

  Claimed: Any method that meets those objectives, by using some
  public-key mechanism in some way parametrized by S.

And then the patent even goes on to cite prior art that meets precisely the
same objectives, using exactly the same high level "method"!

The draft by Radia Perlman and Charlie Kaufman is quite different from
all other secure password authentication methods, in that the choice
of primes is parametrized by the password. But of course, like any
other method that solves the problem using any public-key techniques
whatsoever, I guess it could infringe Jablon's claim 1, assuming that
claim really is valid.

BTW, is it correct that it is possible to update one's patent claims
during the time between patent application and patent issue? In this
case, the timing is as follows: Patent application: March 25, 1997.
Perlman-Kaufman draft: June 26, 2000. Patent issued: May 1, 2001.

Sorry if this discussion is off-topic, but it's really frustrating.

Regards,
/Niels

---

From: [email-masked] (Niels Möller)
Date: 21 Mar 2005 09:52:21 +0100

[...]

> My main concern at the moment is that the approach you describe would
> make it fairly easy to obtain a copy of the encrypted private key on
> which to perform an offline dictionary attack...

Right. That's why one would want to use something more sophisticated,
like SRP.

Regards,
/Niels