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

From: Joseph Galbraith <[email-masked]>
Date: Mon, 29 Mar 2010 11:21:29 -0600

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

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Tue, 30 Mar 2010 11:01:43 -0400

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joseph Galbraith
> Sent: Monday, March 29, 2010 1:21 PM
> To: [email-masked]
> Subject: Feedback on draft-igoe-secsh-x509v3-01
> 
> I just did a quick read-thru on this document and it looks 
> pretty good.
> 
> First off I think "MUST be signed using only algorithms" 
> conflicts with "verifiers SHOULD be prepared" (or at least is 
> confusing.)
> 
> 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.
>

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 30 Mar 2010 10:56:38 -0600

> eliminating the need to support a broad spectrum of signatures.

Are you talking about a client/server combo specifically
implemented only to work with each other, or are you talking
about a generic client/server combo configured in a specific
way?

If it is the former, then they needn't comply to any standard.

If it is the latter, I'm pretty sure that MUST/REQUIRED doesn't
actually apply to site policy... so even if the draft says MUST,
site policy can still disable a feature (like the required key
exchange or encryption algorithms.)

Basically, in terms of interoperability, if we allow one
peer to send something, then it seems like we have to require
the other peer to be able to parse it.

Note that the proposed language doesn't require that the
request succeed, only that the  verifier MUST be prepared
to receive such requests (and in fact the next sentence
predicts increased failure rates for such requests.)

All that said, if you feel strongly about SHOULD instead
of MUST, I'm not going to run screaming from the room :-)

Thanks,

Joseph

---

From: der Mouse <[email-masked]>
Date: Tue, 30 Mar 2010 13:26:30 -0400 (EDT)

> "Verifiers SHOULD".  [...]
>>   algorithms that were not listed [...]

I see no reason to soften this.  Being prepared to receive certificate
chains is not the same thing as being prepared to accept, verify, and
authenticate using them.

Or were you talking about a different paragraph and thus a different
MUST?

/~\ The ASCII				  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: "Igoe, Kevin M." <[email-masked]>
Date: Tue, 30 Mar 2010 15:45:13 -0400

For sake of completeness, let me take a stab at what the
I think is meant by the phrase "prepared to receive" in this
context.

"Prapared to receive" means the server is able to identify the
type digital signature used within each cert in the certificate 
chain and decide if it is capable of verfiying this flavor of  
digital signature.

If either 
	1) putative chain of certs isn't properly formed
	2) the root authority is unaccpetable
	3) the server you isn't able to handle one or more
         of the flavors of digital signatures being used
	4) one or more of the signatures is invalid
then the server should send a SSH_MSG_USERAUTH_FAILURE message.

Sadly, RFC 4252 highly constrains the format of a
SSH_MSG_USERAUTH_FAILURE
message, limiting he feedback that can be given to the user as to why
their authentication has failed.

> 5.1.  Responses to Authentication Requests
>    If the server rejects the authentication request, it MUST respond
>    with the following:
> 
>       byte         SSH_MSG_USERAUTH_FAILURE
>       name-list    authentications that can continue
>       boolean      partial success
> 
>    The 'authentications that can continue' is a comma-separated name-
>    list of authentication 'method name' values that may productively
>    continue the authentication dialog.

> [mailto:[email-masked]] On Behalf Of der Mouse
> Sent: Tuesday, March 30, 2010 1:27 PM
> To: [email-masked]
> Subject: Re: Feedback on draft-igoe-secsh-x509v3-01
> 
> I see no reason to soften this.  Being prepared to receive 
> certificate chains is not the same thing as being prepared to 
> accept, verify, and authenticate using them.
> 
> Or were you talking about a different paragraph and thus a 
> different MUST?
> 
> /~\ The ASCII				  Mouse
> \ / Ribbon Campaign