[reSIProcate] ServerAuthManager and RADIUS/Digest

Daniel Pocock daniel at readytechnology.co.uk
Mon Mar 13 17:56:30 CST 2006


I've just been poking around the RADIUS code in SER and looking at using 
it with my B2BUA.  SER uses the Sterman method (IETF 
draft-sterman-aaa-sip-00.txt).

Basically, rather than requesting a secret from the RADIUS server, it 
forwards the digest data to the RADIUS server and the RADIUS server 
compares the calculated digest to the client's digest and responds `yes' 
or `no'. 

This isn't quite compatible with the `requestCredential()' virtual 
method in ServerAuthManager.  Maybe we need another virtual method, such 
as `requestAuthForDigest()', or perhaps requestCredential()'s prototype 
can be modified to accept the raw digest data, in addition to the 
extracted username, etc.  The derived class which implements the method 
would presumably post some kind of UserAuthInfo message with an 
attribute indicating that the digest data was good or bad, instead of 
providing a value for the secret.

The new auth algorithm (upon receipt of UserAuthInfo) would be something 
like this:

UserAuthInfo uai = ...
InfoMode im = uai.getInfoMode();
switch(im) {
case RetrievedSecret:   // derived class has fetched the un-hashed secret
  md5 = do_md5(uai.getSecret());
  // fall through to CompareMD5
case RetrievedHash:    // derived class has fetched the user's secret, 
within a hash
  if(dr == RetrievedHash)
     md5 = uai.getSecret();
  if(md5 == original hash)
    // good
  else
     // bad
   break;
case DigestOk:    // derived class has verified the hash from the client
  // good
  break;
case DigestFailed:   // derived class has rejected the hash from the client
  // bad
  break;
case Error:    // derived class encountered an error (e.g. fail to 
contact RADIUS server)
  break;
default:
  break;
}

Does anyone have any further ideas about this?  Otherwise, I will start 
coding this shortly.



More information about the resiprocate-devel mailing list