퍼센트(%) 인코딩

기존 퍼센트 인코딩 기술은 일관된 문자열 기반 서명 구성은 보장하지 않는다. 다음의 퍼센트 인코딩 방법은 [RFC3986] 및 [W3C.REC-html40-19980424] 에 이미 정의된 퍼센트 인코딩 기술을 대체하기 위해 정의되는 것은 아니다. 이 방법은 문자열 기반 서명 및 authorization 헤더 필드의 인코딩에만 사용되는 것이다. ( Section 3.5.1 )

이 사양은 다음과 같이 퍼센트 인코딩 방법을 정의한다.
텍스트 값이 [RFC3629]으로 정의된 UTF-8 바이트로 인코딩되어 있지 않으면 그렇게 인코딩 된다. 인간이 이용하지 않는 이진 값들은 생략한다.
값은 다음 [RFC3986] 으로 정의된 퍼센트 인코딩 방법 따라 이스케이프 한다.
다른 문자는 모두 인코딩 해야한다 (MUST).
인코딩된 문자를 나타내는 2자리의 16진수 문자는 대문자여야만 한다.
[RFC3986] 섹션 2.3에서 정의된 예약되지 않은 문자 (알파벳 숫자, "-", "", "_", "~")는 인코딩하면 안된다 (MUST NOT).

이 기법 "application/x-www-form-urlencoded" 에서 사용하는 인코딩 방식과는 다르다. (예를 들어 이 기술은 공백 문자로 "+"가 사용되는 것이 아니라 "%20" 으로 인코딩 되는)이 방법은 Web 개발 프레임워크가 제공하는 퍼센트 인코딩에서는 다를 수 있다 (MAY). (다른 문자를 인코딩하고, 소문자 16 진수 문자를 사용하는 등)

보안 고려사항

[RFC2617] 에 명시된 바와 같이 일반적으로 최대의 위험 요인은 프로토콜의 본질이 아니라 그 프로토콜을 사용하기 위한 정책 및 절차에 있는 경우가 많다. 구현자는, 이 프로토콜이 어느 정도의 보안 요건을 충족하는지 여부를 스스로 평가하기를 권장한다.

RSA-SHA1 서명방식

RSA-SHA1 서명을 이용한 공인 요청은 토큰 공유 키 및 클라이언트 공유 키는 사용되지 않는다. 따라서 이것은 전적으로 클라이언트가 서명 생성에 사용되는 비밀 키 기밀성에 의존한다.

요청 기밀성

이 프로토콜은 요청의 유효성 검증 메커니즘을 제공하지만, 요청의 기밀성은 보장되지 않는다. 기타 예방 조치가 되어 있지 않으면, 도청으로 요청 전체 내용을 가로챌 수있다. 서버는 요청에서 전송되어진 데이터의 종류를 고려하고, 기밀 정보가 포함된 리소스를 보호하기 위해 TLS 메커니즘을 사용해야 한다.

서버의 스푸핑

이 프로토콜은 서버의 신뢰성을 검증하는 것이 아니다. 적의를 가진 제 삼자가 이 점을 악용하여 클라이언트의 요청을 가로 채고 조작 또는 잘못된 응답을 반환할 수 있다. 제공자는 서비스 구축 시 이러한 공격을 고려하여 서버 및 요청 응답의 신뢰성이 요구되는 요청은 TLS를 사용해야 한다.

필수 인증 내용의 프록시와 캐시

HTTP Authorization 체계는( Section 3.5.1 ) 옵션이다, [RFC2616] 은 "Authorization" 및 "WWW-Authenticate" 헤더를 바탕으로 필수 인증 내용 확인을 실시한다. 특히 프록시와 캐시 헤더 필드를 사용하지 않는 경우 요청을 적절하게 보호하는 것은 실패할 수 있습니다.

예를 들면, 개인의 인증된 내용은 공개적으로 접근 가능한 형식으로 저장될 수 있다. HTTP Authorization 헤더 필드를( Section 3.5.1 ) 사용하지 않는 서버가 Cache-Control 헤더와 같은 다른 수단을 사용하여 필수 인증 콘텐츠 보호를 보장해야 한다.

보안 카드 Plaintext 저장소

클라이언트 공유 키와 토큰 공유 키는 기존의 인증 시스템의 암호와 같은 기능을 가진다. RSA-SHA1 이외의 방법으로 사용하는 서명을 계산하려면 서버가 그 키를 일반 텍스트 형식으로 접근할 수 있어야 한다. 최근 운영체제가 사용자 인증 정보를 돌이킬 수 없는 해시로 저장하는 것을 볼때 이것은 대조적이다.

