draft-harris-ssh-rsa-kex

[Ben Harris <a7250%bjh21.me.uk@localhost>]

I've just sent off draft-harris-ssh-rsa-kex to <internet-drafts%ietf.org@localhost>. 
This should address all the concerns I've heard about, updates my postal 
address, and changes the e-mail address to a temporary disposable one for 
the time being.  Detailed responses to comments follow.


Scott Hollenback wrote:
> Section 4: How many bits are in the "byte" data type?  Is the
> "string" data type null-terminated or not?  I checked both
> draft-ietf-secsh-assignednumbers and draft-ietf-secsh-transport to
> see if they included normative definitions, but they appear to use
> the same data types without providing a definition.
>
> Stated generically, where are the normative definitions for the
> data types used in this document?

I believe this is resolved by a new reference to 
draft-ietf-secsh-architecture in section 2.


Russ Housley wrote:
> The security considerations say:
> >
> > K, the random integer generated by the client, is the only secret
> > shared by client and server.  Thus its entropy directly determines
> > the security of the session against eavesdropping.
> >
> Please point to RFC 4086 for guidance on generation of random values.

Done.

> Also, why is the random value and integer?

draft-ietf-secsh-transport, section 7.2, states:

   Encryption keys MUST be computed as HASH of a known value and K as
   follows:
   o  Initial IV client to server: HASH(K || H || "A" || session_id)
      (Here K is encoded as mpint and "A" as byte and session_id as raw
      data.  "A" means the single character A, ASCII 65).

K can only be encoded as an mpint if it's an integer.

> I believe that the key is the
> secret input to the SSH key derivation function.  Finally, please
> point out that the client has complete control over the secret value
> that is used.  The server does not provide any entropy.

The penultimate paragraph of section 8 should cover this.  In particular,
it states:

   Unlike the Diffie-Hellman key exchange method defined by [I-D.ietf-
   secsh-transport], this method allows the client to fully determine
   the shared secret, K.


Elwyn Davies wrote:
> -secsh-assignments specifies the numbers defined in this range in
> -secsh-transport but allows the numbers to be overloaded.  Is it the
> intention that future names/numbers in this range should be registered
> with IANA even though it may not be strictly necessary?

No.  That was an error in -assignednumbers, and has been fixed in
the RFC-Editor draft of RFC 4250.

> s1: It might be useful to mention that the terminology and abbreviations
> (such as K_S) are mostly taken from the -secsh-transport draft.

I've added that to section 2.

> s3: Might be useful to introduce the K_S notation for the server host
> key here, if only to make it absolutely clear that it isn't the same as K_T.

I think the reference in section 2 should be sufficient.

> s3: It would be useful to point to s8 of -secsh-transport for the
> mechanisms used for verifying the host key.

Done (the reference to -transport was there already, but I've added a 
section number.

> s4, para 1: s/, which are defined by the method name/that are specified,
> fixed values defined for each method name/

I've rewritten this entirely.  I think it's rather clearer now.

> s4: There should be a note pointing to -secsh-architecture regarding how
> the message contents are specified.

I think that's covered by my new "other terminology" note in section 2.

> s4: Generation of K: I would prefer (2*HLEN) to 2HLEN in the
> specification of the range for K.
>
> Appendix A:  The previous comment applies to 4 places in Appendix A also.

All changed.


--
Ben Harris