Subject: AD Review for draft-ietf-secsh-publickey-subsystem

From: Sam Hartman <[email-masked]>
Date: Sun, 27 Aug 2006 23:20:29 -0400 (EDT)

Hi.

I have reviewed the publickey subsystem draft for publication and have
the following comments The working group must come to consensus on
resolution for these comments and a new draft reflecting that
consensus should be uploaded.

As has previously been noted there is not a lot of energy left in the
working group.  In the interest of coming to some sort of closure one
way or another, thes comments must be addressed by October 31, 2006 or
the document will be withdrawn from publication.

1) There is no definition of the public key algorithms or the public key blobs.  Please clearly reference what the contents of the public key blob should be.

2) The abstract cannot contain references.  There needs to be a
    terminology section with the standard RFC 2119 language if you are
    going to use 2119 keywords.  id-nits (check
    http://tools.ietf.org/wg/secsh ) claims there are missing
    references.

3) What check must a server apply for the from hosts?  Is that an IP
    address/reverse DNS check?  Is the server expected to use
    cryptographic information when available (host keys)?  Presumably not, but you should say this.

4) 64-chars seems too short for local names.  A DNS domain name can be
    much longer than that.

5) Please use RFC 3066 for language tags.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 28 Aug 2006 11:42:16 -0500

On Sun, Aug 27, 2006 at 11:20:29PM -0400, Sam Hartman wrote:

> 5) Please use RFC 3066 for language tags.

   And the proper reference for UTF-8 is not RFC2279 either but
   RFC3629/STD0063.

   Also, since SSHv2 itself performs language negotiation, and since
   Unicode provides codepoints for indicating the language of a
   string/sub-string, why does this protocol need a slot for RFC3066
   language tags at all?

   I think you should just remove/deprecate the language tag field and
   rely on the language negotiation performed by SSHv2.

 - I'd rather the "mandatory" attribute of attributes be named
   "critical"...

 - Are attributes like "x11" and so on booleans?  Or does their
   presence/absence act as a boolean?  And if so, what kind of values do
   they take on?

 - Clients need to know what kind of environment "command-override"
   values will be evaluated in.  Should there be a request by which a
   client can ask for a description of said environment, and a status
   reply by which a server can list attributes of the environment like
   the OS it runs, OS release, values of certain environment variables,
   etc...  I would think so, something like:

      string "status"
      uint32 SSH_PUBLICKEY_ENVIRONMENT
      uint32 env_count
        string envvar_name
        string envvar_value

   along with some pre-defined environment variable names, like OS,
   OSREL, ARCH, PATH etc...

 - How should the command-override and subsystem attributes interact?

 - How much of the execution environment of command-overrides be
   specified here?

 - An attribute is needed to set environment variables for the
   environment where the command/shell/subsystem is executed.

Cheers,

Nico
--

---

From: Jon Bright <[email-masked]>
Date: Tue, 29 Aug 2006 10:20:49 +0200

Sam Hartman wrote:
> 
> 1) There is no definition of the public key algorithms or the public
> key blobs. Please clearly reference what the contents of the public key
> blob should be.

Opening of section 2: "The format of public-key blobs are detailed in 
the SSH Transport Protocol document [2].".  Is this not sufficient, or 
had you overlooked it?

> 2) The abstract cannot contain references.  

I've moved the paragraph starting "This protocol is intended to be used 
from the Secure Shell Connection Protocol.." out of the Abstract and 
into Introduction.

 > There needs to be a
>     going to use 2119 keywords.  

Added betweek Introduction and Overview.

> id-nits (check

Fixed by updating to the RFCs which obsoleted the referenced RFCs.

>     cryptographic information when available (host keys)?  Presumably not, but you should say this.

That's really platform-dependent.  I've added the following text: "The 
server should use whatever method is appropriate for its platform to 
identify the host - e.g. for IP-based networks, checking the IP address 
or performing a reverse DNS lookup."

> 4) 64-chars seems too short for local names.  A DNS domain name can be