만약 공격자가 이 키에 접근 또는 서버 가진 모든 키 데이터베이스에 대한 접근 권한을 박탈하면 공격자는 리소스 소유자를 대신해 모든 작업을 수행 할 수 있게 된다. 따라서 서버는 권한이 없는 사람에게서 이 키를 엄격하게 보호해야 한다.

클라이언트 보안 카드 기밀성

대부분의 경우, 클라이언트 응용 프로그램은 잠재적으로 실뢰할 수 없는 영역의 관리하에 있다. 예를 들면 클라이언트가 데스크톱 응용 프로그램 소스코드 및 실행 파일의 바이너리가 공개되는 경우 공격자가 분석을 위해 사본을 다운로드하고 클라이언트 보안 카드을 찾아 사용할 수 있다.

이 경우, 서버가 클라이언트의 신원을 확인할 때 클라이언트 보안 카드만 사용하면 안된다. 가능하면 IP 주소와 같은 다른 요소들도 채택해야 한다.

피싱공격

이 사양과 유사한 프로토콜이 널리 실용화되면 리소스 소유자가 암호를 입력하기 위해 웹 사이트로 리다이렉션되는 것에 익숙해질 수 있다. 이런 웹 사이트들의 신뢰성을 주의 깊게 확인하지않고 리소스 소유자가 인증 정보를 입력해 버리면 리소스 소유자의 암호는 공격자에 의해서 도난당할 가
능성이 있다.

서버는 리소스 소유자에게 피싱 공격의 위험에 대한 정보를 제공하며 손 쉽게 웹 사이트의 신뢰성을 검증할 수 있는 수단을 제공해야 한다. 클라이언트 개발자는 사용자 에이전트와 상호 작용 (다른 윈도우나 소스 등)의 보안 문제와 최종 사용자가 서버 웹사이트의 신뢰성을 검증하는 기능을 고려해야 한다.

접근 요청 범위

이 프로토콜은 자체가 클라이언트에 부여할 권한의 범위를 결정하는 방법을 제공한다. 그러나 대부분의 응용 프로그램은 사용 권한 분할을 필요로 하고있다. 예를 들어, 서버가 특정 보호되는 리소스에 대한 접근를 허용하면, 다른 사람은 허용하지 않으며, 제한된 접근 (읽기 전용 등) 만 허용하는 경우가 있다.

이프로토콜을 구현할 때 서버는 리소스 소유자가 클라이언트에 부여하고자 하는 접근 형식을 고려하고 그것을 실현하는 매커니즘을 제공해야 한다. 서버는 리소스 소유자가 접근하려는 자신의 권한 뿐만 아니라 어떤 위험을 가지고 있는지에 대한 이해하고 있다는 것을 신중하게 검토하여야 한다.

인증서의 엔트로피

전송계층 보안 프로토콜을 사용하지 않는 경우, 도청에 의해 인증된 요청 및 서명에 완전히 접근할 수 있게 되고 따라서 보안 카드 사용을 복구하는 오프라인 무차별 대입 공격을 탑재할 수 있게 된다. 서버는 이러한 공격에 대비해 최소한의 유효기간을 정해 공유 키가 정체되지 않도록 충분한 길이로 임의의 공유키를 할당해야 한다..

예를 들면, 2주간 공유 키를 사용하면 서버는 2 주 내에 무차별 대입 공격을 통해 공유 키를 획득하는 것이 불가능함을 보장해야 한다. 물론 서버는 충분한 길이의 키를 사용하여 해결하여야 한다.

Pseudo-Random Number Generator(의사 난수 생성기)를 사용하는 것은 충분히 높은 품질의 키를 생성하기 위해 중요합니다. 많은 PRNG 구현은 임의의 수열을 생성하는 경우에도 암호 해독과 무차별 입력을 쉽게 할 수 있는 패턴 및 취약점을 가졌다. 구현자는 이러한 문제가 없는 안전한 PRNG를 사용하여야 한다.

DoS 공격 / 자원 고갈 공격

