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

[Heikki Nousiainen <htn%sumu.org@localhost>]

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