This was discussed previously in the WG.  The requirement is that way 
because the requirement in ssh-arch is the same:

"In this protocol, all algorithm and method identifiers MUST be 
printable US-ASCII, non-empty strings no longer than 64 characters. 
Names MUST be case-sensitive."

> 5) Please use RFC 3066 for language tags.

As above, updated to 1766.

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

---

From: Jon Bright <[email-masked]>
Date: Tue, 29 Aug 2006 10:20:52 +0200

>    And the proper reference for UTF-8 is not RFC2279 either but

Have updated this.

>    rely on the language negotiation performed by SSHv2.

SSH2 negotiation negotiates a list of the languages to be used (or 
doesn't - that negotiation is optional).  The tags specify which of 
those languages is in use.  (In much the same way that the language tag 
for, say, SSH_MSG_DISCONNECT does.)

As for why we don't use Unicode language indicators - no idea, but I'd 
prefer to keep this consistent with all the messages in the other RFCs 
which also don't.

>  - I'd rather the "mandatory" attribute of attributes be named

This would change a sentence like "If the server does not implement a 
mandatory attribute, it MUST fail the add.." to "If the server does not 
implement a critical attribute, it MUST fail the add..".  The first 
seems preferable to me.

>    presence/absence act as a boolean?  And if so, what kind of values do

Their presence/absence act as boolean.  As for their values, "The 
attribute-value field SHOULD be empty for this attribute.".

>    values will be evaluated in. 

Under what circumstances?

>    Should there be a request by which a

Even if it's desirable, I think it's too late for this kind of change.

>  - How should the command-override and subsystem attributes interact?

command-override overrides SSH_MSG_CHANNEL_REQUESTs with "shell" or 
"exec".  subsystem places limits on SSH_MSG_CHANNEL_REQUESTs with 
"subsystem".  They're independent.

>  - How much of the execution environment of command-overrides be

If I've understood the question correctly: the only thing it specifies 
is the path.  I don't really know when you'd need to specify more?

>    environment where the command/shell/subsystem is executed.

Why?  Again, I think it's too late for this kind of substantive change.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Aug 2006 11:42:01 -0400

>>>>> "Jon" == Jon Bright <[email-masked]> writes:

    Jon> Sam Hartman wrote:
    >>  1) There is no definition of the public key algorithms or the
    >> public key blobs. Please clearly reference what the contents of
    >> the public key blob should be.

    Jon> Opening of section 2: "The format of public-key blobs are
    Jon> detailed in the SSH Transport Protocol document [2].".  Is
    Jon> this not sufficient, or had you overlooked it?

I had overlooked it, but could you please include a reference to the
specific section.

Your other changes seem fine.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Aug 2006 11:44:53 -0400

>> - I'd rather the "mandatory" attribute of attributes be named

    Jon> This would change a sentence like "If the server does not
    Jon> implement a mandatory attribute, it MUST fail the add.." to
    Jon> "If the server does not implement a critical attribute, it
    Jon> MUST fail the add..".  The first seems preferable to me.

My personal opinion is that critical is far preferable to mandatory in
a security protocol.  The usage you seem to be objecting to is quite
common in PKIX documents and is becoming more common in Kerberos
documents and other things throughout the security area.

I didn't make the common as an AD because I thought it a bit late, but
I support this change as an individual.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Aug 2006 11:13:26 -0500

> prefer to keep this consistent with all the messages in the other RFCs 

I misremembered how the rest of SSHv2 handles this -- usually a language
tag field does accompany localized strings in the protocol.

I think that's kind of useless (what do I do with that tag,
client-side?).  But you are following the pattern from the rest of the
SSHv2 protocol family, so I withdraw my comment re: language tag fields.

> implement a critical attribute, it MUST fail the add..".  The first 

The word "critical" is very commonly taken to mean what this doc means
by "mandatory" and there is no chance of confusing it with RFC2119
terminology.  I very strongly encourage this change.  I think it makes
the spec much more readable.

