How Kerberos was evolved - Inside Story Part 2

In my last post I discussed few steps for the evolution of kerberos protocol implementation. In this post I am going to conclude it so read on...

Just want to recolect the problem statements where I left in last post so you get some continuity

Problems

1) Once tickets are generated at the user system and passed over the wire for service access they can be tapped over the wire. For example user got the encrypted ticket during authentication process and it was successfully decrypted, Now user will pass this ticket to mail server for mail access. At this time someone can tap the ticket and replay it later.

2) Tickets are good for ever. Once assigned no ticket session expiry.

For solving first problem Authentication Server (Ticket Granting Server [TGS]) will generate a sessionkey which will be sent to the user. TGS will also send a ticket encrypted with service password to the user. Below is the detailed structure

[SesssionKey:[*Service Ticket encrypted with service Key]]

* Structure of service ticket is [SessionKey:lifespan:issuing time:service name]

issuing time and lifespan are introduced so tickets can be valid for specific amount of time and not good for ever.

TGS will encrypt session key and ticket with user's password to solve the replay attack because password is only shared between user and Authentication Server.

Step by Step process for user authentication and service access

1) User enters the userid and KINIT program on the user machine sends that to TGS for authentication.

2) TGS server creates Ticket Granting Ticket [TGT] (this will be used to get service tickets)and send to the user by encrypting the whole content by users passwod.

3) User decrypts the TGT using the password to get the ticket. If someone spoof the packet then he will not be able to decrypt it as the password is shared between user and TGS only.

4) User wants to access his mail but user does not have mail service ticket so user contacts TGT for mail service ticket by submitting Authenticator,TGT, Name of the user and workstation address. This Authenticator with the session key sent by the TGS in the initial handshaking.

* Authenticator = {username:servie name: time stamp : lifespan}

5) TGS will get the session key of the user and decrypts the authenticator. After validating the identity it generates following and send by encrypting the whole content using the SESSION Key.

i) Ticket for the mail service. This ticket has the session key, service name, lifespan, timestamp and client address. This ticket is encrypted with the service password. (Even User can not decrypt it)
ii) Session key to be used to encrypt the conversation with mail service

6) User recieves the packet and decrypts the content using the session key (Given during first handshake with the TGS).

7) User prepares the Authenticator and encrypts it with the SESSION key (generated for the mail service communication in step 5).

8) Mail Service recieves the Authenticator and Ticket. Decryptst the ticket using it's password to get the session key. Using the session key decrypts the Authenticator. Validate the Authenticator and sends the acknowledgement to the user by encrypting the session key.

9) User receives the acknowledgement and start using the service.

How Kerberos was evolved - Inside Story Part 1

I always wanted to get something on kerberos (earlier name Charon) which can give me inside of the protocol like why,how, what etc...

In this post I am trying to explain this in some easy steps with problem and solution approach for the evolution of this protocol.

Below Image displays the first version of there discussion



Problem with the first version is that anybody can impersonate anybody easily so no security and accountability. There is no Authentication (NO PASSWORD) piece involved it is just the userid which you pass to get the service.

Below Image solves first problem by having a centralized authentication server. Every user and every service has a password which is stored in the authentication server named CHAROS.

Here is how it work

1) User Authenticates with the centralized server
2) Server authenticates the user and give him a TICKET (encrypted text which is encrypted with service password)

*encrypted text contains (Username and servicename and IP address of the user)
3) User passes this ticket to the service and service will verify user's identity to give access




Problems with this:

1) User has to authenticate every time user wants to use any service. For example user has got the TICKET for mail service but wants to print some mail then he has to again enter the password
2) Password is flowing on the network in clear text (people can capture the password on the network)


Above problem is solve by introducing another component called ticket granting service in the authentication service. It will grant the ticket which can be reused.

Another componet which is added at the system level is KINIT service which is responsible for handshaking with the authentication service. Here is how it works

1) KINIT service will take userid and password from the user and will pass the userid to the authentication service (it will NOT pass the password at all)
2) Authentication service will build the TICKET GRANTING TICKET and encrypt it with the user's password because it knows what the user password is.
3) KINIT will decrypt the token using user's password. If it is able to decrypt it successfully then user is authenticated.





Problems:

1) Once tickets are generated at the user system and passed over the wire for service access they can be tapped over the wire. For example user got the encrypted ticket during authentication process and it was successfully decrypted, Now user will pass this ticket to mail server for mail access. At this time someone can tap the ticket and replay it later.

2) Tickets are good for ever. Once assigned no ticket session expiry.

Keep reading this because I will post rest of the story in next post...

SAML in Action

