headers
Joseph Galbraith | 7 Mar 2007 16:34
Favicon

Re: draft-bjh21-ssh-transport-extension-01

Ben Harris wrote:
> I've uploaded a new version of my transport extension draft which I 
> think addresses everyone's comments.  Any more before I wave it at the 
> IESG?  In particular, I'm wondering if I should extend it to allocate 
> similar message numbers for extensions to ssh-userauth and/or 
> ssh-connect.
> 
> <http://www.ietf.org/internet-drafts/draft-bjh21-ssh-transport-extension-01.txt>

I just read this through with an eye towards implementing it,
and have several comments:

1. Did I just miss it, or is the message number actually not yet
   defined?

2. SSH_MSG_UNIMPLEMENTED has some drawbacks (in particular, it isn't
   reasonably possible to identify which packet was unimplemented.)

   For unrecognized extensions, I'd rather see a predefined
   extension:

   byte      SSH_MSG_TRANSPORT_EXTENSION
   string    "unrecognized-extension"

   that should be sent in response to a extension the implementation
   doesn't recognize.

   This has the advantage that the sender can differentiate between
   implementations not implementing the draft and implementations
   not implementing the extension.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Simon Tatham | 7 Mar 2007 16:48
Picon
Favicon

Re: draft-bjh21-ssh-transport-extension-01

Joseph Galbraith  <galb-list <at> vandyke.com> wrote:
> 2. SSH_MSG_UNIMPLEMENTED has some drawbacks (in particular, it isn't
>    reasonably possible to identify which packet was unimplemented.)

Why not? You can remember the sequence number when you construct
your outgoing packets.

I admit I have no first-hand experience of actually trying this, but
I'd imagine that there aren't _many_ circumstances under which you
can recover from SSH_MSG_UNIMPLEMENTED and continue a useful
session. In other words, you'd be able to identify _specific_
outgoing packets on your side of the connection for which you'd be
interested in noticing SSH_MSG_UNIMPLEMENTED. Then you can remember
the sequence number of each of those specific packets until you
receive either the SSH_MSG_UNIMPLEMENTED or the expected response.
For any packet for which you _don't_ have a defined
SSH_MSG_UNIMPLEMENTED handler, there's nothing you can really do
except to terminate the session on the grounds that the other side
refused to deal with something you couldn't manage without.
--

