Forum Discussion

Jeff_Green_4244's avatar
Jeff_Green_4244
Icon for Nimbostratus rankNimbostratus
Nov 06, 2011

Create Domino LTPA token on F5 problem

Hi,

 

 

I'm trying to use the code at

 

 

http://per.lausten.dk/blog/2009/06/how-to-create-a-ltpa-session-cookie-for-lotus-domino-using-f5.html

 

 

to create a Domino LTPA token but I am getting the following error showing on the Domino server:

 

Token does not lead with 0 [Single Sign-On token is invalid].

 

 

The token should begin with the version number 0123 e.g. from the code

 

set ltpa_version "\x00\x01\x02\x03"

 

 

However, after decoding the token and then looking at it in a hex editor the version number shows as:

 

 

C0 80 01 02 03 .......

 

 

Can somebody explain to me why the \x00 is being changed to C0 80 please?

 

 

I've experimented putting other numbers in thefirst position to see what happens e.g. \x01\x01\x02\x03 and the hex readout looks correct i.e. 01 01 02 03. It only fails when I use a \x00 in the first position.

 

 

Thanks for any suggestions.

 

Jeff

 

17 Replies

  • Hi,

    the append function in the original iRule might cause the problem.

    Nov 9 03:49:44 local/tmm info tmm[5158]: Rule irule03 : WITHOUT append

    Nov 9 03:49:44 local/tmm info tmm[5158]: Rule irule03 : Text: 0001020348656c6c6f20576f726c64

    Nov 9 03:49:44 local/tmm info tmm[5158]: Rule irule03 : Text encoded: 414145434130686c6247787649466476636d786b

    Nov 9 03:49:44 local/tmm info tmm[5158]: Rule irule03 : Text decoded: 0001020348656c6c6f20576f726c64

    Nov 9 03:49:57 local/tmm info tmm[5158]: Rule irule03 : WITH append

    Nov 9 03:49:57 local/tmm info tmm[5158]: Rule irule03 : Text: 0001020348656c6c6f20576f726c64

    Nov 9 03:49:57 local/tmm info tmm[5158]: Rule irule03 : Text encoded: 7749414241674e495a5778736279425862334a735a413d3d

    Nov 9 03:49:57 local/tmm info tmm[5158]: Rule irule03 : Text decoded: c08001020348656c6c6f20576f726c64

     
    [root@lb01:Active] log  b rule irule03 list
    rule irule03 {
       when RULE_INIT {
    
     log local0. "WITHOUT append"
     set text "\x00\x01\x02\x03Hello World"
    
     log local0. "WITH append"
     set hello "\x00\x01\x02\x03Hello World"
     set text {}
     append text $hello
    
     set text_enc [b64encode $text]
     set text_dec [b64decode $text_enc]
     binary scan $text H* text_hex
     binary scan $text_enc H* text_enc_hex
     binary scan $text_dec H* text_dec_hex
    
     log local0. "Text: $text_hex"
     log local0. "Text encoded: $text_enc_hex"
     log local0. "Text decoded: $text_dec_hex"
    }
    }
    

    Is this a bug?

    EDIT: Something is wrong with the string when it is initialized as an empty string with 'set text {}'. Anyway, if I change the init to -- set text '' --, the output looks like this, and it's still wrong (c080 in the string).

    Nov 9 03:54:20 local/tmm info tmm[5158]: Rule irule03 : WITH append

    Nov 9 03:54:20 local/tmm info tmm[5158]: Rule irule03 : Text: 27270001020348656c6c6f20576f726c64

    Nov 9 03:54:20 local/tmm info tmm[5158]: Rule irule03 : Text encoded: 4a796641674145434130686c6247787649466476636d786b

    Nov 9 03:54:20 local/tmm info tmm[5158]: Rule irule03 : Text decoded: 2727c08001020348656c6c6f20576f726c64

    So, it's only a problem, if the string is initialized as an empty string and if one uses 'append' to add other strings to it. I'm not sure if this is O.K.

    EDIT2: Furthermore, the problem only exists, if the appended string starts with \x00.

    Nov 9 04:20:36 local/tmm info tmm[5158]: Rule irule03 : WITH append

    Nov 9 04:20:36 local/tmm info tmm[5158]: Rule irule03 : Text: 01020348656c6c6f20576f726c64

    Nov 9 04:20:36 local/tmm info tmm[5158]: Rule irule03 : Text encoded: 415149445347567362473867563239796247513d

    Nov 9 04:20:36 local/tmm info tmm[5158]: Rule irule03 : Text decoded: 01020348656c6c6f20576f726c64

    To sum it up.

    1.) create a string that starts with \x00

    2.) initialize another string with "set string2 {}"

    3.) append the first string to the second string. 'append string2 $string1'

    4.) b64encode and then b64decode string2 and the result will contain (or start with) c080.

    This really looks like a bug.

    Regards

    Kurt Knochner
  • why does it seem okay to me?

     

     

    maybe the TMOS version you've used, 10.2.3. I've tested with 10.2.2 and Jeff with 9.4.4 and 10.2.0.

     

     

    EDIT: I ran the test again and this time it gave the correct result. Strange. I'll try to figure out in which cases it will produce the wrong result.

     

     

    Regards

     

    Kurt Knochner

     

     

     

     

     

  • why does it seem okay to me?

    [root@ve1023:Active] config  b version|grep -iA 1 version
    BIG-IP Version 10.2.3 112.0
    Final Edition
    [root@ve1023:Active] config  b rule myrule list
    rule myrule {
       when RULE_INIT {
     set text "\x00\x01\x02\x03Hello World"
     set text_enc [b64encode $text]
     set text_dec [b64decode $text_enc]
     binary scan $text H* text_hex
     binary scan $text_enc H* text_enc_hex
     binary scan $text_dec H* text_dec_hex
    
     log local0. "Text: $text_hex"
     log local0. "Text encoded: $text_enc_hex"
     log local0. "Text decoded: $text_dec_hex"
    }
    }
    
    [root@ve1023:Active] config  grep -i myrule /var/log/ltm
    Nov  8 23:54:37 local/ve1023 err mcpd[3752]: 01020066:3: The requested rule (myrule) already exists in partition Common.
    Nov  8 23:54:37 local/tmm info tmm[4766]: Rule myrule : Text: 0001020348656c6c6f20576f726c64
    Nov  8 23:54:37 local/tmm info tmm[4766]: Rule myrule : Text encoded: 414145434130686c6247787649466476636d786b
    Nov  8 23:54:37 local/tmm info tmm[4766]: Rule myrule : Text decoded: 0001020348656c6c6f20576f726c64
    
    
  • Hi,

    I'm able to reproduce what you've seen.

     
     set text "\x00\x01\x02\x03Hello World"
     set text_enc [b64encode $text]
     set text_dec [b64decode $text_enc]
     binary scan $text H* text_hex
     binary scan $text_enc H* text_enc_hex
     binary scan $text_dec H* text_dec_hex
    
     log local0. "Text: $text_hex"
     log local0. "Text encoded: $text_enc_hex"
     log local0. "Text decoded: $text_dec_hex"
    

    The result:

    Nov 9 03:13:54 local/tmm info tmm[5158]: Rule rule01 : Text: 0001020348656c6c6f20576f726c64

    Nov 9 03:13:54 local/tmm info tmm[5158]: Rule rule01 : Text encoded: 7749414241674e495a5778736279425862334a735a413d3d

    Nov 9 03:13:54 local/tmm info tmm[5158]: Rule rule01 : Text decoded: c08001020348656c6c6f20576f726c64

    So, yes there is a c080 in front of the text and it only happens if the initial string starts with \x00.

    This looks like a bug. Maybe something with internal string handling. Please open a case with my example and ask support what's going wrong. It would be nice if you could update this thread as soon as you get a reply from support.

    Thanks!

    Regards

    Kurt Knochner
  • What we've now found is when the token is subsequently b64encoded, then b64decoded, the leading 00 is replaced with the C0 80. This happens on both v9.4.4 and v10.2.0.

     

     

    hm.. can you post some sample code? There is no b64decode in the original iRule, at least not for the token.

     

     

    Regards

     

    Kurt Knochner
  • Hi Kurt,

     

     

    No errors are showing in the ltm log. I added the debug lines and I get the same result as you. Leading 00 is where it shoud be. So I know that part is working correctly. Thanks.

     

     

    What we've now found is when the token is subsequently b64encoded, then b64decoded, the leading 00 is replaced with the C0 80. This happens on both v9.4.4 and v10.2.0.

     

     

    Regards,

     

    Jeff Green
  • Jeff,

     

     

    are there any TCL errors in /var/log/ltm (grep TCL /var/log/ltm)?

     

     

    If there are no errors, could you please add some log statements to the iRule and post the output (see /var/log/ltm) here?

     

     

    
      Final Base64 encoded token
     set ltpa_token_final [b64encode $ltpa_token_raw]
    
      please add these lines.
     binary scan $ltpa_token_raw H* ltpa_token_raw_hex
     log local0. "LTP_TOKEN Hex: $ltpa_token_raw_hex"
     log local0. "LTP_TOKEN Final: $ltpa_token_final"
    

     

     

    If I run the code on my test system, the HEX encoded string looks good.

     

     

    local/tmm info tmm[5104]: Rule rule01 : LTP_TOKEN Hex: 0001020334454237453145363445423745384545e3f09dbbff9248a638a6bfeeb876f66c52df6cb2

     

    local/tmm info tmm[5104]: Rule rule01 : LTP_TOKEN Final: wIABAgM0RUI3RTFFNjRFQjdFOEVFw6PDsMKdwrvDv8KSSMKmOMKmwr/DrsK4dsO2bFLDn2zCsg==

     

     

    Regards

     

    Kurt Knochner