[cisco-voip] tokenless CTL client - how to move devices between mixed mode clusters?

Fri Aug 14 23:34:23 EDT 2015

Ryan, thanks very much for the review and feedback, it was very helpful to
understand how TVS fits into the picture for scenarios like this.

In the case of my situation, the goal is to move devices from one
mixed-mode cluster to another mixed-mode cluster, and the CTLs on both
clusters were NOT signed by the same tokens. I realize it's possible to
manually add additional tokens to one side or the other and make both CTL
files have the same token list and signing token. However, I am trying to
see if it's possible to avoid some of those steps.

Is it definitely the case that there is no way to import the eToken's cert?
The following doc seems to indicate one can export the eToken cert to a
file using the Safenet tool that comes with the CTL client, and from there
it could be imported as a Phone-SAST-trust cert. In the flow they explained
(moving from tokenless mixed mode to eToken mixed mode), it appears they
add the eTokens as Phone-SAST-trust so that phones can learn via TVS to
trust the new tokens, as phone's current CTL doesn't contain them at all.
http://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118893-technote-cucm-00.html

Wouldn't you think following that same logic (adding the additional eToken
certs as Phone-SAST-trust) would allow TVS-aware devices to move from one
eToken mixed mode cluster to another eToken mixed mode cluster - even when
each cluster uses its own eTokens?

On Thu, Aug 13, 2015 at 9:35 AM, Ryan Ratliff (rratliff) <rratliff at cisco.com
> wrote:

> Inline.
>
>
> -Ryan
>
> On Aug 12, 2015, at 11:23 PM, Dave Goodwin <Dave.Goodwin at december.net>
> wrote:
>
> Ryan, let me lay out an example to make sure I understand. Please note
> that I haven't found anywhere that this has been well-explained, so I am
> laying out the following logic flow as a guess. Hopefully it's at least
> close; please set me straight. Say we have an old cluster and a new
> cluster, and that I want to move phones registered to the old cluster to
> instead register to the new cluster. Are you saying:
>
>
>    1. Download the CallManager.pem from new cluster pub and upload that
>    cert as phone-trust to the old cluster. This will enable the old cluster
>    TVS to have TVS-aware phones trust the new cluster.
>
> Correct.  I’d do this between both clusters so phones can move back and
> forth.
>
>
>    1. When the phone is told (say, via change in DHCP option 150 value)
>    to register to the new cluster, it will fail to authenticate the new
>    cluster's CTL file due to a different file signer.
>    2. So, the phone will then connect with its already-trusted TVS server
>    in the old cluster. At this point, since the new cluster pub cert was added
>    as phone-trust in the old cluster, TVS will instruct the phone to trust the
>    cert.
>
> Correct, phone will get CTLsepmac.tlv from the new cluster first, reach
> out to OLD TVS to validate it.
>
>
>    1. Then, based on TVS's go-ahead, the phone will now load and install
>    the new cluster CTL file.
>
> Correct.
>
>
>    1. At this stage, the phone will trust only the entries in the new
>    cluster CTL file - and also any certs that the new cluster's TVS can trust.
>
> The phone won’t use the new TVS until it gets a config file from the new
> cluster. Since the CTL should allow it to update the ITL and trust the new
> config file there should be no need for TVS after the CTL is loaded.
>
>
> Also, it seems like this procedure would also work with the token-based
> CTL client, as long as TVS is present and all the moving endpoints support
> TVS.
>
>
> Except that the token-based CTL file is signed by the eToken and you can’t
> import that cert.  The key to moving between clusters with tokens is that
> the CTLs on both clusters are signed by the same tokens.
>
>
> -Dave
>
> On Wed, Aug 12, 2015 at 10:45 PM, Brian Meade <bmeade90 at vt.edu> wrote:
>
>> Ryan, would you need to add the other cluster in the TFTP server list?  I
>> know I usually had to do this with the actual CTL client but not sure how
>> this would work in tokenless unless there's a CLI command for it.
>>
>> On Wed, Aug 12, 2015 at 10:03 PM, Ryan Ratliff (rratliff) <
>> rratliff at cisco.com> wrote:
>>
>>> The tokenless CTL is signed by the CallManager.pem on the publisher.
>>> Upload that cert as a phone-trust cert and TVS on that cluster will be able
>>> to authenticate files signed by that cert.
>>>
>>> CTL Record #:1
>>>           ----
>>> BYTEPOS TAG LENGTH VALUE
>>> ------- --- ------ -----
>>> 1 RECORDLENGTH 2 1701
>>> 2 DNSNAME 20 videolab-ucm11a-pub
>>> 3 SUBJECTNAME 70
>>> CN=videolab-ucm11a-pub.videolab.local;OU=TAC;O=Cisco;L=NC;ST=RTP;C=US
>>> 4 FUNCTION 2 System Administrator Security Token
>>> 5 ISSUERNAME 70
>>> CN=videolab-ucm11a-pub.videolab.local;OU=TAC;O=Cisco;L=NC;ST=RTP;C=US
>>> 6 SERIALNUMBER 16 52:0B:74:69:CF:4F:5A:CD:5B:48:6F:EE:99:9E:E0:B8
>>> 7 PUBLICKEY 270
>>> 8 SIGNATURE 256
>>> 9 CERTIFICATE 961 76 5D 15 01 0E 41 0D 16 BE EA 8A 98 29 33 EE 27 B6 3E
>>> D3 01 (SHA1 Hash HEX)
>>> 10 IPADDRESS 4
>>> This etoken was used to sign the CTL file.
>>>
>>>
>>> admin:show cert own CallManager/CallManager.pem
>>> [
>>>   Version: V3
>>>   Serial Number: 520B7469CF4F5ACD5B486FEE999EE0B8
>>> …
>>>
>>>
>>>  -
>>> Ryan
>>>
>>> On Aug 12, 2015, at 9:06 PM, Dave Goodwin <Dave.Goodwin at december.net>
>>> wrote:
>>>
>>> For anyone who has an environment with multiple mixed mode clusters (CTL
>>> file is present), do you know of a way to move devices from one cluster to
>>> another?
>>>
>>> Using the eToken SAST (physical USB devices), it seems you can do this
>>> by using the same signing token to sign the CTL file on each cluster. With
>>> the new tokenless CTL client, it seems each cluster's publisher private key
>>> is used to sign that cluster's CTL file - so it seems the old way will not
>>> work.
>>>
>>> I realize it can be done by deleting the CTL file on the phone (or
>>> factory reset) if you're standing in front of it, and I also realize there
>>> are commercial software tools that can perform feats like this (like
>>> UnifiedFX and other competitive offerings). I am looking for a way to do
>>> this without either of those methods.
>>>
>>> -Dave
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150814/dbad00fc/attachment.html>