Gaps to Map

Right before the IETF in Anaheim I’m off to the ISOC Identity event: Mapping the Gaps in DC. This post is a set of possible discussion points for that event. The event will focus on the gaps between the technological and policy/legal view of the identity metasystem.

Standardized Federation Policy and Practice Statements

Building identity federation involves establishing policy documents and practice statements analogous to the CP and CPS of a PKI. In the world of public key infrastructure there are templates to start from – RFC 3647, ETSI TS 102 042, ANSI X9.79, etc. In the world of federations there is no such help. We need those and we need them to be simpler (if possible) than their PKI cousins.

Simplified/Standardized Federation Contracts

Joining a federation (as an SP or IdP) often involves signing some form of contract. For an SP joining multiple federations the fact that no two contracts look alike soon becomes a problem. There are at least two ways around this:

  • Make the contracts easily comparable – i.e standardize!
  • Do away with the contracts all together.

In may situations having a contract will probably be inevitable but in certain cases it might be perfectly reasonable not to have a contractual relationship between (say) an SP and a federation. I’ve blogged about this and there has been some work in this area.

Separate technical trust from federation metadata

Technical trust for identity federation is often (at least in many R&E federations) represented as signatures on SAML metadata documents which contain keys for the member entities. This works (often better than using a traditional PKI) but it does tie technical trust management in with a particular identity technology. We need a way to represent technical trust which is easier to setup and maintain than PKI and which can be applied to all identity technologies in use today.

Comments Off on Gaps to Map

Filed under Uncategorized

Computer Sweden picks up on Swedish eID problems

Computer Sweden har intervjuat Fredrik Ljunggren på Kirei om vår blog-plost om federerad e-id i Sverige.

Dom har faktiskt uppfattat budskapet riktigt väl!

Comments Off on Computer Sweden picks up on Swedish eID problems

Filed under E-delegationen

Kammarkollegium och organisationslegitimationerna

Det är svårt att tänka om.

Nyligen kom e-delegationen ut med sitt betänkande kring bla eID där man tydligt säger att man vill satsa på identitetsfederationer och på öppna lösningar för identifiering i Sverige. Ingen blir nog förvånad om Skatteverket kommer att få ansvara för nämnden för e-samordning och om Kammarkollegium kommer att få göra alla upphandlingar som blir resultatet av de standarder och regelverk som nämnden förhoppningsvis kommer att etablera. So far so no surprises…

Det är därför med växande förvåning jag har följt hanteringen av sk organisations-legitimationer hos Kammarkollegium under sommaren och hösten. Där har man suttit och räknat ut att X509-certifikat med både personnummer och organisationsnummer är det bästa sättet att representera att NN jobbar på firma X.

Alla som har någon insikt i hur identitetssystem byggs idag inser att det finns en del problem med ett sådant angreppsätt och att en modernare lösning kanske hade varit att jobba med teknologi som kan hantera attribut i någon form, tex OpenID, SAML, InfoCard eller varför inte attributcertifikat!

Trots att det alltså finns invändningar i sak och ett uppenbart behov att samordna med nära förestående arbete inom ramen för nämnden för e-samordning så kör Kammarkollegium på som om inget har hänt…

Idag var det informationsmöte på Sheraton. Det kändes lite som att sitta på en diskussion i 15 punkter kring färg, form, placering, material och distribution av havrepåsar för framtidens hästlösa vagnar. Vid varje punkt påpekade någon i publiken att det kanske inte behövs en häst eller att om det behövs en slags häst så kanske det är en järnhäst som inte äter havre. Efter varje diskussion så gick presentationen av nästa punkt vidare (“.. och såhär tror vi att havrepåsen ska spikas fast…”).

Någon påpekade helt korrekt (om också tämligen irrelevant) att det kan finnas användning av certifikat med organisationsnummer instoppade även om man använder federationsteknologi.

Jo man kan ju vilja leda en häst bredvid bilen och då vill man kanske ha en havrepåse…

Som vanligt i dessa sammanhang så drog någon med jämna mellanrum fram “signaturs-kortet”: “Det går ju inte att göra offline signaturer med en sån däringa federations-pryl…”. Helt rätt. Man kan inte köra sin hästlösa vagn ut i skogen om man skulle behöva avverka ett träd på vägen mellan Konsum och hemmet men genom att optimera för det vanligaste fallet (identifiering) så blir hela systemet så mycket billigare att man har råd att hyra sig en skogsmaskin när man behöver den.

