Re: [Curdle] WG status and extension negotiation

[Румен Петров <[e-mail]>]

Hi,

I would like to split my comments in two parts.
First part is about extension negotiation 
(draft-ietf-curdle-ssh-ext-info-nn.txt) and subject of this email.

I'm author of PKIX-SSH secure shell implementation that support X.509 
certificate based publickey and hostbased algorithms.

Goal is to find way transparently to users to switch from legacy 
algorithms to rfc6187 one.
Legacy algorithms as defined  in draft-ietf-secsh-transport-12.txt (31 
Jan. 2002) are
- x509v3-sign-rsa and
- x509v3-sign-dss .
Algorithms that correspond to same key type defined in rfc6187 are
- x509v3-ssh-rsa and
- x509v3-ssh-dss .
Currently x509v3-rsa2048-sha256 ( rfc6187) is out of my scope.


Daniel Migault wrote:
> Hi,
>
> So far we have not received many inputs and I would like to make sure we
> understand Romen's concern. My understanding of the concerned raised by
> Romen is that specifying signature algorithms may complexity the ways
> Public Key Algorithm registries are designated.  However it looks to me one
> reason is that we are moving from implicit signature scheme to explicit
> ones.
>
> Romen please re-state your issues with the draft, clearly expose the issues
> as well as the alternate you would fine acceptable.

Let review be example following case - secure token (smart-card), RSA 
key and associated X.509 certificate.

Which publickey algorithm to in public key authentication without to 
probe all listed below?
- (1) x509v3-sign-rsa  (legacy)
- (2) x509v3-ssh-rsa  (rfc6187)
- (3) x509v3-rsa2048-sha256 (rfc6187 if applicable, perhaps will be 
implemented in PKIX-SSH)
- (4) ssh-rsa (rfc4253)
- (5) rsa-sha2-256 (upcoming)
- (6) rsa-sha2-512 (upcoming)


To find suitable algorithm we could use "software version" field (see 
rfc4253 4.2.  Protocol Version Exchange). This solution is possible but 
requires up-to date database with information for vendor, version and 
supported ssh features. For such solution maintenance cost is too high.

Another solution id peers to inform each other for supported 
functionality. So "extension negotiation mechanism"fail into this category.


Denis,  author of extension negotiation propose "server-sig-algs".

Until now ssh related documents define publickey algorithm - see 
rfc4252, chapter  7. Public Key Authentication Method: "publickey") and 
hostbased (same rfc) and format of key and signature in
with triplet :
(I) public key algorithm name in USERAUTH_REQUEST message (rfc4252)
(II) certificate or public key format identifier (rfc4253)
(III) signature format identifier (as specified by the public 
key/certificate format) (rfc4253)

For algorithms (1), (2) and (4) the triplet is :
(1) x509v3-sign-rsa  / --- (!?!) / x509v3-sign-rsa
(2) x509v3-ssh-rsa / x509v3-ssh-rsa / ssh-rsa
(4) ssh-rsa / ssh-rsa / ssh-rsa

As is visible identifier of signature algorithm overlap two publickey 
algorithm.

To avoid ambiguities in PKIX-SSH 10.1 I implement new extension (a) 
/"[e-mail]"/ . Thus PKIX-SSH could list 
all algorithms from above (3* if implemented) as "public key algorithm 
name" in unique.
As of today client will chose algorithm (1) but in the near future 
(perhaps next version)  rfc6187 algorithm(2) will be preferred chose.

Extension (b) "server-sig-algs" is also announced by PKIX-SSH but with 
restriction - list only algorithms whose name match identifier of 
signature. This exclude automatically rfc6187 but could be used for 
compatibility with implementation like Bitvise and OpenSSH as they 
supports "algorithms whose name match identifier of signature".
In connection to those servers PKIX-SSH will chose algorithm (5).

In connection to server without extensions - client will try (1) and if 
not accepted (4).

Above is part of PKIX-SSH feature called "/adaptive public key algorithm 
selection"/ - an automatic process.

Manual configurations that impact /public key algorithm selection is out 
of scope to this mail ./


In conclusion : extension negotiation mechanism is valuable solution to 
resolve case above if propose an extension that allows in unique way to 
chose triplet for USERAUTH_REQUEST message.

> Yours,
> Daniel
>
[SNIP]


Regards,
Roumen Petrov