Update 2017-11-05: "TLS-N" and others
I only recently learned of the existence of a new project. Some guys from the university of Zürich are working on something called "TLS-N" which is dedicated to bringing non-repudiation to TLS. There is no RFC that I know of yet. But they have a white paper. I'm not sure when/if we'll ever see this in the wild. But it's an interesting idea. See: https://tls-n.org
Also mentioned in their paper are some earlier attempts at bringing non-repudiation to TLS called TLS sign and TLS Evidence. Both attempts seem to have died a long time ago.
Your book is right. There is no non-repudiation for regular TLS packets.
When Alice tells Bob "Let's kill the president!" and Bob goes to tell the police, then Alice can always say: "I never said that." So Alice just repudiated the previous statement.
And in regular TLS there is no way for Bob to prove by himself that Alice has in fact repudiated her earlier statement.
So no, regular TLS does NOT provide non-repudiation. So your book was right.
Signatures can provide non-repudiation...
Now why is that? Asymmetric crypto allows you to provide proof of authorship by using Cryptographic Signatures. This WOULD in fact give non-repudiation. Then it would be straight forward to verify Yep, that really WAS signed with Alice's private key. And there is no getting out of that mathematic fact. (Of course then Alice could say: "But my key was stolen!" but there's no denying that her key was used to sign that particular message.)
So if in fact crypto signatures were used for regular TLS packets then they would be non-repudiatable. But signatures are NOT used for the regular TLS packet, so we don't have non-repudiation either.
...but TLS packets are MACed instead
Instead what is used to prove to the other side, My message has NOT been changed along the way is something called a MAC, a Message Authentication Code. MAC-functions work like this: You drop in two inputs and you get one output. One input is a secret MAC-key, the other input is the message that you want to protect. And what falls out is like a two-dozen byte hex-string, called a MAC Value. That string is sent along with the encrypted message. The recipient then feeds the same to inputs into the MAC function again and only accepts the decoded message if the MAC Value matches.
But since Alice and Bob both know the secret-MAC-key either one of them can generate MAC-values for whatever message they like. A MACed message says NOTHING about authorship of either Alice or Bob.
So if Bob goes and tells Charlie: Here's something evil Alice said!, then Alice can rightfully say: You could have written that your self!.
And thus: No non-repuditiation.
But: If there is a trusted third party (Alice's employer Charlie maybe) that has a network dump of the entire conversation between Alice and Bob then Alice will be in trouble. Regardless of any non-repudiation properties of TLS. Because Charlie vouches for the authenticity of the original network dump and Bob provides the key to decrypt the conversation. Of course Alice could still say Charlie is in on this! I'm being framed! but she's basically lost then.