Vi behöver mer konkurrens inom eID i Sverige, inte mindre! Kammarkollegium har ett ansvar att göra upphandlingar som inte i onödan begränsar spelplanen till de få företag (jag kan räkna dom på ena handens fingrar även om jag har tappat ett par fingrar) som utfärdar den typ av ḱort som Kammarkollegium uppenbarligen har i åtanke. Jag menar att Kammarkollegium (om man alls ska ge sig in i detta) bör bredda upphandlingen till att inkludera all teknologi som rimligen kan anses ha samma nivå av tekniska skydd som ett klassiskt PKI-kort, tex olika former av OTP-tokens som av goda skäl blivit allt mer populära på senare tid.

I och med etableringen av federations-lösningar så spelar det ingen roll vad som används för inloggningen så länge det finns ett assuransnivå-begrepp (LoA) som både identifierande part och förlitande part kan enas om. Sådana assuransbegrepp finns det flera färdiga man kan använda – tex Kantara Identity Assurance Framework som av allt att döma är bra nog för att bli godkänt för användning inom USAs statsförvaltning.

Missförstå mig rätt nu – jag gillar 2-faktors-inloggning! Jag menar bara att efter 10+ år med PKI-kort som flaxar med armarna och aldrig lyfter så är det hög tid att vi släpper in några nya spelare i laget och ser om dom lyckas bättre. Federationsteknologi är bla ett sätt att göra spelplanen lite öppnare och lite jämnare.

Comments Off on Kammarkollegium och organisationslegitimationerna

Filed under E-delegationen

Swedish national SAML federation?

The long-awaited (at least if you’re Swedish and interested in public sector IT which does rather limit the audience a bit) e-delegationen report was released today. The section on national identity solutions says “SAML” and “federations” over and over.

On the whole the report promises a significant improvement over todays proprietary solutions. There is still lots of work left to do in order to realize these ideas. Those of us who have worked in identity space for a while know that there are plenty of opportunities to shoot oneself in the foot even if you have the right shoes on.

For reasons that escape me Sweden has a bit of a track record trying to “roll your own” in areas where there are plenty of existing standards and market direction, but this time I do believe e-delegationen is betting on the right horse. Good work!

Comments Off on Swedish national SAML federation?

Filed under Identity

Stork & InfoCard (and maybe U-Prove)

Paul Madsen twittered this networworld article about what i guess must be one of the first public appearances of the EU Stork project.

Kim Cameron and MSFT seem to be shopping InfoCard and Geneva all over the place these days so their comments about Stork shouldn’t be surprising to anyone. The article claims that InfoCard has seen solid industry uptake which may be true but according to the recent Concordia Survey on Federated Identity InfoCard has a very small deployed base.

Nevertheless I think it reasonable to think that InfoCard will get deployed more, even in the R&E community where federated identity is already a Big Thing (TM).

InfoCard shares important infrastructure with SAML making it fairly easy to deploy alongside SAML (even though the semantics and user experience of SAML WebSSO and InfoCard differ quite a bit), namely SAML metadata which, when deployed “the right way” becomes the primary trust fabric of an identity federation. Microsofts Geneva was apparently designed around the same principles of how SAML metadata should be used as is fast becoming best practice among R&E identity federations.

So we learn that STORK will consider SAML 2.0 and holder-of-key as the primary way to interface national eID solutions in the European countries. I really hope they understand that the devil is in the details and design metadata management and trust fabric management in a sensible way.

One can only wonder what lies behind Microsoft pushing Geneva all over the place. Typically Microsoft aren’t happy just following where others lead. Perhaps the idea is to include the U-Prove technology they bought with Credentia last year in Geneva and embrace and extend the identity federation framework…

Then again once you can see the threat it is suddenly less of a threat. The famous embrace and extend tactic is precisely that: famous. People who are interested in open standards and open implementations should recognize where the ball is being played and start to think about how to implement U-prove.

1 Comment

Filed under Identity

Metadata license becomes metadata terms-of-use

