Source of "Trust" for Trusted RFC

[Former Member]

Dear colleagues,

my favorite hobby (that's the one my company is actually paying for) is SAP auditing. I regularily spend some time - usually during the low season at the beginning of a new year - to improve my understanding of some of the security "mysteries".

I think I managed to understand the normal SSO(2) mechanism. IMHO, there is enough information available about security of the logon tickets and their security impact. Here the question is more whether the right measures are actually taken (e.g. a.o. the protection of the SAPSYS.pse file). To be honest: I found it interesting that it has been discussed in this forum how to back them up, where a better line of thought is probably that you actually should ensure they are not being backed-up at all ... .

But with regard to a similar topic - Trusted RFC - I failed to understand what the basis for the security is. I see some security key in table RFCSYSACL, I see where it comes from (finally from the dark dungeons of a System Call) - but I cannot judge at all what that implies.

Simple tests of mine indicate that this security key (as returned by RFC_TRUSTED_SYSTEM_SECURITY) is independent of the key used for SSF/SSO.

So: Are there also files / database entries containing private keys that are used for Trusted RFC and that consequently should also be dealt with very carefully ?

Thanks and regards,

Ralf

[fredrik_borlie]

Trusted RFC as far as I have seen it is nothing more than a technology to create a SSO-like login by using trust and authorizations.

First of all when trying to log on over a trusted RFC you need the S_RFCACL authorizations.

Then the trust is more or less to remove the need of the password when logging on.

So the trusting (receiving) system recevies the request for logon, checkes the trust-ACL and either approves or rejects the logon, if approved the user receives the SAME user account as in the trusted (calling) system.

So the things to be aware of is the SM59 and SMT1 transactions, and of course the rights to add S_RFCACL into roles/profiles.

Regards

Fredrik

[Former Member]

Dear Fredic,

sorry - I probably wasn't clear enough:

The question is: How can the trusting system be sure that the logon is coming from the trusted one and not from another system. There would be several options:

Bad ones: Name (very bad), IP-Address (pretty bad)

Good ones: Private/Public key technology with open standards.

I somehow assume that SAP is using one of the better options, but I fail to see what it really relies on (i.e. what has to be protected in order to make Trusted RFC secure).

Regards,

Ralf

[fredrik_borlie]

Ralf,

seems like your question needs to go to the hardcore techies in Walldorf.

It is a bit out of my league, I can make qualified guesses, but they will not give you the complete story!

However the qualified guess is that the RFCSECKEY is a hash of some kind of identifier. Logically this would be a combination of the logical system and something close to it, (maybe the server name?), since that is what is communicating to the trusting system.

Regards Fredrik

[WolfgangJanzen]

> The question is: How can the trusting system be sure

> that the logon is coming from the trusted one and not

> from another system. There would be several options:

> Bad ones: Name (very bad), IP-Address (pretty bad)

> Good ones: Private/Public key technology with open

> standards.

Neither-nor.

It is using a symmetric mechanism based on time-stamped and salted hash values. The salt is using a system-specific "spice" (DB key).

Notice: you can use the "RFC Trusted System" in conjunction with SNC (-> asymmetric mechanism); SNC is then used to authenticate the calling system (but not for SSO).

Regards, Wolfgang ("hardcore techie")

[Former Member]

Hi Wolfgang,

I was hoping that you'd answer ...

Will follow up on your hints. They probably help, but maybe you can explain a bit more. I failed to see the consequences and I still do ... . If it is somehow based on the "DB key", how do we prevent to have a fake system with the same key ?

(and that is the final "auditor" question)

Thanks anyway,

Ralf

[WolfgangJanzen]

Well, it's not just the name of the database that is used to determine the "DB key". From some existing SAP notes you can conclude that it's <u>at least</u> also the DB hostname that contributes.

Unless you <u>clone</u> the system (including the DBMS) the "DB key" will be different.

However, you'll face other problems if you operate two identical systems (one "original" and one "perfect clone") at the same time in the same system landscape.

It's really hard to tell "perfect clones" apart. But a lot of system components react "peevish" if assumed uniqueness is violated. Just like networks dislike duplicate IP addresses - a lot of "weird" problems result from that.

Regards, Wolfgang