I ran into this problem recently when a customer was on board with our methodology, but higher management got wind that the developers were spending their time testing rather than developing and were concerned about this - after all, they had QA people to do the testing!
This is how I dealt with the situation (read my old blog post for more details). I compared our estimated hours against actual hours for the project and then compared our defect rate against other teams' defect rate. In our case these numbers compared favourably and there were no more concerns.
My conclusion based on this experience is:
...the best way to convince anyone that your approach to doing something is practical and pragmatic, is to do it and measure it against other approaches. People don’t care about dogma, or why you think something should be the best way. Only by showing people the numbers and measuring the effectiveness of your approach can you truly show that your practices are effective.
On other projects, we've worked alongside customer developers who didn't create unit tests or do TDD and we've had to maintain tests that they break. However, it becomes very easy to sell the TDD approach to those customer developers when you can tell them what they've broken in the code before they know!
So in your case, I would do it by stealth if necessary (perhaps there is a small area of the code that you can start to test that changes often or that you are responsible for), but keep track of your numbers - what is the effort for creating your tests? What is the defect rate? How does this compare with other projects / team members?
In my opinion, no-one should need to ask permission or apologize for wanting to do their job properly and any professional developer should be attempting to test their code with automated tests wherever it's possible and practical. Hopefully it's both of these things in your case. Good luck!