IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts.
On Thursday, Apr 10, 2003, at 13:32 America/Montreal, Joseph Galbraith wrote: 
11.1.3 Replay

   This protocol binds each session key to the session
   by including random data that is specific to the
   session in the hash used to produce session keys.

[RJA:  Is it random or pseudo-random ?
[RJA:  Does the difference matter in this case ?


It is probably pseudo-random?  I'm not sure if
it matters.  If no one else can say, I'll just
change it to pseudo-random.


It would be good if we could find a cryptographer
who could tell us whether it matters.


   This session id is used by higher level protocols
   to prevent replay of packets form previous sessions.

   In addition, the use of cipher chaining prevents
   replay of packets within the session.  Cipher chaining
   also prevents the insertion or deletion of packets.

[RJA:  Citations would be pleasant for these claims.


All right, I think I was just having a major incident
of drain bamage.

This section should be rewritten:

   The use of a MAC other than 'none' provides rigorerous
   protection agains replay attacks at the protocol
   level.


I think of a MAC (by itself) as only providing integrity/authentication.

I imagine that a sequence number does help preclude replay
attacks, but I was hoping that someone else had actually
done some analysis that we could cite to justify the claim
that this MAC combined with this kind of sequence numbering
would actually provide replay attack prevention.


   In addition, the transport protocol provides a
   unique session identifier (bound in part to pseudo-random
   data that is part of the algorithm and key exchange process)
   that can be used by higher level protocols to
   bind data to a given session and prevent replay of
   data from prior sessions.

   For example, the authentication protocol uses this to
   prevent replay of signatures from previous sessions.



   This vulnerability to man-in-the-middle attacks can
   be mitigated in several fashions:

   1. Narrow the window.  If the client ensures that the
      host key for a given server remains consistant, an
      attacker must execute the man-in-the-middle attack
      on the _first_ connection to a given server.

[RJA:  Narrow *which* window ?
[RJA:  Intended meaning is not crystal clear above.


How about this?
   1. Narrow the window during which the client is vulnerable
      to such a man-in-the-middle attack..  If the client ensures
      that the...


OK with me.


   2. Use an authentication method that is not vulnerable
      to man-in-the-middle.  For example, public-key
      authentication is not vulnerable to man-in-the-middle
      attack, because the signature is made across data
      that is session specific.  The attack can not use
      the signature he receives because the session specific
      data between the attacker and server is different, and
      can not create a valid signature because he does not
      have the private key.

[RJA:  Is this really true and sufficient ?


Hmm... I'm not sure if I missed something here or
what?  If the man-in-the-middle doesn't have the
private key, he can't complete the authentication
right?  It seems that this is true and sufficient
to prevent an attack, but maybe I'm missing something?


Maybe you didn't miss anything.  It really was a
question on my part.  Maybe massage the above new
paragraph to include your sentence:

		"[Because] the man-in-the-middle does not have
		the private key [of whom ?], the he cannot
		correctly complete the authentication with
		[whom ?]."

My main goal here is clarity, so avoiding pronouns
and making the identities clear is appreciated. :-)


   Use of this protocol without reliable association

[RJA:  association of what/whom ?


How about:

   Use of this protocol without reliable association
   of hosts and host keys is inherently insecure, but
   but may be necessary in non-security critical
   environments, and still provides protection against
   passive attacks.  However, implementors of applications
   running on top of this protocol should keep this
   possibility in mind.


Proposed slight edit to first clause:

	Use of this protocol without reliable authentication
	of the binding between a host and its host keys is
	inherently insecure, but ...


11.2 Authentication Protocol

   The purpose of this protocol is to perform client user
   authentication.  It assumed that this runs over a secure transport
   layer protocol, which has already authenticated the server machine,
   established an encrypted communications channel, and computed a
   unique session identifier for this session.  The transport layer
   provides forward secrecy for password authentication and other
   methods that rely on secret data.

[RJA:  "perfect forward secrecy" or "forward secrecy" ?


I'm not sure; this paragraph is quoted from the previous
security considerations section.  Would any one else care
to comment?


I'm also not sure, but it would be nice if we could find
someone who is sure -- preferably someone who can supply
a citation or a more detailed rationale to support the claim.


11.2.3 Local security policy

   Implementer MUST ensure that the credentials provided
   validate the professed user and also MUST ensure that
   the local policy of the server permits the user the
   access requested.

   In particular, because of the flexible nature of the
   SSH connection protocol, it may not be possible to determine
   this completely at the time of authentication, because
   the kind of service being requested is not yet clear.

[RJA:  Unclear antecedent "this".


How about:

   In particular, because of the flexible nature of the
   SSH connection protocol, it may not be possible to determine
   the local security policy that should apply at the time
   of authentication, because the kind of service being
   requested is not yet clear.


Fine with me.


11.3.3 X11 forwarding

   Another form of proxy forwarding provided by the ssh
   connection protocol is the forwarding of the X11 protocol.

   Implementors of the X11 protocol SHOULD implement the
   magic cookie spoofing, to prevent unauthorized use of
   the proxy.

[RJA:  Add citation for "magic cookie spoofing".


How about: see "SSH Connection Protocol", Section 4.3.1, page 9.


Maybe.  Once upon a time there was a component of X11 called
"MIT-magic-cookie" that was used to provide (very very weak)
security.  My original thought was that the original text
was referring to that, hence some reference to the X11 protocol
specification or to some relevant published paper on X11 would
be the right one.  With your new text, I'm now wondering whether
the intended reference was to the "MIT-magic-cookie" part of
the X11 protocol or to something else.

I'm confused.



   X11 forwarding relies on end-point security.  If end-point
   security has been compromised, X11 forwarding will allow
   any attack against the X11 server possible locally.

   Users and administrators should, as a matter of course, use
   X11 security mechanism to prevent unauthorized use of
   the X11 server.


[RJA:  Which "X11 security mechanism" is meant ?
[RJA:  Also, please add a citation for that mechanism.

Well, I didn't have a particular one in mind.  The
advice is to use any X11 security mechanism.  I'd
be willing to remove the paragraph.


I'd like to keep text encouraging folks to use as much
security as they can.  I'm not an expert on the security
properties of X11.  I was thinking that there probably were
some specific security mechanisms (e.g. my vague recollection
of the MIT-magic-cookie hack noted above) that we ought
to mention and cite.

Cheers,

Ran
Home | Main Index | Thread Index | Old Index