Korean Identity Management(KIM)

title; Trusting OpenID
link; http://www.windley.com/archives/2006/12/trusting_openid.shtml

요즘 한창 OpenID의 보안에 대해 고민하고 있습니다. 작년 중순에 팀 세미나를 했는데 OpenID는 너무 좁은 수준의 활용밖에 제공하지 못한다는 결론에 다다랐었죠. 처음에는 OpenID를 긍정적으로 바라보고 다른 팀원들을 설득하는 과정에서 5 단계의 식별 체계를 도출했습니다. OpenID는 인터넷 상의 '익명'은 아니지만 약간은 식별해줄 수 있는 정도의 ID로서 가치를 가집니다. 블로그나 위키같이 익명 덧글을 허용하기는 싫지만 사이트에 로그인해야 하는 불편을 없애는 정도의 유용성을 가지기 때문에, 그 정도만으로도 충분히 의미가 있다고 생각했습니다.

1. 익명(Anonymous) : Internet
2. 신뢰하지 않는 도메인의 ID(Identification with unknown domain) : OpenID
3. 신뢰하는 도메인의 ID(Identification with known domain) : SAML
4. 로컬 도메인의 ID(Identification with local domain) : 일반 사이트(Usual Sites)
5. 실명(Real Name) : 실명제

OpenID는 fully decentralized 모델이기 때문에 인터넷 레벨에서 쉽게 적용이 가능하다는 장점이 있습니다. 하지만 그렇기 때문에 '신뢰 모델'이 없습니다. Ad-hoc 환경에서의 신뢰 방법과 유사한 문제지만, 언제나 문제가 상존합니다.

1. IIW2006에서도 나왔듯이, RP(Relying Party)가 사용자를 임의의 IDP로 이끌어서 사용자의 암호를 노출하는 공격이 가능합니다. 하지만 David가 말했듯이 그 문제는 OpenID가 해결해 줄 수 있는 게 아닙니다. 유일한 해결 방안은 사용자 브라우저 레벨에서 피싱 사이트를 판별하는 것입니다. 그래서 OpenID가 OSIS(Open Source Identity Selector)에 적극적으로 참여하는 이유가 생기겠죠.

Someone asked what’s to keep a relying party from purposely misdirecting a user to a site that’s spoofing the user’s IdP and stealing the user’s credentials. David said “Nothing.” 

2. 누구나 OpenID 서버를 만들어서 사용할 수 있다는 것은, 누구나 OpenID를 임의로 만들어서 RP(Relying Party)에 사용할 수 있다는 것을 의미합니다. 블로그나 위키에 스팸 공격을 할 수 있는 것이죠. 이런 공격에 대한 해결책은 OpenID 스펙에 없습니다. 제가 생각하는 가장 좋은 방법은 OpenID에 선택적인 '신뢰 모델'을 만드는 것입니다. 가이드라인 차원이 될 수도 있고, 플러그인 방식의 스펙일 수도 있습니다.

지금은 OpenID가 블로그와 같은 환경에서 사용되는 것도 한계가 있지 않나는 생각이 듭니다. OpenID가 인터넷 레벨에서 사용되기 위해서는 정작 fully decentralized 모델에 너무 의지하지 말아야 합니다. 인터넷 환경에 부족한 '신뢰' 문제를 해결해 주어야 합니다.

다른 분들의 생각은 어떠신지요?

tag; identity management, openid, spam, phishing