이 사양에는 서버 리소스를 소모시키는 공격을 가능하게 하는 부분이 많다. 예를 들면, 이 프로토콜은 서버에서 nonce 값이 사용되었는지 검사하도록 요구하고 있다. 공격자가 순식간에 수 많은 nonce 값을 사용할 수 있으면, 그들을 시험하기 위해 서버 리소스를 고갈시켜 버릴 것이다. 또는 서명을 확인하기 위해 서버에 높은 계산 능력을 요구할 수 있다. 공격자는 유효하지 않는 요청을 대량으로 보내는 DoS 공격으로 악용할 수 있다.

자원 고갈 공격은 결코 이 사양만의 특유한 것은 아니지만, 구현자는 이 사양이 고갈 공격 방법에 대해 표면화 하고 있는 것을 고려하여 충분한 설계를 해야한다. 예를 들어 엔트로피의 부족은 새로운 엔트로피를 기다리는 동안 DoS나 약한 (추측하기 쉬운) 키를 초래하게 된다. 구현에 있어서 서버는 이러한 응용 프로그램에서 심각한 위험을 초래할 수 있다는 것을 고려하여 충분한 설계를 해야 한다.

SHA - 1 공격

HMAC-SHA1 서명 방식, RSA-SHA1 서명 방식으로 사용되는 SHA-1은 충돌 공격에 많은 취약점이 있는 것으로 알려져 있다. 이 취약점은 HMAC-SHA1 서명 방식의 이용에는 영향 없어 보인다, RSA-SHA1 서명 방식에는 영향이 있다. NIST는 디지털 서명으로 SHA-1의 사용을 2010년까지 단계적으로 폐지할 예정이라고 발표했었다.

사실, 이 취약점을 이용하는 것은 어렵고 이용자에게 심각한 위험을 초래하는 것은 아니다. 그러나 이것들은 보다 효율적인 공격이 가능하게 될지도 모르며 서버에서는 SHA-1이 응용 프로그램을 위해 충분한 보안 수준을 제공할 것인가를 생각할 때 이 점을 염두해 두어야 한다.

문자열 기반 서명 제약

문자열 기반 서명은 이 사양에 정의된 서명 방식을 지원하기 위해 설계되었다. 앞으로 서명 방식을 추가하는 설계자는 문자열 기반 서명의 호환성 및 보안 요구 사항을 평가해야 한다. 많은 요청 엔티티 본문 및 엔티티 헤더, 매개 변수의 표시 순서 등의 정보는 문자열 기반 서명에 포함되지 않는다. 이 처럼 문자열 기반 서명은 HTTP 요청 전체를 커버하는 것이 없기 때문에 서버는 문자열 기반 서명에 포함되지 않는 요소를 보호하는 메커니즘을 추가 도입해야 한다.

크로스사이트 요청 위조 (CSRF)

Cross-Site Request Forgery(CSRF)는 HTTP 요청이 믿을 수 있는 웹 사이트 또는 인증된 사용자가 전송하는 Web 기반 공격이다. CSRF 공격은 인증 승인에서 공격자가 보호된 리소스에 대한 승인을 사용자 동의 없이 얻기 위해 허용 할 수 있다. 서버는 모든 프로토콜 인증 엔드 포인트에서 CSRF 대책 사례를 고려해야 한다.(SHOULD).

CSRF 공격은 클라이언트의 OAuth 콜백 URI에서도 가능하다. 클라이언트는 클라이언트 사이트의 리소스 소유자가 서버와 OAuth 통신을 완료하는 의도가 있는 것을 확인하여 OAuth 콜백 URI로 CSRF 공격을 예방해야 한다. 이러한 CSRF 공격 방어 수단은 이 사양 밖의 범위이다.

유저 인터페이스 Redress

서버는 인증 과정에서 UR Redress 공격 ( "클랙재킹"으로 잘 알려진 )을 방지한다. 이 사양이 작성될 당시 완벽한 UI redress를 막을 방법은 존재하지 않았다. 서버는 다음과 같은 기술을 통해 UI redress 위험을 줄일 수 있다.

Javascript로 프레임 해제.
Javascript로 프레임 해제 및 승인 페이지에서 브라우저의 Javascript를 활성화하는 것을 요구.
브라우저별 프레임 방지 기술.
OAuth token 발급 전에 비밀번호 입력 요구.

반복적 인증의 자동처리

