Subject: RE: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts.

From: Heikki Nousiainen <[email-masked]>
Date: Tue, 15 Apr 2003 05:07:38 +0300 (EEST)

Some observations on the discussion on the security considerations.

Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts.,
Nicolas Williams, Fri 4/11/2003 9:22 AM
> > >>    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.
>
> IANAC, but what matters is that if the data in question (e.g., DH
> parameters) be 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 - not all
> implementations will have suitable sources of entropy).
>
> 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.
>
> [...]

I am not a cryptographer either, but cryptographically strong PRNG would 
be a safe choice.

The cookies are supposed to be used in the generation of the exchange
hash, for which:
 1) it must not be possible for either party to affect the resulting hash
 2) the resulting hash must be unique

That being said, the use of the cookies is dependant on the key exchange
method used. For what it's worth, it appears to me that 
'diffie-hellman-group1-sha1' is safe even if the cookies were constant 
(don't take my word for it, though).

[...]
> > >> 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.
>
> "Perfect forward secrecy" - see Google search:
[...]

This is not "perfect forward secrecy". From what I understand, the text
merely points out that the transport layer provides confidentiality and
integrity protection [given encryption and mac] for authentication
protocol (and methods within, e.g. password authentication) running on top 
of it.

Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts., R.J
Atkinson, Thu 4/10/2003 11:10 AM:
>>>    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.

TLS uses sequence number as an input into a MAC for replay protection, but
they don't cite any references either.

Again, I am not a cryptographer,
For HMAC constructs, if one assumes MAC(unencrypted packet) detects the 
tampering of the packet, MAC(sequence number || unencrypted packet) should
be secure as well. The underlying hash function should make certain that 
a change in the sequence number with the rest of the data being replayed 
will result in an invalid MAC.

Given no encryption, attacker knows:
 - next sequence number (nsn)
 - sequence number      (sn)
 packet:
  - packet len  (pkl)
  - padding len (pdl)
  - payload     (pl)
  - padding     (p)

In order to replay a packet, attacker needs to find  nsn, p'  such that:
H(K xor opad || H(K xor ipad || nsn || pkl || pdl || pl || p' )) =
H(K xor opad || H(K xor ipad ||  sn || pkl || pdl || pl || p  ))

nsn is 32bit, p' is 32-2048bit depending on the captured packet; K is 
512bit with sha1 and md5 (which of ???bits are secret with group1?)
An attacker has no knowledge of nor control over the whole input of either 
the inner or the outer hashing operation.

I can't work out the numbers, I'm afraid, but if the H is strong, 
HMAC(sequence_number || unencrypted packet) appears a good construct to me.

Implementation must make sure the rekeying happens before the sequence 
number wraps around.

Regards,
  Heikki Nousiainen

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Apr 2003 08:53:46 -0700

[...]
> protocol (and methods within, e.g. password authentication) running on top

Diffie-Hellman (DH) key exchanges have PFS as a property; specifically,
keys exchanged with DH are perfectly forward secure.

SSHv2 uses DH as the basis of the key exchange and derives session keys
from the DH exchange.

Ergo SSHv2 has PFS as a property.

The text should say so since this is an important cryptographic property
of the protocol.

Cheers,

Nico
--

---

From: Heikki Nousiainen <[email-masked]>
Date: Tue, 15 Apr 2003 19:29:44 +0300 (EEST)

> The text should say so since this is an important cryptographic property

Yes, PFS is a property we get wih DH key exchanges, but I don't think it 
applies to paragraph 11.2. Clearly, compromise of a session key leads into 
a compromise of secret data, e.g. password, sent over that session.

PFS is not property of the SSHv2 protocol, but a property of the key 
exchange method, and I'd be vary to lay claims on it in the SSHv2 
protocol level.

 Regards,
  Heikki Nousiainen

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Apr 2003 09:59:31 -0700

> a compromise of secret data, e.g. password, sent over that session.

Of course.  I'd lost track of the text in question - I was responding
to the question of what is PFS and what is a good reference for it.

Now that I look at it, I have to agree with you that the text should
clearly state that PFS is a property of the key exchange, that SSHv2 key
exchange provides PFS for the session keys used in the transport layer
(the proposed text reads: "The transport layer provides forward secrecy
for password authentication ...," this is not correct).

> exchange method, and I'd be vary to lay claims on it in the SSHv2 

This is evident from the definition of PFS.  SSHv2 sessions are secure
even if private keying/authentication material is later revealed[*], but
not if the session keys are revealed.  So, given the definition of PFS,
SSHv2 does have PFS.

[*] Of course, if the DH private parameters for the client and server
    and revealed then the session key is revealed, but these items can
    be thrown away after the key exchange completes.  It's worth
    pointing out that these items should not be allowed to end up on
    swap space and that they should be erased from memory as soon as the
    kex completes.

Perhaps there should be a sub-section on the key exchange phase of the
protocol.

Cheers,

Nico
--

---

From: Heikki Nousiainen <[email-masked]>
Date: Tue, 15 Apr 2003 21:16:40 +0300 (EEST)

> for password authentication ...," this is not correct).

Now that I read my e-mail again, I could have made my point clearer, 
sorry about that.

In conclusion, I think RJ Atkinson's original question '"perfect forward 
secrecy" or "forward secrecy"' is irrelevent to 11.2. I believe the intention
of this chapter is that authentication schemes based on shared secret are 
secured by the transport layer below, given encryption and MAC.

> not if the session keys are revealed.  So, given the definition of PFS,

My point is, since we don't know whether the key exchange algorithm 
provides PFS, I think we can't make an explicit claim about PFS in SSHv2. 
Certainly that is the case for diffie-hellman-group1-sha1 (and as far as 
I know, for the rest of the key exchange methods drafted), but not 
necessarily for all key exchange methods used within the protocol.

[...]
> Perhaps there should be a sub-section on the key exchange phase of the

The core document should address diffie-hellman-group1-sha1, and each key 
exhance method draft should discuss the security considerations for the 
given alogrihm.

 Best regards,
  Heikki Nousiainen

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Apr 2003 11:30:32 -0700

> necessarily for all key exchange methods used within the protocol.

Er, yes, but, a) today all key exchange methods specified for SSHv2 have
PFS, and b) one would hope that all future ones will also.

Of course, (b) is no guarantee of anything, so I must cede the point :)

> exhance method draft should discuss the security considerations for the 

I think the core doc's security considerations section can certainly
state that "if the kex used has PFS then the session keys can be
perfectly forward secure" or something like that.  Point is, it's worth
pointing out, in the core drafts, that PFS is there [always today, even
if perhaps not always tomorrow].

Cheers,

Nico
--