RE: Feedback on draft-igoe-secsh-x509v3-01

["Igoe, Kevin M." <kmigoe%nsa.gov@localhost>]

Good suggetions.  Given the existing SSH UserAuth
SSH_MSG_USERAUTH_REQUEST
and SSH_MSG_USERAUTH_SUCCESS/FAILURE protocol specified in sction 7 of
RFC 4253, 
the best we can do is mitigate the need for many rounds of REQUEST &
FAILURE 
messages.  Your suggested text addresses that quite nicely.

I'd like to soften the "Verifiers MUST" in the second paragraph to
"Verifiers SHOULD".  Some ssh servers are restricted to a very 
limited set of authorized clients.  In such a case, these users may
have been issued certs specifically for this site. The server
need only deal with the signature algorithms used in these certs, 
eliminating the need to support a broad spectrum of signatures.



> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost 
> [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Joseph Galbraith
> Sent: Monday, March 29, 2010 1:21 PM
> To: ietf-ssh%NetBSD.org@localhost
> Subject: Feedback on draft-igoe-secsh-x509v3-01
> 
> I just did a quick read-thru on this document and it looks 
> pretty good.
> 
> However, this paragraph from Section 2 was confusing:
> 
> >  o  The individual certificates in the certificate chain MUST be
> >       signed using only algorithms corresponding to public key
> >       algorithms supported by the peer.  The choice of signature
> >       algorithm used by any given certificate is independent of the
> >       signature algorithms chosen by other certificates in 
> the chain.
> >       However, verifiers SHOULD be prepared to receive certificate
> >       chains that do not comply with this (in other words, using any
> >       signature algorithms), and MAY verify a non-compliant chain if
> >       they are able to do so.
> 
> First off I think "MUST be signed using only algorithms" 
> conflicts with "verifiers SHOULD be prepared" (or at least is 
> confusing.)
> 
> And secondly, as I noted before, we really don't have a good 
> indication of what algorithms the peer supports.  We know 
> what algorithms the server has a hostkey for and what 
> algorithms the client is willing to accept as a hostkey.  But 
> we don't actually know what algorithms either side supports 
> for publickey authentication.
> 
> I would suggest this paragraph be rewritten as something similar to
> this:
> 
> o The only algorithms that can be guaranteed to be supported
>   by the peer are those that were listed in
>   "server_host_key_algorithms" of key exchange (See RFC 4253,
>   Section 7.1, "Algorithm Negotiation").  Where possible, the
>   individual certificates in the certificate chain SHOULD be
>   restricted to the algorithms listed in "server_host_key_algorithms";
>   however, other algorithms are permitted.
> 
>   Verifiers MUST be prepared to receive certificate chains that use
>   algorithms that were not listed in "server_host_key_algorithms",
>   and indeed potentially algorithms that have no ssh equivalent.
>   Such chains are more likely result in a failure than a chain
>   which uses only the algorithms listed in 
> "server_host_key_algorithms"
> 
> Thanks,
> 
> Joseph
>