Chapter 3 of the Clean Code book has a section in it about functions. It mentions that the ideal number of arguments is Zero, then next to ideal is One. Two if you really have to. Three should be avoided, and anything further should require special justification. This may seem similar to the answers given by both rupjones and Péter Török, however there is more to this than simply picking an arbitrary number of method parameters to deal with.
As David Wallace mentions in his answer, Readability and Maintenance are your key considerations. Every parameter you add to a method increases it's level of relative difficulty in terms of the reader's ability to understand what is going on in the method. So while a new class may be justified, the number of parameters should not be the defining reason for this. Every class you create is a new file and entity to maintain, and while this can often be the better option if it helps to keep your code clean and easy to reuse and change, this needs to be balanced against the complexity of the method and its usage of the class itself.
There are also other considerations. Your classes should only be responsible for one conceptual thing. If your method parameters are only loosely related, a class might not be justified. Your parameter list may even seem to suggest that you might need two classes, or a composite, or some other combination.
As with classes, you should also consider that your methods should only do one thing. If you have a lot of method arguments, or even if you use a large number of parameters on a class, then perhaps you're trying to do too many individual things within in a single method. You may be able to break your method down into a set of smaller methods, and in doing so reduce the clutter of parameters, and reduce the complexity of your method(s).
Waiting for your parameter list to grow before refactoring can often mean you've left a problem to be dealt with later on. It's often better to address such concerns as soon as they appear, to save you needing to deal with potentially difficult refactorings later on. Of course, if you have good test coverage, then this shouldn't be too difficult, however this should not mean you should allow yourself to become too complacent about addressing potential problems in your code as they become known to you.
So sure, there are no real hard or fast rules about this, however you'll find if you keep your methods small, and then try and find a way to make them smaller and without repetition, that many of these issues to do with the number of parameters or classes - while no less relevant - will likely appear less often.