-- 
Simon Tatham         "My heart bleeds.
<anakin <at> pobox.com>    (That's how it works.)"   -- Gareth Taylor
Permalink | Reply | 0 comments |
headers
Jeffrey Hutzelman | 7 Mar 2007 17:03
Picon
Favicon

Re: draft-bjh21-ssh-transport-extension-01


On Wednesday, March 07, 2007 08:34:36 AM -0700 Joseph Galbraith 
<galb-list <at> vandyke.com> wrote:

> Ben Harris wrote:
>> I've uploaded a new version of my transport extension draft which I
>> think addresses everyone's comments.  Any more before I wave it at the
>> IESG?  In particular, I'm wondering if I should extend it to allocate
>> similar message numbers for extensions to ssh-userauth and/or
>> ssh-connect.
>>
>> <http://www.ietf.org/internet-drafts/draft-bjh21-ssh-transport-extension
>> -01.txt>
>
> I just read this through with an eye towards implementing it,
> and have several comments:
>
> 1. Did I just miss it, or is the message number actually not yet
>    defined?

No, you didn't miss it.  The actual message number won't be assigned by 
IANA until after the spec has been approved by the IESG.  This is normal 
for assignments requiring IESG approval and/or IETF consensus action.

> 2. SSH_MSG_UNIMPLEMENTED has some drawbacks (in particular, it isn't
>    reasonably possible to identify which packet was unimplemented.)
>
>    For unrecognized extensions, I'd rather see a predefined
>    extension:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
der Mouse | 7 Mar 2007 17:09
Picon

Re: draft-bjh21-ssh-transport-extension-01

> 2. SSH_MSG_UNIMPLEMENTED has some drawbacks (in particular, it isn't
>    reasonably possible to identify which packet was unimplemented.)

This is no worse than the stock protocol with respect to channel
requests.

> [...]
>    This has the advantage that the sender can differentiate between
>    implementations not implementing the draft and implementations not
>    implementing the extension.

Why would a sender care?  I'm having trouble thinking of a reason.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse <at> rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply | 1 comment |
headers
Joseph Galbraith | 7 Mar 2007 17:17
Favicon

Re: draft-bjh21-ssh-transport-extension-01

Jeffrey Hutzelman wrote:
> 
> 
> On Wednesday, March 07, 2007 08:34:36 AM -0700 Joseph Galbraith
> <galb-list <at> vandyke.com> wrote:
> 
>> Ben Harris wrote:
>>> I've uploaded a new version of my transport extension draft which I
>>> think addresses everyone's comments.  Any more before I wave it at the
>>> IESG?  In particular, I'm wondering if I should extend it to allocate
>>> similar message numbers for extensions to ssh-userauth and/or
>>> ssh-connect.
>>>
>>> <http://www.ietf.org/internet-drafts/draft-bjh21-ssh-transport-extension
>>> -01.txt>
>>
>> I just read this through with an eye towards implementing it,
>> and have several comments:
>>
>> 1. Did I just miss it, or is the message number actually not yet
>>    defined?
> 
> No, you didn't miss it.  The actual message number won't be assigned by
> IANA until after the spec has been approved by the IESG.  This is normal
> for assignments requiring IESG approval and/or IETF consensus action.

Ahh... I suspected something like that, but wanted to make
sure.

>> 2. SSH_MSG_UNIMPLEMENTED has some drawbacks (in particular, it isn't
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joseph Galbraith | 7 Mar 2007 17:29
Favicon

Re: draft-bjh21-ssh-transport-extension-01

der Mouse wrote:
>> 2. SSH_MSG_UNIMPLEMENTED has some drawbacks (in particular, it isn't
>>    reasonably possible to identify which packet was unimplemented.)
> 
> This is no worse than the stock protocol with respect to channel
> requests.
> 
>> [...]
>>    This has the advantage that the sender can differentiate between
>>    implementations not implementing the draft and implementations not
>>    implementing the extension.
> 
> Why would a sender care?  I'm having trouble thinking of a reason.

Well, the use case that comes to my mind is that if the draft
isn't implemented, the sender might which to avoid sending any
further extensions, but if it is just a specific extension,
the sender might care to use other extensions.

Thanks,

Joseph
Permalink | Reply | 0 comments |
headers
Ben Harris | 7 Mar 2007 17:28
Picon

Re: draft-bjh21-ssh-transport-extension-01

On Wed, 7 Mar 2007, Joseph Galbraith wrote:

> 3. Do we need a nod to in-order vs. out-of-order processing:

I don't think so, for the same reason that I dropped the security 
consideration about packets sent before SSH_MSG_NEWKEYS: the issue applies 
to all extensions that define new message types, whether they do it by 
assigning a whole message number or by using a named message.  It would be 
perverse to impose a more stringent requirement on named messages than on 
numbered ones.

On your other points, Simon's and der Mouse's replies cover everything I 
was going to say.

--

-- 
Ben Harris
Permalink | Reply | 0 comments |
headers
rfc-editor | 13 Mar 2007 00:55
Favicon

RFC 4819 on Secure Shell Public Key Subsystem


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4819

        Title:      Secure Shell Public Key Subsystem 
        Author:     J. Galbraith, J. Van Dyke,
                    J. Bright
        Status:     Standards Track
        Date:       March 2007
        Mailbox:    galb <at> vandyke.com, 
                    jpv <at> vandyke.com, 
                    jon <at> siliconcircus.com
        Pages:      17
        Characters: 32794
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-secsh-publickey-subsystem-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4819.txt

Secure Shell defines a user authentication mechanism that is based on
public keys, but does not define any mechanism for key distribution.
No common key management solution exists in current implementations.
This document describes a protocol that can be used to configure
public keys in an implementation-independent fashion, allowing client
software to take on the burden of this configuration.

The Public Key Subsystem provides a server-independent mechanism for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 13 Mar 2007 06:37
Picon
Picon
Picon
Favicon

Re: X.509

Oskari Saarenmaa <oskari <at> saarenmaa.fi> writes:

>I recently submitted a new individual draft for ssh x509 which backs down
>from what we specified in the latest WG draft, and just specifies how we use
>certificates in our implementations.  It's available at
>http://tools.ietf.org/wg/secsh/draft-saarenmaa-ssh-x509-00.txt
>
>Any thoughts?

Further to my previous comments, the text in the Implementation Considerations
section seems a bit misplaced.  Firstly, it's already subsumed by the "refer
to PKI standards" requirement in the Security Considerations, so it's
redundant.  Secondly, I would both hope that any implementation that doesn't
implement a verification algorithm would fail to verify the certificate that
uses it, and can't really see why this would be singled out for special
attention when there are lots of other things that also need to be checked.
Finally, to be nit-picky, you need to verify up to a trust anchor, which isn't
necessarily "all the certificates in the chain".

For all of the above, the appropriate solution seems to be to remove this
section, since it's already more than covered by the requirement in section 7.

Is anyone running a test SSH server that implements this authentication
mechanism?  I'd like to have something to test against...

Peter.
Permalink | Reply | 501 comments |
headers
Roumen Petrov | 27 Mar 2007 23:51
Favicon

Re: X.509

Peter Gutmann wrote:
> Oskari Saarenmaa <oskari <at> saarenmaa.fi> writes:
>
>   
>> I recently submitted a new individual draft for ssh x509 which backs down
>>     
> >from what we specified in the latest WG draft, and just specifies how we use
>   
>> certificates in our implementations.  It's available at
>> http://tools.ietf.org/wg/secsh/draft-saarenmaa-ssh-x509-00.txt
>>
>> Any thoughts?
>>     
>
> Further to my previous comments, the text in the Implementation Considerations
> section seems a bit misplaced.  Firstly, it's already subsumed by the "refer
> to PKI standards" requirement in the Security Considerations, so it's
> redundant.  Secondly, I would both hope that any implementation that doesn't
> implement a verification algorithm would fail to verify the certificate that
> uses it, and can't really see why this would be singled out for special
> attention when there are lots of other things that also need to be checked.
>   

It is possible simple implementation to compare public key extracted from
certificate sent with keys from its configuration and if they match to 
accept
connection. As example without this self-issued(self-signed) X.509 
certificates
cannot be used in authentication.
(Continue reading)

Permalink | Reply | 501 comments |

Gmane