서버가 이미 리소스 소유자의 승인을 얻은 클라이언트 인증 요청( Section 2.2 )을 자동으로 처리하는 것을 원할지도 모른다. 리소스 소유자가 접근 권한 부여를 위해 서버로 리다이렉션 되는 경우 서버는 리소스 소유자가 이미 클라이언트에서 접근 권한을 부여받고 있다는 것을 감지했다. 이 경우 서버는 리소스 소유자에게 승인을 요구하는 대신 리소스 소유자를 자동으로 클라이언트에게 리다이렉션 한다.

클라이언트 보안 카드가 노출되는 경우 자동 처리는 추가적인 보안위험을 만들어 낸다. 공격자는 훔친 클라이언트 보안 카드를 사용하여 리소스 소유자 서버에 리다이렉션하고 인증 요청을 할 수 있다. 그러면 서버는 리소스 소유자의 승인 절차없이 리소스 소유자에게 접근 권한을 부여하게 된다. 물론 공격에 대한 주의를 요구한다. 자동 승인이 구현되지 않으면 공격자가 리소스 소유자에게 접근 권한을 부여하기 위해서 사회 공학을 사용해야 한다.

서버는 자동 처리에 연관되어진 위험을 줄이기 위해 자동 승인 프로세스를 통해 실행되는 토큰 보안 카드 범위를 제한할 수 있다. 리소스 소유자의 동의를 얻어 발행된 토큰 보안 카드에 영향을 줄 필요는 없다. 클라이언트는 클라이언트 보안 카드를 보호하기 위한 자동화된 프로세스에 연관되는 위험을 줄일 수 있다.

IANA 고찰

이 메모는 IANA에 대한 요청을 포함하지 않는다.

Acknowledgments

이 사양은 여러 기업에 의해 개별적으로 구현된 기존의 고유 프로토콜 및 우수 사례를 바탕으로 만들어진 커뮤니티 사양 OAuth Core 1.0 Revision A 이 직접적인 기반이 되었다.

커뮤니티 사양은 Eran Hammer 에 의해 편집되고 Lahav, Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M. Conlan, Blaine Cook, Leah Culver, Breno de Medeiros, Brian Eaton, Kellan Elliott - McCrea, Larry Halff, Eran Hammer - Lahav, Ben Laurie, Chris Messina, John Panzer, Sam Quigley, David Recordon, Eran Sandler, Jonathan Sergent, Todd Sieling, Brian Slesinsky, Andy Smith 에 의해 쓰여졌다.

편집자는 이 에디션을 공개하기 위해 많은 도움을 준 분들에게 감사함을 전한다.
Lisa Dusseault, Justin Hart, Avshalom Houri, Chris Messina, Mark Nottingham, Tim Polk, Peter Saint - Andre, Joseph Smarr, Paul Walker.

Appendix A. 커뮤니티 버전의 차이
본 사양은 원래 커뮤니티 사양 [OAuth Core 1.0 Revision A] 이 공개되고 나서 발견된 다음과 같은 실수나 누락 부분을 해결하기 위해 변경 사항을 포함한다.

plain text를 보낼 때 TLS / SSL 사용을 SHOULD 에서 MUST 로 변경. 이렇게 하면 임시 보안 카드( Section 2.1 ) 요청 및 토큰 보안 카드( Section 2.3 ) 검색 뿐만 아니라, "PLAINTEXT" 서명 방식의 이용에 영향을 미친다.
토큰 / 타임 스탬프 / 클라이언트 조합이 유일하게 되도록 nonce의 표시를 통제.
타임 스탬프가 이전의 요청에 이용되는 것보다 크거나 같을 필요가 있다는 사실을 삭제.
"PLAINTEXT" 서명 방식을 사용할 때 nonce 및 타임 스탬프 파마리터를 옵션으로 변경.
문자열 기반 서명의 범위는 사용되는 HTTP 메소드가 POST 이 외의 경우 "application / x-www-form-urlencode" 엔티티 본문 파라미터를 HTTP 메소드가 GET 이 아닌 경우는 URI 쿼리 파라미터 확장.
이중 인코딩의 오류를 방지하기 위해 각 서명 방식에 대한 해설은 "oauth_signature" 파라미터에 서명 값을 삽입하기 전 인코딩한 것을 덧붙임.
"oauth_token" 매개 변수가 비어있는 경우 생략을 허용.
빈 "oauth_token" 매개 변수를 임시 보안 카드 요청에 전송하는 것을 허용.
"oauth_" 매개 변수 추가 정의를 제한하는 항목은 삭제.

