While there's no formal requirement, common practice is to estimate user stories with story points and tasks in units of time. There is no canonical formula for converting story points to ideal hours.
Story Point Estimates vs. Man-Hours
Story points are relative level-of-effort estimates. They typically measure whether a given story is bigger or harder than some other story. Story points are great at leveraging your team's cross-functional knowledge and the current size of your cone of uncertainty to provide a metric suitable for filtering what stories should fit into a given iteration, but they don't really say much about time.
A common Scrum practice is to use story points and historical velocity to determine which stories to accept into the current Sprint during Sprint Planning. Then, the second half of Sprint Planning is devoted to converting the stories into tasks on the Sprint Backlog.
It's at this point that time often enters into the planning. Some teams provide actual time estimates for each task, while other teams may simply ensure that no given task exceeds some maximum size (often two calendar days or some equivalent number of ideal man-hours). The purpose of this decomposition is primarily to ensure that tasks are done or not-done in a timely way, and to allow the team to "fail early" when a task ends up being larger or more complicated than expected.
Burn-Down and Velocity Units Should Match
If your velocity is measured in story points, then your burn-down chart should be, too. Rolling the aggregate time estimates from the Sprint Backlog back up and comparing the sum to your Sprint length can act as a sanity check that you
haven't under-estimated your stories, over-committed your resources, or exceeded your team's capacity for the iteration, but the comparison is a process control rather than a required Scrum artifact.
While the reality is that each iteration has a finite amount of time, the nature of Scrum lends itself to a lot of horse-trading during Sprint Planning and within each Sprint. The underlying theory is that while the Sprint Goal is immutable, the individual tasks needed to complete each story may be changed, added, or discarded as needed by the team. Because of the rate of change in tasks, task-based time estimates are generally unreliable for agile planning purposes.
Mike Cohn's Agile Estimating and Planning may provide you with a greater understanding of the differences between deterministic estimates and agile estimation practices. It's certainly worth reading, whether or not you drink the agile Kool-Aid.