Subject: Re: Comments on the reviesed Security Section open issues.

From: Heikki Nousiainen <[email-masked]>
Date: Mon, 12 May 2003 23:11:55 +0300 (EEST)

> On Monday, May 12, 2003, at 13:40 America/Montreal, Joseph Galbraith
> wrote:
> >>> [RJA:  I imagine that a sequence number does help preclude replay
> > attacks,
> >>> [RJA:  but I was hoping that someone else had actually done some
> > analysis
> >>> [RJA:  that we could cite to justify the claim that this MAC combined
> > with
> >>> [RJA:  this kind of sequence numbering would actually provide replay
> >>> [RJA:  attack prevention.
> >
> > If no one knows of something to cite here, I'm
> > not sure what to do at this point?
> >
> > Baring someone stepping forward witht the requested
> > citation, what should we do?  I'd like to move forward.
> 
> Generic comment (applies to above and other places):
> 	I'd rather delete a claim that the WG can't clearly justify
> 	than have this document accidentally make a claim that later
> 	turns out to be inaccurate or misleading.

I for one believe replay protection is an important property for the 
protocol and I would like this claim to remain in the documents. 

IpSec AH uses sequence number with HMAC for replay protection (rfc2085), 
so does TLS (rfc2246). 

HMAC security considerations are discussed in rfc2104. The document 
describes security of the construct in general, and I believe the replay 
protection scheme is a small subset compared to that, given the so many 
bits an attacker can affect (sequence number, padding).

How about "to our best knowledge"?

> > Public key authentication is not vulnerable regardless
> > of whether the server's public key has been securely
> > distrubuted.
> >
[snip]
> > Now, of course MITM Client can simply defer completing
> > authentication with Server, and wait for client to
> > request Agent forwarding.  Then, using agent, obtain
> > the signature it needs to complete the authentication
> > with Server, and quickly bring MITM client --> Server
> > state up to date with Client --> MITM Server state.
> >
> > Maybe the whole argument isn't worth including.

In my opinion, this belongs into the agent spec, not here. [Don't do
agent forwarding for the servers you don't trust.]

> Seems to me that we ought to note the criticality
> of the quality of the PRNG implementation in the
> Security Considerations section of the document.

I second that.

Regards,
 Heikki Nousiainen

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 12 May 2003 16:28:05 -0400

On Monday, May 12, 2003, at 16:11 America/Montreal, Heikki Nousiainen 
> How about "to our best knowledge"?

Does someone want to try to construct a rationale for the
document about why folks believe the attempted replay
protection actually works ?

Barring that, maybe the words should be more tentative
(edit to taste):

	Through the use of a sequence number and ... and ...,
	the SSH specification seeks to provide protection against
	replay attacks.

???

> agent forwarding for the servers you don't trust.]

That would be OK with me.

Ran

---

From: Heikki Nousiainen <[email-masked]>
Date: Tue, 13 May 2003 02:00:26 +0300 (EEST)

> protection actually works ?

I'm not much of an editor, but maybe someone can slash something out of 
the following:

Running sequence number gives us an unique input for the MAC 
function regardless of the contents of the packet, as long as the 
sequence number doesn't wrap. With rekeying before the sequence number 
wraps, we get an unique input into the MAC function (well, HMAC at least) 
regardless of the sequence counter wrapping.

If an attacker captures a packet and inserts it within the SSH stream in 
order to replay the packet, either the sequence number or the MAC key will 
be different, and the MAC check will fail.

We assume MAC is secure of course, specifically it being infeasible to
construct x' such that MAC(x) = MAC(x'). For HMACs it is discussed in
rfc 2104.
I don't know if it's relevant or not, but given that an attacker wants to
re-use data from the packet, there are even less bits to work with, and,
even less of a chance of succeeding in creating a valid MAC.

 Regards,
  Heikki Nousiainen

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 May 2003 09:49:25 -0700

> even less of a chance of succeeding in creating a valid MAC.

I like this text.  Note that because the "packet sequence
number itself is not included in the packet sent over the wire"
out-of-sequence detection and recovery is not possible.

Rekeying before sequence number wrapping is a MUST though.

Cheers,

Nico
--

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 14 May 2003 13:49:58 -0700 (PDT)

Hi,

Continuing on with Section 11.2.3.  Please comment.

Thanks,
Chris

=====================================================================

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 the local security policy, if any, that
   should apply at the time of authentication because the kind of service
   being requested is not clear at that instant. For example, local
   policy might allow a user to access files on the server, but not start
   an interactive shell. However, during the authentication protocol, it
   is not known whether the user will be accessing files or attempting to
   use an interactive shell, or even both.  In any event, where local
   security policy for the server host exists, it MUST be applied and
   enforced correctly.

   Implementors are encouraged to provide a default local policy and
   make its parameters known to administrators and users.  At the
   discretion of the implementors, this default policy may be along the
   lines of 'anything goes' where there are no restrictions placed upon
   users, or it may be along the lines of 'excessively restrictive' in
   which case the administrators will have to actively make changes to
   this policy to meet their needs.  Alternatively, it may be some
   attempt at providing something practical and immediately useful to the
   administrators of the system so they don't have to put in much effort
   to get SSH working.  Whatever choice is made MUST be applied and
   enforced as required above.

---Notes---

[Nico:  What if no policy is available?

---Joseph---vv
Then there is nothing to enforce?

   ---Nico---vv
   The implementation MUST provide a default policy, either the "null"
   policy (anything goes) or a highly restrictive policy (the client can
   establish an SSHv2 connection but do nothing with it other than close
   it :).
   ---Nico---^^

Perhaps we should say,
  In any event, where local security policy for the server host exists,
  it MUST be applied and enforced correctly.

and sprinkle a few 'if any' around judiciously.
---Joseph---^^

---Nico---vv
Sure.
---Nico---^^

---Ran---vv
Those proposed edits seem reasonable to me.
---Ran---^^

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 14 May 2003 14:39:19 -0700 (PDT)

Hi,

Moving right along, another edit for your perusal.

Thanks,
Chris

===================================================================

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.  If the random data here (e.g., DH parameters)
   are pseudo-random then the PRNG should be cryptographically secure
   (i.e., its next output not easily guessed, even when knowing all
   previous outputs) and, furthermore, the PRNG should be seeded with some
   truly random inputs, or as random as can be available.  In any case,
   the amount of entropy available to a given client or server sometimes
   may be less than what is needed to run the protocol, in which case
   either one must resort to PRNGs anyways or refuse to run the protocol.
   In practice implementors will generally rely on some PRNG.  RFC 1750
   [1750] contains more discussion on this.

   The use of a MAC other than 'none' provides integrity and
   authentication.  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.  Because public key authentication exchanges are
   cryptographically bound to the session (i.e., to the initial key
   exchange) they cannot be successfully replayed in other sessions.
   Note that the session ID can be made public without harming the
   security of the protocol.

   If two session happen to have the same session ID [hash of key
   exchanges] then packets from one can be replayed against the other.
   It must be stressed that the chances of such an occurrence are,
   needless to say, minimal when using modern cryptographic methods.
   This is all the more so true when specifying larger hash function
   outputs and DH parameters.

   Replay detection using monotonically increasing sequence numbers as
   input to the MAC, or HMAC in some cases, is described in RFC 2085
   [2085], RFC 2246 [2246], RFC 2743 [2743], RFC 1964 [1964], RFC 2025
   [2025], and RFC 1510 [1510].  The underlying construct is discussed in
   RFC 2104 [2104].  Essentially a different sequence number in each
   packet ensures that at least this one input to the MAC function will
   be unique and will provide a nonrecurring MAC output that is not
   predictable to an attacker.  If the session stays active long enough,
   however, this sequence number will wrap.  This event may provide an
   attacker an opportunity to replay a previously recorded packet with an
   identical sequence number but only if the peers have not rekeyed since
   the transmission of the first packet with that sequence number.  If
   the peers have rekeyed, then the replay will be detected as the MAC
   check will fail.  For this reason, it must be emphasized that peers
   MUST rekey before a wrap of the sequence numbers.  Naturally, if an
   attacker does attempt to replay a captured packed before the peers
   have rekeyed, then the receiver of the duplicate packet will see that
   it has the sequence number of a packet that has already been received
   and will discard it.

[1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
       Recommendations for Security", RFC 1750, December 1994.

[2246] TLS
[2085] IPsec AH
[2104] HMAC
[2743] GSS-API
[1964] The KerberosV GSS-API mechanism
[2025] SPKM
[1510] Kerberos V

---Notes---

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

---Joseph---vv

---Nico---vv
Er, this is a time-honored technique.  Examples of protocols that
support the use of sequence numbers as a replay detection technique are:

 - GSS-API (generally) [RFC2743]
    - The KerberosV GSS-API mechanism (specifically) [RFC1964]
    - The Simple Public-Key GSS-API Mechanism (SPKM) (specifically)
[RFC2025]

 - Kerberos V [RFC1510]

 - TLS 1.0 [RFC2246]

Need I go on?  Probably not.  Each of those documents makes reference to
the use of sequence numbers for replay and out-of-sequence detection.
---Nico---^^

---Ran---vv
---Ran--^^

---Heikki---vv

---Heikki---^^

   ---Ran---vv

   ---Heikki---vv

   wraps, we get an unique input into the MAC function (well, HMAC at
least)

   If an attacker captures a packet and inserts it within the SSH stream
in
   order to replay the packet, either the sequence number or the MAC key
will
   be different, and the MAC check will fail.

   We assume MAC is secure of course, specifically it being infeasible to
   construct x' such that MAC(x) = MAC(x'). For HMACs it is discussed in
   rfc 2104.
   I don't know if it's relevant or not, but given that an attacker wants
to
   re-use data from the packet, there are even less bits to work with,
and,
   even less of a chance of succeeding in creating a valid MAC.
   ---Heikki---^^

---Chris---vv
I'm going to put that last part into the MITM section rather than here in
the Replay section.
---Chris---^^

---

From: "Joseph Galbraith" <[email-masked]>
Date: Wed, 14 May 2003 16:26:35 -0600

> Naturally, if an

The packet sequence number is not actually sent on
the wire, but is maintained independantly by each
side.

If an attacker replays a captured packet, it will
be input into the mac routines with the next valid
sequence number.  Since that is not the sequence
number that was used in the original computation of
the mac, it will show up as a MAC error.

Thanks, Chris, for compiling these.

- Joseph

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 15 May 2003 05:49:03 -0700 (PDT)

Hi Joseph,

> Thanks, Chris, for compiling these.

Got it.  Is what I've revised below better?

Also, would anyone object if I took the first paragraph out of this
section (Replay) and turned it into the basis for a separate section on
the importance of a good PRNG?  That would be consistent with the
discussion on the list to emphasize it's importance.

Thanks,
Chris

======================================================================

11.1.3 Replay

   Replay detection using monotonically increasing sequence numbers as
   input to the MAC, or HMAC in some cases, is described in RFC 2085
   [2085], RFC 2246 [2246], RFC 2743 [2743], RFC 1964 [1964], RFC 2025
   [2025], and RFC 1510 [1510].  The underlying construct is discussed in
   RFC 2104 [2104].  Essentially a different sequence number in each
   packet ensures that at least this one input to the MAC function will
   be unique and will provide a nonrecurring MAC output that is not
   predictable to an attacker.  If the session stays active long enough,
   however, this sequence number will wrap.  This event may provide an
   attacker an opportunity to replay a previously recorded packet with an
   identical sequence number but only if the peers have not rekeyed since
   the transmission of the first packet with that sequence number.  If
   the peers have rekeyed, then the replay will be detected as the MAC
   check will fail.  For this reason, it must be emphasized that peers
   MUST rekey before a wrap of the sequence numbers.  Naturally, if an
   attacker does attempt to replay a captured packet before the peers
   have rekeyed, then the receiver of the duplicate packet will not be
   able to validate the MAC and it will be discarded.  The reason that
   the MAC will fail is because the receiver will formulate a MAC based
   upon the packet contents, the shared secret, and the expected sequence
   number.  Since the replayed packet will not be using that expected
   sequence number (the sequence number of the replayed packet will have
   already been passed by the receiver) then the calculated MAC will not
   match the MAC received with the packet.

[2246] TLS
[2085] IPsec AH
[2104] HMAC
[2743] GSS-API

---Notes---

---Joseph---vv

---Nico---vv

 - Kerberos V [RFC1510]

 - TLS 1.0 [RFC2246]

---Ran---vv

---Heikki---vv

   ---Ran---vv

   ---Heikki---vv

---Chris---vv

---David Williams---vv
>   attacker does attempt to replay a captured packed before the peers
should read "... packet before the peers"
---David---^^

---Joseph---vv

   ---Chris---vv
   I knew that.  No, really; I knew that.  S-)
   ---Chris---^^

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 16 May 2003 13:47:34 -0700 (PDT)

Hi,

I've made changes to the first part of Section 11.3 "Authentication
Protocol" and 11.3.1 "Weak Transport" to address the concerns from Simon
and Nico about MITM and _user_ authentication mechanisms.  Please comment.

Thanks,
Chris

11.3 Authentication Protocol

   The purpose of this protocol is to perform client user authentication.
   It assumes that this run 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.

   Several authentication methods with different security characteristics
   are allowed.  It is up to the server's local policy to decide which
   methods (or combinations of methods) it is willing to accept for each
   user.  Authentication is no stronger than the weakest combination
   allowed.

   The server may go into a "sleep" period after repeated unsuccessful
   authentication attempts to make key search more difficult for
   attackers.  Care should be taken so that this doesn't become a
   self-denial of service vector.

11.3.1 Weak Transport

   If the transport layer does not provide confidentiality,
   authentication methods that rely on secret data SHOULD be disabled.
   If it does not provide strong integrity protection, requests to change
   authentication data (e.g. a password change) SHOULD be disabled to
   prevent an attacker from  modifying the ciphertext without being
   noticed, or rendering the new authentication data unusable (denial
   of service).

   The assumption as stated above that the Authentication Protocol only
   run over a secure transport that has previously authenticated the
   server is very important to note.  People deploying SSH are reminded
   of the consequences of man-in-the-middle attacks if the client does
   not have a very strong a priori association of the server with the
   host key of that server.  Specifically for the case of the
   Authentication Protocol the client may form a session to a
   man-in-the-middle attack device and divulge user credentials such as
   their username and password.  Even in the cases of authentication
   where no user credentials are divulged, an attacker may still gain
   information they shouldn't have by capturing key-strokes in much the
   same way that a honeypot works.