> attribute-value field SHOULD be empty for this attribute.".

Thanks.

> Under what circumstances?

So users (and even programs, I suppose) can properly construct
command-override values.  I don't feel strongly about this though.

> "subsystem".  They're independent.

OpenSSH does wrap subsystems with forced_commands, thus my question.

> is the path.  I don't really know when you'd need to specify more?

Are there environment variables that are set, etc...?  Or are such
details out of scope for your document?

> Why?  Again, I think it's too late for this kind of substantive change.

Because the facility you patterned this after (right?  OpenSSH?) has a
way to associate environment variables with public keys.

Nico
--

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 29 Aug 2006 09:52:53 -0600

> I support this change as an individual.

I don't have any objection one way or the other-- however, if
"critical" is becoming part of the 'standard writing language'
for security documents, we should probably adopt that standard.

Thanks,

Joseph

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Aug 2006 14:34:04 -0400

> documents and other things throughout the security area.

I agree.

---

From: Jon Bright <[email-masked]>
Date: Wed, 30 Aug 2006 08:22:18 +0200

> I support this change as an individual.

OK, since everyone seems to want this, I'll change the wording to 
"critical".  I'm still confused about why this is an improvement, though.

In normal English usage, "critical" has several meanings.  One of these 
is "indispensible, essential" (and having looked at several 
dictionaries, that's usually the meaning right before the definitions 
involving nuclear physics begin).  "Mandatory" seems to have only the 
meaning wanted in this document.

Far be it from me to be (ahem) critical of the security area's 
documents, but doesn't "mandatory" express the required meaning in a way 
more easily understood by the uninitiated reader?  Maybe I'm missing 
something...

---

From: Jon Bright <[email-masked]>
Date: Wed, 30 Aug 2006 12:54:01 +0200

> way to associate environment variables with public keys.

I didn't write the original version of this draft, I've just been 
shepherding it since it became a WG working item.  It'd be nice to 
document how OpenSSH does this, but I think it's too late to make this 
the job of this draft.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 10:12:27 -0500

> document how OpenSSH does this, but I think it's too late to make this 

But then OpenSSH can't implement this protocol without changing its
existing behaviour.

Therefore I think the fair thing to do would be to either allow the
'command-override' command to override subsystem commands also.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 30 Aug 2006 12:37:55 -0400

> 'command-override' command to override subsystem commands also

I don't think so.

Subsystems are not the same as shells.  A subsystem name is essentially a 
protocol constant used to request a particular service; it is not a 
command.  It's appropriate to limit what subsystems may be used, but not to 
replace a subsystem with a connection to a random program that does not 
speak the protocol defined for that subsystem.  I understand that this is 
the current OpenSSH behavior, but I believe that behavior is problematic, 
and that defining a useful, interoperable behavior is more important than 
being consistent with OpenSSH.

OpenSSH _can_ implement this protocol without eliminating its existing 
behavior and without breaking backward-compatibility, by introducing a new 
keyword which has the effect specified for command-override.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 30 Aug 2006 13:15:15 -0400

On Wednesday, August 30, 2006 11:50:08 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

> On Wed, Aug 30, 2006 at 12:37:55PM -0400, Jeffrey Hutzelman wrote:
>> Subsystems are not the same as shells.  A subsystem name is essentially
>> a  protocol constant used to request a particular service; it is not a
>> command.  It's appropriate to limit what subsystems may be used, but not
>> to  replace a subsystem with a connection to a random program that does
>> not  speak the protocol defined for that subsystem.
>
> But the command-override wouldn't fail to speak the subsystem's
> protocol -- typically it would be a wrapper for another program that
> does speak that protocol.

No, because that's not how openssh works.  OpenSSH's "command" option 
specifies a command that is used for _any_ connection authenticated by that 
key.  That command is used for any new shell or subsystem, and it does not 
get to know what the user requested.  That makes it kind of hard to know 
what protocol the client wants to speak, let alone implement it.