Today I was browsing the net to find more on SAML and came across a good implementation of SAML by google. In this post I am going detailed out my understanding of SAML implementation by google.

Security Assertion Markup Language(SAML): It is used in a federated environment where TRUST is needed between service provider (like google gmail, gtalk etc) and identity provider (any organization using google applications). Google is providing it's services like gmail, gtalk etc for enterprises who wants to use these applications with there corporate domain. To enable these services and provide Single Sign On between corporate network and google application network SAML can be used.

Below diagram shows four main entities used for SAML implementation

1. Actor : User using the application hosted at service provider


2. Service Provider : In this case Google exposing it's services like gmail, gtalk etc.


3. Identity Provider : Corporate using the google services.


4. Repository : Store for holding the user base for the identity provider.

Step By Step Flow of SAML in Action

1) User accesses the service hosed by the service provider. There could be two different scenarios

a) User is already authenticated at the corporate (identity provider) :If user is already authenticated, identity provider will set the session in the cookie. This cookie will be passed to the user when service provider redirects the user for SAML assertion. Identity provider will validate the cookie and pass the user information in the assertion to the service provider without asking user to enter the credentials.

b) User is directly accessing the service without logging into the corporate portal: If the user is accessing the service without logging into the corporate network user will be asked to enter the credentials when service provider request for an assertion at the identity provider.

2) Service Provider requests for an assertion: As we know that SAML request and SAML response (assertions) are sent using XML over HTTP/S, it is mandatory to define the XML structure in which service provider will request for the assertion and identity provider will respond with an assertion. Google has also defined such schema's. Google is also using the RSA/DSA key pair (public/private) to validate the assertion sent by the identity provider. Corporate using the SAML SSO needs to generate the key pair and register the public key with google assertion validator (This is the component residing at the service provider [in this case google] to extract the user information from the assertion).

3)Identity Provider generates and sends the assertion: Identity provider will authenticate the user based on two cases mentioned in step 1 and passes the userid to the service provider.

Since we can not pass directly XML documents as the request parameters (GET/POST) over HTTP it is required to encode the SAML request and SAML responses.

Samples of the SAML request/responses

SAML Request XML format

<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="fpagejpkbhmddfodlbmnfhdginimekieckijbeei"
Version="2.0"
IssueInstant="2006-05-02T08:49:40Z"
ProtocolBinding="urn:oasis:names.tc:SAML:2.0:bindings:HTTP-Redirect"
ProviderName="google.com"
AssertionConsumerServiceURL="https://www.google.com/hosted/psosamldemo.net/acs"/>

Encoded Request passed to the identity provider

identity_provider.html?SAMLRequest=eJxdkE1PwzAMhs%2F9F1XubcM00IjWTQOEmDTQtA8O3NrEa7M1donTjZ9P2UAgrraf1489nn64Jj6CZ0uYi6tUihhQk7FY5WK7eUxGYjoZc%2BGaVs26UOMK3jvgEEc9iKzOnVx0HhUVbFlh4YBV0Go9e16oQSpV6ymQpkZE84dc7Nqign17KGtnzI5MUzrc1aayaB0cLOiD3ZcAVsTR649Wn9LDzB3MkUOBoS9JeZPI60QONnKkhrdqKN9EtPxedWfxcsE%2Fr%2FSvV3kZYvW02SyTFRjrQYdzyNEa8C89kYuKqGog1eRENGMGH3qle0LuHPg1%2BKPVsF0tclGH0LLKstPplP5CWU0cwGQt09erDDhKEUJWaBbZ5BPy1YRc&RelayState=http%3A%2F%2Fwww.google.com%2Fhosted%2Fpsosamldemo.net%2FDashboard

SAML Response Generated at the Identity provider

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
ID="hedangifkfodeigidaeijpdnfjkfbnegddealebo"
IssueInstant="2006-08-17T10:05:29Z"
Version="2.0">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>sJAWNV9VzT+CghjrHsJSXAY9DRk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>X9Fx4pFSOlI2byrLXBw8azq26xxdqeF7w1UfQtcZ5l7HfXfkq9Tp2w==</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9jQTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==</P>
<Q>li7dzDacuo67Jg7mtqEm2TRuOMU=</Q>
<G>Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==</G>
<Y>VMoV//Oh7VytBbZVySNmVZevV1bw7vmJwx5hHszeR25bforBFA19nk+3ehg6SgUjWiXn7HsybemjRFs5x4+XFg==</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="dojnoaponicbieffopfdecilinaepodfimmkpjij"
IssueInstant="2003-04-17T00:46:02Z"
Version="2.0">
<Issuer>https://www.opensaml.org/IDP </Issuer>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> demouser </NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
</Subject>
<Conditions NotBefore="2003-04-17T00:46:02Z" NotOnOrAfter="2008-04-17T00:51:02Z"> </Conditions>
<AuthnStatement AuthnInstant="2006-08-17T10:05:29Z">
<AuthnContext>
<AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:Password </AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>

