Re: Comments on the reviesed Security Section open issues.

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

> 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