Andrew Cormack of ja.net talked at the REFEDS meeting today about recent work they have done on standardizing interfederation agreements. One interesting announcement was that they’ve picked up my old idea of associating a license with federation metadata. They ran this by a set of lawyers who basically said: “don’t call it a license, call it terms-of-use and you’re fine”.

This has the potential of simplifying federation operations (including federation peering) significantly since service-providers don’t have to be tied to federations by legal agreements. For multi-federation service-providers like Microsoft Dreamspark or Elsevier this is good news since they may in time get away from having to sign agreements with every federation on the planet.

While this may seem like a bad idea for federations whose business was driven by being able to charge SPs for inclusion in metadata in the long run everyone benefits from the identity business growing with the removal of a major obstacle.

2 Comments

Filed under Identity

Certificate enrollment in confusa using OAuth

I’ll admit that X.509 certs aren’t the most hot topic in the world these days but they do rear their ugly little heads now and again. Most recently I’ve been involved with the people working on deploying the new Terena Certificate Service (TCS). The TCS is a follow-up of SCS – a pan-European flat-rate certificate service negotiated by Terena. The second round of procurement got us a sweet deal with Comodo which includes unlimited flat-rate user, code and server certificates (!)

Reading Andreas excellent post on adding support for OAuth in simpleSAMLphp and talking to Thomas Zangerl at NDGF who is helping Henrik Austad of UNINETT work on the confusa CA server we’ll use for the emai/GRID certificate part of TCS, we realized that OAuth could also be used in conjunction with Java WebStart to provide secure key generation and enrollment for confusa. Here is a rough outline:

The CA web interface is a federated application – in our case using the Browser Web SSO SAML 2 profile implemented in simpleSAMLphp. Today confusa allows the user to login via one of the trusted IdPs and then upload a PKCS#10 certification request in a form. This CSR is combined with attributes provided by the IdP to provision the certificate.

This works but doesn’t provide a very nice user experience. Instead we could launch a Java WebStart application or applet which does key generation on the client and submits the CSR to the CA server. This approach has been implemented by others. The problem is how to authenticate the CSR and tie it to the authenticated user attributes. A session identifier could be used but would typically need lots of tweaking to be sufficiently time-limited and secure.

If we try to apply OAuth to this situation and view the established session as a protected resource that the user grants access to for the purpose of binding a public key to it we get the following translation of OAuth concepts:

  • Consumer: The Java WebStart application
  • Service Provider: The CA application (confusa in our case)
  • User: The user requesting a certificate.
  • Protected Resource: The established session at the web applicaiton containing the user attributes.

Since the User has already logged in an authorized the request and is provisioned with a consumer key and a pre-authorized request token as part of the launch JNLP file. At this point the JWS application can obtain an access token and use it to associate the CSR with the established session using a PUT request.

I’ll be the first to admit that this is a corner-case – the request-token is authorized before any OAuth protocol flows are initiated but nevertheless it shows that OAuth is a very nice idea adaptable to many situations.

We will look deeper into the security implications of this and this process is expected to get lots of scrutiny by the GridPMA when we submit the TCS Grid CPS to the EuroGRID PMA for review so the jury is still out on weather this gets deployed or not! Stay tuned.

Comments Off on Certificate enrollment in confusa using OAuth

Filed under Identity

LDAP schemas for IM and SIP

Over the years at Stockholm university I worked on lots of new technology. Some of that technology deserves a wider audience and in some cases I’ve been asked to provided detailed descriptions of some of the solutions we built. I’ll try to summarize some of the most (imho) useful stuff here for future reference.

I’ll start with something that Olle E Johansson over at edvina recently asked me about: LDAP Schemas for IM and SIP.

The production environment at Stockholm university was designed to be tightly integrated with focus on single points of administration for things like authentication, identity, etc. Kerberos and LDAP is (still) the religion.

Jabber

We started using jabber using ejabberd a couple of years ago and decided to use our LDAP-based identities (naturally). However we found that nobody had designed a credible virtual-host aware schema that was useful for IM applications. Here is the schema we came up with. It is pretty basic to say the least:


# jabberuser (at) 1.2.752.43.9.1
attributeType ( 1.2.752.43.9.1.1
NAME 'jabberID'
DESC 'The Jabber ID(s) associated with this object. Used to map a JID to an LDAP account.'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# jabberuser (oc) 1.2.752.43.9.2

objectClass ( 1.2.752.43.9.2.1
NAME 'jabberUser'
DESC 'A jabber user'
AUXILIARY
MUST ( jabberID ) )

Since we used Kerberos to authenticate users this was really all we needed. Since jabberID is multivalued we often attached multiple jabberIDs to a single LDAP. This gave us a way to test new servers and domains wo setting up additional infrastructure. We used this together with the external authentication module of ejabberd (which I contributed to ejabberd specifically for this case, however it is now part of the standard ejabberd distribution).

SIP

The SIP case turned out to be slightly more complex. Since SIP still uses a simple share-secret based authentication mechanism by default we needed to stick passwords somewhere. At that time our Kerberos (Heimdal naturally!) didn’t do remote digest yet so we needed to keep the passwords outside our KDC. We decided to face our shame and stick them in LDAP.

Thus for SIP we needed to represent both information about SIP authentication and SIP message routing. This is analogous to the mail case where you keep the identity used to authentication to the SMTP/IMAP server logically (in the schema sense that is) separate from the attributes used to represent email aliases. This is what we came up with – I hope the comments explain some of the semantics.


# The sipLocalAddress is a (multivalued) attribute used to assocate
# uri:s with an entity to which sip messages can be addressed. This
# attribute can contain any uri scheme used in ENUM including sip:
# and tel:

attributetype ( 1.2.752.43.4.1.1
NAME 'sipLocalAddress'
DESC 'A uri (sip or otherwize) associated with this object'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# This is the unique user identifier and primary key into the location
# database of a sip server using this schema. The syntax of the value
# is an opaque IA5-string. No structure is implied (neither ,
# @ or otherwize) is implied and MUST NOT be assumed.

attributetype ( 1.2.752.43.4.1.2
NAME 'sipAuthenticationUser'
DESC 'The user identifier used for authentication.'
SINGLE-VALUE
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# Cleartext password used in MD5-based authentication.

attributetype ( 1.2.752.43.4.1.3
NAME 'sipPassword'
DESC 'The cleartext SIP authentication password.'
SINGLE-VALUE
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# Incoming messages to a sipRoutingObject is sent to this address. The
# implied semantic is that the sip-server regard the presence of this
# attribute as a REDIRECT which must be proxied to the client UA.

attributetype (1.2.752.43.4.1.4
NAME 'sipRoutingAddress'
SINGLE-VALUE
DESC 'A uri (sip or otherwize) used to route sip messages'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# A sipUser SHOULD be associated with a person, account or similar
# STRUCTURAL object class.

objectclass ( 1.2.752.43.4.2.1
NAME 'sipUser'
AUXILIARY
MUST ( sipAuthenticationUser )
MAY ( sipPassword ) )

# A sipRoutingObject MAY be associated with either a sipUser object or
# with a groupOfNames, groupOfUniqueNames or organizationalRole in which
# case forking of the call to those entries present in referring attributes
# who are also sipUser object is implied.

objectclass ( 1.2.752.43.4.2.2
NAME 'sipRoutingObject'
AUXILIARY
MUST ( sipLocalAddress )
MAY ( sipRoutingAddress $ telePhoneNumber ) )

This work was done together with Fredrik Thulin (who still works for Stockholm university), the lead developer of the YXA SIP-server where this stuff got implemented and deployed as part of the Stockholm university SIP infrastructure. The operational experience of this approach to SIP identity management has been good overall.

What would I have done different today?

Definitely I’d have used remote digest in Heimdal to keep all authentication secure inside my KDC. Passwords in LDAP are an abomination (imo). I would have tried to combine the two schemas into a single Presence/IM/VOIP schema since most of the semantics is either harmless or equivalent in all cases.

Comments Off on LDAP schemas for IM and SIP

Filed under Cleaning the desk

Moving my blog

Since I’ll be changing jobs soon (going to work for NORDUnet and SUNET) I thought it wise to move my blog from blogs.su.se/leifj where I have been writing sporadically about various aspects of Internet technology. I plan to use this site (blogs.mnt.se) as a place to write about things that aren’t directly related to my activities at NORDUnet.

Comments Off on Moving my blog

Filed under Uncategorized