Technorati : SAML

Technorati : SAML

DSML Introduction

Directory Services Markup Language (DSML) provides a mechanism for accessing directory servers as XML document. It evolved with version 1.0 which just gave flexibility to read the directory servers but version 2.0 came with more flexibility. Using version 2.0 directory server entries can be updated.

DSML functionality is motivated by scenarios including:

1) Hand held device which does not have LDAP client.
2) Applicaion programs developed using XML tools and application needs to access LDAP.
3) A program needs to access a directory across the firewall and firewall does not allow LDAP ports.
Click on the below image to view the animation.

4) Integrating two different vendor directory servers.

Most of the existing directory server vendors support the DSML but it needs to be enabled explicitely. Below are some links specific to Sun DS.

How to enable DSML support

Accessing Directory using DSML

DSML tools are also available for integration with existing applications.

Technorati : dsml introduction

How SPML works

What is SPML?

The Service Provisioning Markup language (SPML) is the open standard protocol for the integration and interoperation of service provisioning requests. SPML version 1.0 is a draft OASIS standard due for ratification in Summer 2003.

What does 'service provisioning' mean?

Service provisioning refers to the "preparation beforehand" of IT systems' materials or supplies required to carry out a specific activity. It goes beyond the initial "contingency" of providing resources, to encompass the entire lifecycle management of these resources. This includes the provisioning of digital services such as user accounts and access privileges on systems, networks and applications, as well as the provisioning of non-digital or "physical" resources such as cell phones and credit cards.


How it is used?

Products like Sun Identity Manager provides SPML interface so end applications/systems can provision/de-provision user accounts on the system. Designers should expose the web service calls which internally use the SPML calls to interact with the system. This way different systems can integrate with centralized system for necessray action. Extra care should be taken before exposing the web-service calls to the whole world as web service is exposing critical functions.

Here is a little program which I have written for creating user account using SPML on Sun Identity Manager

import org.openspml.client.LighthouseClient;
import org.openspml.message.ExtendedRequest;
import org.openspml.message.ExtendedResponse;
import org.openspml.message.SpmlResponse;

public class CallingCustomWorkflow {

/**
* @param args
*/
public static void main(String[] args) {
try
{
LighthouseClient client = new LighthouseClient();
client.setTrace(true);
client.setUrl("http://localhost/idm6/servlet/rpcrouter2");
client.setUser("configurator");
client.setPassword("password");
ExtendedRequest req = new ExtendedRequest();

req.setOperationIdentifier("launchProcess");
req.setAttribute("accountId","abcdefg");
req.setAttribute("firstname","abcd");
req.setAttribute("lastname","abcd");
req.setAttribute("password","gdswer");
req.setAttribute("resources","LDAP");


req.setAttribute("process","SPMLWorkflow");
SpmlResponse res = client.request(req);



}
catch (Exception e)
{

}
}

}

How HTTP Keep Alive works?

HTTP Keep Alive
Http Keep-Alive seems to be massively misunderstood. Here's a short description of how it works, under both 1.0 and 1.1, with some added information about how Java handles it.

Http operates on what is called a request-response paradigm. This means that a _client_ generates a request for information, and passes it to the server, which answers it. In the original implementation of HTTP, each request created a new socket connection to the server, sent the request, then read from that connection to get the response.

This approach had one big advantage - it was simple. Simple to describe, simple to understand, and simple to code. It also had one big disadvantage - it was slow. So, keep-alive connections were invented for HTTP.

HTTP/1.0
Under HTTP 1.0, there is no official specification for how keepalive operates. It was, in essence, tacked on to an existing protocol. If the browser supports keep-alive, it adds an additional header to the request:

Connection: Keep-Alive

Then, when the server receives this request and generates a response, it also adds a header to the response:

Connection: Keep-Alive

Following this, the connection is NOT dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.

HTTP/1.1
Under HTTP 1.1, the official keepalive method is different. All connections are kept alive, unless stated otherwise with the following header:

Connection: close

The Connection: Keep-Alive header no longer has any meaning because of this.

Additionally, an optional Keep-Alive: header is described, but is so underspecified as to be meaningless. Avoid it.


Curtsey: http://www.io.com/~maus/HttpKeepAlive.html