Layer7 API Management

  • Private Community
 View Only

  • 1.  Kerberos Communication

    Posted Jan 10, 2020 07:04 AM
    Hi

    We authenticate Requests with Kerberos Token on the API Gateways and this works fine.

    • We import a Keytab file on the Gateway
    • We use the "Require WS-Security Kerberos Token Profile Credentials" Assertion to authenticate the Requests

    However, on one Gateway I noticed SocketTimeoutExceptions while the Gateway tries to contact the KDC Server (UDP 88, see below). This is expected since the communication between Gateway and KDC is not allowed (Firewall).

    Questions:
    • What is the Gateway trying to do here?
    • Should we allow this communication?
    • Is there anything supposed not to working when we block this communication? We did not experience any problems so far.
    • I expect the Gateway to be independent of the KDC due to the imported Keytab-File. Am I wrong on this Kerberos theory?

    Thanks
    Stephan

    2020-01-08T10:47:51.641+0100 INFO    5336144 STDOUT: SocketTimeOutException with attempt: 3
2020-01-08T10:47:51.641+0100 INFO    5336144 STDOUT: >>> KrbKdcReq send: error trying [IP-Number]:88
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: java.net.SocketTimeoutException: Receive timed out
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at java.net.PlainDatagramSocketImpl.receive0(Native Method)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at java.net.DatagramSocket.receive(DatagramSocket.java:812)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at sun.security.krb5.internal.UDPClient.receive(NetClient.java:206)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:411)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at sun.security.krb5.KdcComm$KdcCommunication.run(KdcComm.java:364)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at java.security.AccessController.doPrivileged(Native Method)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at sun.security.krb5.KdcComm.send(KdcComm.java:348)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at sun.security.krb5.KdcComm.sendIfPossible(KdcComm.java:253)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at sun.security.krb5.KdcComm.send(KdcComm.java:229)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at sun.security.krb5.KdcComm.send(KdcComm.java:200)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:316)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:776)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at sun.reflect.GeneratedMethodAccessor83183.invoke(Unknown Source)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at java.lang.reflect.Method.invoke(Method.java:498)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at java.security.AccessController.doPrivileged(Native Method)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at com.l7tech.kerberos.KerberosClient.getKerberosAcceptPrincipal(Unknown Source)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at com.l7tech.server.aj.run(Unknown Source)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: 	at java.lang.Thread.run(Thread.java:748)
2020-01-08T10:47:51.643+0100 INFO    5336144 STDOUT: >>> KdcAccessibility: add [IP-Number]:88
2020-01-08T10:47:51.643+0100 WARNING 5336144 com.l7tech.server.KerberosAdminImpl: Kerberos error getting principal: [principal]
2020-01-08T10:47:53.955+0100 INFO    5336167 STDOUT: SocketTimeOutException with attempt: 2
2020-01-08T10:47:53.955+0100 INFO    5336167 STDOUT: >>> KDCCommunication: kdc=[IP-Number] UDP:88, timeout=30000,Attempt =3, #bytes=155
​


  • 2.  RE: Kerberos Communication

    Broadcom Employee
    Posted Jan 12, 2020 05:32 PM
    Dear Stephen,
    Please refer to RFC 4120, 
    https://tools.ietf.org/html/rfc4120#page-102

    Kerberos is primarily a UDP protocol, Kerberos client MAY first use UDP protocol (default port 88) for contacting KDC, it can fail back to TCP port 88 if UDP fails.
    (on old rfc1510, only UDP for kerberos)

    Since your use case is working, I believe your firewall has TCP port 88 opened. 
    But I would concern on the performance, as it seems it will wait for UDP timeout each time calling the KDC.

    Regards,
    Mark
    Original Message


  • 3.  RE: Kerberos Communication

    Posted Jan 13, 2020 04:59 AM
    Hi Mark

    Thanks a lot for your answer. Yes, the fallback to TCP could be the reason it works, I will check that.

    However, the main question is: What tries the Gateway to do? The Gateway is not the Kerberos client, it is the Kerberos Service that has a Keytab file and authenticates Kerberos tokens sent by the clients.

    As far as I understand Kerberos and according to this answer, the Kerberos Service has no need to communicate with the KDC. Only the Client does that to get tokens. The Kerberos Service can be off-site (Cloud, partner company, whatever) and it would be a problem if you had to allow such foreign networks to access your internal KDC, wouldn't it?

    Regards
    Stephan
    Original Message


  • 4.  RE: Kerberos Communication
    Best Answer

    Broadcom Employee
    Posted Jan 14, 2020 05:58 PM
    Dear Stephan,
    I am not sure if the gateway works like that.
    But at least, the gateway will contact KDC to validate the keytab (you can see "Validate Keytab" button on Kerberos Configuration window, and by default it will automatically validate keytab ).

    You can enable kerberos debug as below, then you can see what gateway is trying to do,
    1. vi /opt/SecureSpan/Gateway/node/default/etc/conf/node.properties
    add one line,
    node.java.opts = -Dsun.security.krb5.debug=true

    2. restart gateway
    service ssg restart

    3. check the ssg log for kerberos transactions,
    /opt/SecureSpan/Gateway/node/default/var/logs/ssg_0_0.log

    Regards,
    Mark
    Original Message


  • 5.  RE: Kerberos Communication

    Posted Jan 15, 2020 06:21 AM
    Thanks for the point with the keytab validation. That is of course a reason to contact the KDC.

    I observed the following with our firewall staff:
    • Our gateways (even Production) did NOT contact the KDC in the last 7 days. So I can assume that this is only done for special things like keytab validation
    • When I press the button to validate the keytab, the gateway tries 3 times to contact the KDC on UDP/88
    • If all 3 fail, there is no fallback to TCP/88
    • In the client, I don't get an error message or similar. I just notice a quick GUI change (half a second or so), then the former keytab table reappears. The short "flashing" GUI could be an error message, but it disappears too fast :-)

    Summary:
    • The gateway does not contact the KDC to validate Kerberos tokens (as expected)
    • Keytab validation is probably the only reason to contact the KDC as long as you use the gateway as Kerberos Service
    • If the gateway has the Kerberos client role (retrieve Kerberos tokens) it must of course communicate with the KDC for that

    Original Message