>> behavior and without breaking backward-compatibility, by introducing a
>> new  keyword which has the effect specified for command-override.
>
> But you couldn't faithfully list pre-existing authorized_keys file
> entries.

Sure you could, using an attribute like "[email-masked]".
But I would not object to adding an OPTIONAL attribute with similar 
semantics, to allow OpenSSH to express current behavior.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 30 Aug 2006 11:55:46 -0400

On Wednesday, August 30, 2006 08:22:18 AM +0200 Jon Bright 
<[email-masked]> wrote:

> is "indispensible, essential" (and having looked at several dictionaries,
> that's usually the meaning right before the definitions involving nuclear
> physics begin).  "Mandatory" seems to have only the meaning wanted in
> this document.

The distinction here is subtle but important.
The word "mandatory" usually describes things that MUST be implemented.
The word "critical", in a security context, is used to describe things that 
need not be implemented, but which have the effect of producing incorrect 
behavior if blindly ignored.  Such features/extensions/whatever must be 
rejected if they are seen by an implementation which doesn't understand 
them.

-- Jeff

---

From: Joseph Galbraith <[email-masked]>
Date: Wed, 30 Aug 2006 11:31:33 -0600

Jeffrey Hutzelman wrote:
> specifies a command that is used for _any_ connection authenticated by 
> that key.  That command is used for any new shell or subsystem, and it 
> does not get to know what the user requested.  That makes it kind of 
> hard to know what protocol the client wants to speak, let alone 
> implement it.
> 

It doesn't seem inappropriate to use "@openssh.org" to express
an openssh compatibility option.

In the normal course of events, I wouldn't be opposed to adding
a standard attribute to the draft, but I'm worried that something
like that would require us to redo last-call?  And given the
deadline we are operating under, I suspect this is not a winning
option.

Thanks,

Joseph

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 12:52:59 -0500

> deadline we are operating under, I suspect this is not a winning

If I decide that I'm happy with vendor-specific command-override
alternatives then I won't ask you to change the draft and I'll withdraw
my comment.

However, what I requested was simple enough: add text saying that
servers MAY apply command-overrides to subsystems.

I think this MAY should be non-controversial -- there is already way too
much that is left unstated about the environment in which command-
overrides are executed.

For example, OpenSSH sets a number of SSH_* environment variables in the
environment of forced commands to convery information about the
connection and/or channel in the context of which the command is being
executed.  And you would not want to specify such things here.  But by
constraining command-overrides so they do not apply to subsystems you
create a problem.  The MAY and [email-masked] solutions
both address the problem, but I think the former is easier to understand
for users of this protocol than the latter.  Users already have to know
quite a bit about the environment on the server, such as paths to the
command-override programs, and may even want to write their own, in
which case they have to know even more about the environment.  So asking
users to know whether command-override applies to subsystems seems
reasonable, but asking them to know that [email-masked]
(or do you expect the client to learn this?) means the same seems like
too much.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 12:32:44 -0500

> what protocol the client wants to speak, let alone implement it.

OpenSSH sets environment variables like SSH_ORIGINAL_COMMAND, so forced
commands can find out that, gee, this is for the sftp subsystem, say.

> semantics, to allow OpenSSH to express current behavior.

True, you could do that, and you might argue that that is the better
thing to do, because then a presumably savvy client would know about
this subtle semantic difference.  I have to decide whether this makes my
concern go away.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Aug 2006 11:50:08 -0500

On Wed, Aug 30, 2006 at 12:37:55PM -0400, Jeffrey Hutzelman wrote:
> speak the protocol defined for that subsystem.

Yes, this is very much implementation-specific as other implementations
and even future versions of OpenSSH (for all I know) might use other
means to implement subsystems, such as dynamically loaded plug-ins.

But all I ask is that the OpenSSH behaviour be allowed.

>                                                 I understand that this is 

I agree, but this does not preclude allowing the OpenSSH behaviour
explicitly.

Nico
--