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

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

On 3/30/2010 09:01, Igoe, Kevin M. wrote:
> 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.

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

>> -----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
>>