Appendix B. Document History
To be removed by the RFC editor before publication as an RFC.
-10
o Added missing 'oauth_token' in exmaple.
o Changed realm values from URI to string to make them more generic (since the protocol does not define any internal structure for them).
-09
o Added 'with a 200 status code (OK)' in two places.
o Missing comma in example.
o Corrected typos.
o Changed the use of TLS/SSL when sending or receiving plain text credentials to a MUST.

o Clarified text about change control moving from the community to the IETF.
-08
o Adjusted timestamp language to allow use of time servers for clock sync.
o Revised security language for SHA-1 weakness and applicability.
o Added link to the community specification.
o Minor editorial changes.
-07
o Corrected typos.
o Changed examples to use HTTPS in authorization step.
o Clarified the use of 'oauth_' tokens in the three static endpoint URIs.
o Edited abstract and introduction.
-06
o Moved parameter section into client instructions.
o Added more examples in the delegation section, including more complete HTTP responses.
o Removed language about restricting the use of the 'oauth_' prefix.
o Changed the nonce and timestamp parameters to optional when using PLAINTEXT.
o Allowed empty token in temporary credentials requests.
-05
o Replaced the word 'lexicographical' with 'ascending' in sorting instructions.
o Added note that the 'a3' parameter appears twice in the example.
o Made the note about the encoding scheme being different from most common implementations more explicit.

o Moved and cleaned up the example from appendix to introduction.
Removed crypto details from the example.
-04
o Corrected typo and other minor editorial changes.
o Added warning about token sizes.
o Clarified that all 'oauth_' parameters must be transmitted using the same method.
o Added explicit requirement to exclude parameters not transmitted in a request in the signature base string (for example oauth_version when omitted).
o Explicitly set OAuth to use HTTP 1.1.
o Rearranged the signature base string section to provide a better narrative of how the HTTP request is normalized. Added the protocol parameters to the examples to better demonstrate how they are incorporated in practice.
o Flipped the document order between authentication and authorization.
o Removed the requirement for timestamps to be equal or greater than previous timestamps.
-03
o Updated draft with changes from OAuth Core 1.0 Revision A to fix a session fixation exploit.
o Small editorial corrections.
o Removed confusing language from 'Denial of Service / Resource Exhaustion Attacks'.
o Added new 'Differences from the Community Edition' appendix.
o Updated acknowledgements section.
-02
o Corrected mistake in parameter sorting order (c%40 comes before c2).

o Added requirement to normalize empty paths as '/'.
-01
o Complete rewrite of the entire specification from scratch. Separated the spec structure into two parts and flipped their order.
o Corrected errors in instructions to encode the signature base string by some methods. The signature value is encoded using the transport rules, not the spec method for encoding.
o Replaced the entire terminology.
-00
o Initial draft based on the OAuth Core 1.0 community specification with the following changes.
o Various changes required to accommodate the strict format requirements of the IETF, such as moving sections around (Security, Contributors, Introduction, etc.), cleaning references, adding IETF specific text, etc.
o Moved the Parameter Encoding sub-section from section 5 (Parameters) to section 9.1 (Signature Base String) to make it clear it only applies to the signature base string.
o Nonce language adjusted to indicate it is unique per token/timestamp/consumer combination.
o Added security language regarding lack of token secrets in RSA-SHA1.
o Fixed the bug in the Normalize Request Parameters section. Removed the "GET" limitation from the third bullet (query parameters).
o Removed restriction of only signing application/x-www-form-urlencoded in "POST" requests, allowing the entity-body to be used with all HTTP request methods.

References

Normative References

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[W3C.REC-html40-19980424] Hors, A., Raggett, D., and I. Jacobs, "HTML 4.0 Specification", World Wide Web Consortium Recommendation REC-html40-19980424, April 1998, <http://www.w3.org/TR/1998/REC-html40-19980424>.

Informative References

[NIST SHA-1 Comments]
Burr, W., "NIST Comments on Cryptanalytic Attacks on SHA-1".
[OAuth Core 1.0 Revision A]

OAuth, OAuth Community., "OAuth Core 1.0 Revision A".

Author's Address#
Eran Hammer-Lahav (editor)
Email: eran@hueniverse.com
URI: http://hueniverse.com

Html markup produced by rfcmarkup 1.86, available from http://tools.ietf.org/tools/rfcmarkup/

일본 번역 자료를 토대로 한글화 작업이 되었습니다. 경우에 따라 매끄럽지 않거나 잘못된 번역이 있을 수 있습니다.