8장 RPCSEC_GSS를 사용한 보안 네트워크 프로그래밍

네트워크 작업을 수행하는 응용 프로그램은 해당 트랜잭션의 보안 유지를 보장해야 합니다. RPCSEC_GSS 응용 프로그램 프로그래밍 인터페이스(API)를 사용하면 SEAM과 Kerberos V5 등의 광범위한 보안 메커니즘을 이용할 수 있습니다. 특히, RPCSEC_GSS에는 인증 이상의 보호를 제공하는 무결성 및 프라이버시 서비스가 포함되어 있습니다. RPCSEC_GSS는 SEAM의 일부도, 고유 기능도 아니지만 개발할 응용 프로그램에 Kerberos V5의 보안 기능을 활용할 수 있는 최상의 방법입니다. 실제로 RPCSEC_GSS는 모든 메커니즘에서 사용할 수 있기 때문에, SEAM/Kerberos V5를 사용하지 않지만 그에 상당하는 프라이버시와 무결성을 사용하려는 개발자에게는 이상적인 솔루션입니다.

이 장의 내용은 RPC 프로그래밍에 익숙한 사용자를 기준으로 설명되어 있습니다. RCP에 대한 내용은 ONC+ Developer's Guide를 참고하십시오. 또한 이 장에서는 전반적인 개요만 다루었으며 RPCSEC_GSS의 기능이나 데이터 구조 등과 같은 자세한 내용은 rpcsec_gss(3N) 매뉴얼 페이지를 참고하십시오. 기타 이 장에서 설명한 모든 함수에 대해서는 해당 매뉴얼 페이지를 참고하십시오.

다음은 이 장에서 다룰 내용입니다.

• "보안 플레이버"

• "RPCSEC_GSS 루틴"

• "콘텍스트 작성"

• "값 변경 및 콘텍스트 폐기"

• "주체 이름"

• "서버에서 증명서 받기"

• "콜백"

• "최대 데이터 크기"

• "기타 함수"

• "관련 파일"

보안 플레이버

이 단원에는 RPCSEC_GSS API의 개발 및 특징에 대한 설명이 나와 있습니다.

RPCSEC_GSS 이전의 보안

RPC에서 처음으로 지원된 보안 플레이버는 AUTH_SYS(AUTH_UNIX라고도 함)였습니다. AUTH_SYS는 사용자와 그룹 ID를 사용하여 메시지 발신자와 수신자를 식별하는 UNIX 스타일의 증명서를 제공했었습니다. AUTH_SYS는 구현하기가 쉽지만 정확한 인증을 제공하지 않았기 때문에 보안을 유지하기 어려웠습니다. 즉, 승인을 요청하는 클라이언트가 실제 그 클라이언트인지 서버에서 확인할 방법이 없었던 것입니다. 따라서 AUTH_SYS를 사용할 때는 비교적 쉽게 네트워크 요청을 도용할 수 있습니다.

AUTH_SYS가 개발된지 얼마 되지 않아 곧 다음 버전의 보안 플레이버인 AUTH_DES가 제공되었습니다. AUTH_DES는 공개키 인증을 기반으로 하며, 클라이언트의 개인키와 서버의 공개키 사이에 공통키를 생성하기 위해 Diffie-Hellman 키 교환을 사용합니다. 생성된 공통키는 DES 세션키를 암호화하기 위해 사용되며, 이 세션키는 서버가 세션을 구축할 때 해독됩니다.

AUTH_DES는 AUTH_SYS에 비해 상당히 향상되었지만 광범위한 사용에 있어서 어느 정도의 제한이 있습니다. 현재 암호화 표준에서 볼 때 많은 사용자가 사용하기에는 키 크기가 작다는 것이 가장 큰 결점입니다.

마지막으로 또 하나의 RPC 보안 플레이버가 소개되었습니다. AUTH_KERB는 Kerberos V4를 기반으로 AUTH_DES나 AUTH_SYS보다 향상된 보안을 제공합니다. 그러나 이것 역시 도용 가능성이 있습니다.

이러한 보안 플레이버에 대한 자세한 내용은 ONC+ DEVELOPER'S GUIDE를 참고하십시오.

무결성 및 프라이버시: GSS-API

보안 성능을 향상시키기 위해 새로운 네트워크 계층인 일반 보안 표준 API 즉, GSS-API가 추가되었습니다. GSS-API 프레임워크에서는 인증 외에 두 가지 보안 서비스를 추가로 제공합니다.

• 무결성. 무결성 서비스의 경우, GSS-API는 기본 메커니즘을 사용하여 프로그램 간에 교환된 메시지를 인증합니다. 암호 검사합계는 다음을 설정합니다.

  • 수신자에 대한 데이터 작성자의 ID

  • 작성자에 대한 수신자의 ID(상호 인증이 요청될 경우)

  • 전송된 데이터 자체의 인증

• 프라이버시. 프라이버시 서비스에는 무결성 서비스가 포함되어 있습니다. 또한 전송된 데이터는 도용을 방지하기 위해 암호화됩니다.

  미국 수출 제한에 따라, SEAM을 사용하더라도 프라이버시 서비스를 사용할 수 없는 경우가 있습니다.

현재 GSS-API는 응용 프로그램 레벨에서 사용할 수 없습니다. 그러나 일부 GSS-API 기능은 RPCSEC_GSS 기능을 통해 사용할 수 있으며 이 기능들은 "불투명(opaque)" 방식으로 조작할 수 있습니다. 프로그래머들은 이 기능들의 값에는 직접 관여할 필요가 없습니다.

RPCSEC_GSS API

ONC RPC 응용 프로그램에서는 RPCSEC_GSS 보안 플레이버를 통해 GSS-API의 기능을 이용할 수 있습니다. RPCSEC_GSS는 다음과 같이 GSS-API 계층의 "최상위"에 위치합니다.

그림 8-1 GSS-API와 RPCSEC_GSS 보안 계층

RPCSEC_GSS 프로그래밍 인터페이스를 사용하면 ONC RPC 응용 프로그램에서 다음을 지정할 수 있습니다.

메커니즘

보안 모델로, 각 유형의 보안 메커니즘이 여러 수준의 다양한 데이터 보호를 제공합니다. 이 경우 모든 보안 메커니즘(Kerberos V5, RSA 공개키 등)은 GSS-API에 의해 지원됩니다.

보안 서비스

프라이버시나 무결성 서비스입니다(또는 둘 다 해당 없음). 기본적으로는 무결성 서비스가 제공되며 이 서비스는 특정 메커니즘에 국한되지 않습니다.

QOP

보호 수준으로, 프라이버시나 무결성 서비스를 구현하기 위해 사용되는 암호화 알고리즘의 유형을 지정합니다. 각 보안 메커니즘에는 관련 QOP가 여러 개 포함될 수 있습니다.

응용 프로그램에서는 RPCSEC_GSS가 제공하는 기능을 통해 유효한 QOP와 메커니즘 목록을 얻을 수 있습니다( "기타 함수" 참고). 개발 시 응용 프로그램에 메커니즘과 QOP를 하드코딩하지 않아야 나중에 다른 메커니즘과 QOP를 사용할 때 응용 프로그램을 수정할 수 있습니다.

원래 "보안 플레이버"와 "인증 플레이버"는 같은 의미였습니다. 그러나 RPCSEC_GSS의 도입과 함께 "플레이버"는 약간 다른 의미로 사용되었습니다. 이제 플레이버는 인증과 함께 서비스(무결성 또는 프라이버시)를 포함하지만 현재 이에 해당하는 플레이버는 RPCSEC_GSS뿐입니다.

ONC RPC 응용 프로그램에서는 다른 플레이버와 마찬가지로 RPCSEC_GSS를 사용하여 동배와 보안 콘텍스트를 설정하고, 데이터를 교환하고, 콘텍스트를 폐기합니다. 일단 콘텍스트가 설정되면 응용 프로그램은 전송된 각 데이터 단위에 대해 QOP와 서비스를 변경할 수 있습니다.

RPCSEC_GSS 데이터 유형 및 RPCSEC_GSS에 대한 자세한 내용은 rpcsec_gss(3N) 매뉴얼 페이지를 참고하십시오.

RPCSEC_GSS 루틴

표 8-1는 RPCSEC_GSS 명령을 요약해 놓은 것입니다. 따라서 각 RPCSEC_GSS 함수에 대한 자세한 설명은 제공되지 않고 일반적인 개요만 나와 있습니다. 각 함수에 대한 자세한 내용은 해당 매뉴얼 페이지를 참고하십시오. 또한 RPCSEC_GSS 데이터 구조 목록을 포함한 개요에 대한 내용은 rpcsec_gss(3N) 매뉴얼 페이지를 참고하십시오.

콘텍스트 작성

콘텍스트는 rpc_gss_seccreate() 호출로 작성됩니다. 이 함수는 다음을 인수로 받습니다.

• 클라이언트 핸들(예를 들면 clnt_create()에 의해 반환됨)

• 서버 주체의 이름(예: nfs@acme.com)

• 해당 세션의 메커니즘(예: Kerberos V5)

• 보안 서비스 유형(예: 프라이버시)

• 해당 세션의 QOP

• 대부분의 경우 익스포트되지 않은 상태로 유지할 수 있는 두 개의 GSS-API 매개변수(즉, 프로그래머가 널 값을 제공할 수 있음)

이 함수는 AUTH 인증 핸들을 반환합니다. 예 8-1 은 Kerberos V5 보안 메커니즘과 무결성 서비스를 사용하여 콘텍스트를 작성하기 위해 rpc_gss_seccreate()함수가 어떻게 사용되는지를 보여줍니다.

예 8-1 rpc_gss_seccreate()

CLIENT *clnt;                    /* client handle */
char server_host[] = "foo";
char service_name[] = "nfs@eng.acme.com";
char mech[] = "kerberos_v5";

clnt = clnt_create(server_host, SERVER_PROG, SERV_VERS, "netpath");
clnt->clnt_auth = rpc_gss_seccreate(clnt, service_name, mech,
                          rpc_gss_svc_integrity, NULL, NULL, NULL);

. . .

다음은 예 8-1 에서 주의해야 할 몇 가지 사항입니다.

• 비록 메커니즘이 읽기 쉽도록 명시적으로 선언되었더라도, 일반적으로 프로그램에서 rpc_gss_get_mechanisms() 를 통해 해당 메커니즘 테이블로부터 얻게 됩니다.

• QOP는 NULL로 전달되어 해당 QOP를 이 메커니즘의 기본으로 설정합니다. 또는 유효한 값을 통해 메커니즘과 마찬가지로 rpc_gss_get_mechanisms()를 사용하여 프로그램에서 가져올 수 있습니다. 자세한 내용은 rpc_gss_get_mechanisms(3N) 매뉴얼 페이지를 참고하십시오.

• 보안 서비스 유형인 rpc_gss_svc_integrity는 RPCSEC_GSS 유형 rpc_gss_service_t의 enum입니다. rpc_gss_service_t 는 다음과 같은 형식을 갖습니다.

  ---

  typedef enum {
       rpc_gss_svc_default = 0,
       rpc_gss_svc_none = 1,
       rpc_gss_svc_integrity = 2,
       rpc_gss_svc_privacy = 3
  }  rpc_gss_service_t;

  ---

  기본 보안 서비스는 무결성으로 지정되므로, 프로그래머가 rpc_gss_svc_default 를 지정하여 같은 결과를 얻을 수 있습니다.

자세한 내용은 rpc_gss_seccreate(3N) 매뉴얼 페이지를 참고하십시오.

값 변경 및 콘텍스트 폐기

콘텍스트가 일단 설정되면 응용 프로그램에서는 전송되는 각 데이터 단위에 대한 QOP 및 서비스 값을 변경해야 합니다. (예를 들어, 프로그램에서 로그인 이름이 아닌 암호를 암호화하도록 할 수 있습니다.) rpc_gss_set_defaults() 함수를 사용하여 다음과 같이 할 수 있습니다.

예 8-2 rpc_gss_set_defaults()

rpc_gss_set_defaults(clnt->clnt_auth, rpc_gss_svc_privacy, qop);

. . .

이 경우 보안 서비스는 프라이버시로 설정됩니다("콘텍스트 작성" 참고). qop는 새 QOP 이름을 지정하는 문자열에 대한 포인터입니다.

콘텍스트는 auth_destroy()를 사용하여 일반적인 방법으로 폐기됩니다.

서비스와 QOP 변경에 대한 자세한 내용은 rpc_gss_set_defaults(3N) 매뉴얼 페이지를 참고하십시오.

주체 이름

보안 콘텍스트를 설정하고 유지하려면 두 가지 유형의 주체 이름이 필요합니다.

• 서버 주체 이름 서버의 주체 이름은 service@host 형식이며 항상 널로 끝나는 ASCII 문자열로 지정됩니다(예: nfs@eng.acme.com).

  클라이언트가 보안 콘텍스트를 작성할 때 클라이언트는 이와 같은 형식으로 서버 주체 이름을 지정합니다("콘텍스트 작성" 참고). 마찬가지로 서버를 표시할 주체 이름을 설정해야 할 경우에도 rpc_gss_set_svc_name()함수를 사용하는데 이 함수는 위 형식의 주체 이름을 인수로 받습니다.

• 클라이언트 주체 이름. 서버에서 받는 클라이언트의 주체 이름은 rpc_gss_principal_t 구조의 형식을 가집니다. 이것은 사용 중인 메커니즘에 따라 결정된, 카운트된 불투명(opaque) 바이트입니다. 이 구조에 대한 설명은 rpcsec_gss(3N) 매뉴얼 페이지를 참고하십시오.

서버 주체 이름 설정

서버는 시작할 때 표시할 주체 이름을 받아야 합니다. (한 서버는 여러 주체로 작동할 수 있습니다.) rpc_gss_set_svc_name() 함수는 주체 이름을 설정합니다.

예 8-3 rpc_gss_set_svc_name()

char *principal, *mechanism;
u_int req_time;

principal = "nfs@eng.acme.com";
mechanism = "kerberos_v5";
req_time = 10000;		/* time for which credential should be valid */

rpc_gss_set_svc_name(principal, mechanism, req_time, SERV_PROG, SERV_VERS);

(Kerberos는 req_time 매개변수를 무시합니다. 다른 인증 시스템에서는 이 매개변수를 사용할 수도 있습니다.)

자세한 내용은 rpc_gss_set_svc_name(3N) 매뉴얼 페이지를 참고하십시오.

클라이언트 주체 이름 생성

서버는 클라이언트의 주체 이름과 관련된 작업을 할 수 있어야 합니다. 이러한 작업에는 클라이언트의 주체 이름을 액세스 제어 목록과 비교하거나, 증명서가 있을 경우, 해당 클라이언트에 대한 UNIX 증명서를 검색하는 작업 등이 있습니다. 이러한 주체 이름은 rpc_gss_principal_t 구조 포인터의 형식을 유지합니다. rpc_gss_principal_t에 대한 자세한 내용은 rpcsec_gss(3N) 매뉴얼 페이지를 참고하십시오. 서버가 받은 주체 이름을 알려진 실재 이름과 비교하려면 위와 같은 형식으로 주체 이름을 생성할 수 있어야 합니다.

rpc_gss_get_principal_name() 함수를 호출하면 네트워크에서 각 개인을 고유하게 식별하는 매개변수를 입력으로 받아, rpc_gss_principal_t 구조 포인터로 주체 이름을 생성합니다.

예 8-4 rpc_gss_get_principal_name()

rpc_gss_principal_t *principal;

rpc_gss_get_principal_name(principal, mechanism, name, node, domain);
. . .

rpc_gss_get_principal_name() 함수에 대한 인수는 다음과 같습니다.

• principal: 설정할 rpc_gss_principal_t 구조에 대한 포인터입니다.

• mechanism: 사용 중인 보안 메커니즘입니다. 생성되는 주체 이름은 특정 메커니즘에 국한됩니다.

• name: joeh나 nfs와 같이 개인 또는 서비스 이름이거나 사용자 정의 응용 프로그램 이름일 수 있습니다.

• node: 예를 들어, UNIX 시스템 이름일 수 있습니다.

• domain: 예를 들어, DNS, NIS, NIS+ 등의 도메인 이름이거나 Kerberos 영역일 수 있습니다.

각 보안 메커니즘에 따라 다른 식별 매개변수가 필요합니다. Kerberos V5의 경우, 사용자 이름은 필수, 해당 노드와 도메인 이름(Kerberos 용어로는 호스트 및 영역 이름)은 선택 사항입니다.

자세한 내용은 rpc_gss_get_principal_name(3N) 매뉴얼 페이지를 참고하십시오.

주체 이름 해제

주체 이름은 free() 라이브러리 호출로 해제됩니다.

서버에서 증명서 받기

서버는 클라이언트의 증명서를 가져올 수 있어야 합니다. 예 8-5에 나와 있는 rpc_gss_getcred() 함수를 사용하면 서버에서 UNIX 증명서나 RPCSEC_GSS 증명서(또는 둘 다)를 검색할 수 있습니다. 이 검색은 함수가 성공적으로 실행될 경우 설정되는 두 개의 인수를 통해 수행됩니다. 하나는 rpc_gss_ucred_t 구조에 대한 포인터로서, 증명서가 있을 경우 호출자의 UNIX 증명서를 포함합니다.

typedef struct {
    uid_t   uid;          /* user ID */
    gid_t   gid;          /* group ID */
    short   gidlen;       
    git_t   *gidlist;     /* list of groups */
} rpc_gss_ucred_t;

나머지 인수는 rpc_gss_raw_cred_t 구조에 대한 포인터로서 다음과 같습니다.

typedef struct {
		u_int                  version;               /* RPCSEC_GSS program version */
 	char                   *mechanism;
		char                   *qop;
		rpc_gss_principal_t    client_principal;     /* client principal name */
		char                   *svc_principal;        /* server principal name */
		rpc_gss_service_t			service;               /* privacy, integrity enum */
} rpc_gss_rawcred_t;

예 8-5 는 서버가 호출자에 대한 증명서를 얻는 단일 서버 디스패치 프로시저의 예입니다. 이 프로시저는 호출자의 UNIX 증명서를 읽은 다음 rpc_gss_rcred_t 인수에 있는 메커니즘, QOP, 서비스 유형을 사용하여 사용자 ID를 확인합니다.

예 8-5 증명서 읽어오기

static void server_prog(struct svc_req *rqstp, SVCXPRT *xprt)
{
		rpc_gss_ucred_t *ucred;
		rpc_gss_rawcred_t *rcred;

		if (rqst->rq_proq == NULLPROC) {
			svc_sendreply(xprt, xdr_void, NULL);
			return;
		}
		/*
		 * authenticate all other requests */
		 */

 	switch (rqstp->rq_cred.oa_flavor) {
		case RPCSEC_GSS:
			/*
			 * get credential information
			 */
			rpc_gss_getcred(rqstp, &rcred, &ucred, NULL);
			/*
			* verify that the user is allowed to access
			* using received security parameters by
			* peeking into my config file
			*/
			if (!authenticate_user(ucred->uid, rcred->mechanism,
				rcred->qop, rcred->service)) {
				svcerr_weakauth(xprt);
				return;
			}
			break; 	/* allow the user in */
		default:
			svcerr_weakauth(xprt);
			return;
		} /* end switch */

		switch (rqstp->rq_proq) {
		case SERV_PROC1:
			. . .
		}
		/* usual request processing; send response ... */

		return;
}

자세한 내용은 rpc_gss_getcred(3N) 매뉴얼 페이지를 참고하십시오.

쿠키

예 8-5에서 rpc_gss_getcred() 함수의 마지막 인수(여기서는NULL)는 사용자 정의 쿠키로서 반환값은 콘텍스트가 작성될 때 서버에서 지정했던 값이 됩니다. 이 쿠키는 4바이트 값으로, 해당 응용 프로그램에 적합한 모든 방식으로 사용될 수 있습니다. RPC는 이를 해석하지 않습니다. 예를 들어, 쿠키는 구조에 대해 콘텍스트 개시 프로그램을 나타내는 포인터나 인덱스일 수 있습니다. 서버는 요청 때마다 이 값을 계산하는 대신 콘텍스트 작성 시 이 값을 계산하여 요청 처리 시간을 단축합니다.

콜백

쿠키는 콜백과 함께 사용될 수도 있습니다. 서버는 rpc_gss_set_callback() 함수를 사용하여 콘텍스트가 처음 사용되는 시점을 알 수 있도록(사용자 정의) 콜백을 지정할 수 있습니다. 콜백은, 지정된 프로그램 및 버전에 대해 콘텍스트가 설정된 후 이 콘텍스트가 데이터 교환에 처음 사용될 때 호출됩니다.

사용자 정의 콜백 루틴은 다음과 같은 형식을 취합니다.

둘째, 세째 인수인 deleg와 gss_context는 GSS-API 데이터 유형이며 현재는 익스포트되지 않았으므로 콜백 함수에서 무시할 수 있습니다. (프로그램에서 GSS-API 작업을 해당 콘텍스트에서 수행하려 했을 경우 즉, 허용 기준을 테스트할 경우, deleg는 위임을 받은 동배의 ID이며 gss_context는 GSS-API 콘텍스트에 대한 포인터입니다.) cookie 인수는 앞에서 설명했습니다.

lock 인수는 rpc_gss_lock_t 구조에 대한 포인터입니다.

typedef struct {
	  bool_t              locked;
	  rpc_gss_rawcred_t   *raw_cred;
} rpc_gss_lock_t;

자세한 내용은 rpc_gss_set_callback(3N) 매뉴얼 페이지를 참고하십시오.

최대 데이터 크기

두 함수, rpc_gss_max_data_length()와 rpc_gss_svc_max_data_length()는 데이터가 보안 방법에 의해 변형되기 전에 그리고 네트워크를 통해 전송되기 전에 얼마나 커질 수 있는지를 확인할 때 유용합니다. 암호화 같은 보안 변형은 일반적으로 전송 데이터의 크기를 변경시킵니다(대부분의 경우 크기가 커짐). 데이터 용량이 사용 가능한 크기를 초과하지 않도록 이 두 함수(rpc_gss_max_data_length()는 클라이언트 버전이고 rpc_gss_svc_max_data_length()는 서버 버전임)는 해당 전송에 대한 최대 변형 전 크기를 반환합니다.

자세한 내용은 rpc_gss_max_data_length(3N)와 rpc_gss_svc_max_data_length(3N) 매뉴얼 페이지를 참고하십시오.

기타 함수

다음은 설치된 보안 시스템에 대한 정보를 읽어올 때 사용할 수 있는 함수들입니다.

• rpc_gss_get_mechanisms() 함수는 설치된 보안 메커니즘 목록을 반환합니다.

• rpc_gss_is_installed() 함수는 지정된 메커니즘이 설치되었는지 확인합니다.

• rpc_gss_get_mech_info() 함수는 해당 메커니즘에 대한 유효 QOP를 반환합니다.

이러한 함수를 사용하면 프로그래머가 응용 프로그램에 보안 매개변수를 하드코딩할 필요가 없습니다 (모든 RPCSEC_GSS 함수의 목록은 표 8-1과 rpcsec_gss(3N) 매뉴얼 페이지를 참고하십시오).

관련 파일

RPCSEC_GSS는 정보를 저장하기 위해 특정 파일을 사용합니다.

gsscred 테이블

서버가 요청과 관련된 클라이언트 증명서를 검색하면 클라이언트의 주체 이름(rpc_gss_principal_t 구조 포인터 형식)이나 해당 클라이언트의 로컬 UNIX 증명서(UID)를 읽어올 수 있습니다. NFS와 같은 서비스에서는 액세스 확인을 위해 로컬 UNIX 증명서를 사용하지만 기타 서비스에서는 주체 이름을 rpc_gss_principal_t 구조로 액세스 제어 목록에 직접 저장할 수도 있습니다.

클라이언트의 네트워크 증명서(주체 이름)와 로컬 UNIX 증명서의 일치는 자동으로 이루어지지 않으며, 로컬 보안 관리자가 명시적으로 설정해야 합니다.

gsscred 파일에는 클라이언트의 UNIX와 네트워크(예: Kerberos V5) 증명서가 모두 포함되어 있습니다. (네트워크 증명서는 rpc_gss_principal_t 구조의 16진수 ASCII로 표시됩니다). 이 파일은 XFN을 통해 액세스됩니다. 이 테이블은 파일, NIS, NIS+ 등이나 XFN에서 지원하는 향후 네임 서비스를 통해 구현될 수 있습니다. XFN 계층 구조에서 이 테이블은 this_org_unit/서비스gsscred로 표시됩니다. gsscred 테이블은 관리자가 gsscred 유틸리티를 사용하여 사용자와 메커니즘을 추가하거나 삭제함으로써 관리할 수 있습니다.

/etc/gss/qop 및/etc/gss/mech

사용자의 편의를 위해 RPCSEC_GSS는 메커니즘과 보호 수준(QOP) 매개변수를 나타낼 때 문자열 리터럴을 사용합니다. 그러나 기본 메커니즘 자체에서 메커니즘은 개체 식별자로, QOP는 32비트 정수로 표현되어야 합니다. 또한, 해당 메커니즘에 대한 서비스를 구현하는 공유 라이브러리가 각 메커니즘에 대해 지정되어야 합니다.

/etc/gss/mech 파일에는 ASCII 형식의 메커니즘 이름, 메커니즘의 OID, 해당 메커니즘에서 제공하는 서비스를 구현하는 공유 라이브러리, 서비스를 구현하는 커널 모듈(선택적) 등 시스템에 설치된 모든 메커니즘에 대한 정보가 저장됩니다. 다음은 이 파일에 저장된 정보의 예입니다.

kerberos_v5   1.2.840.113554.1.2.2    gl/mech_krb5.so gl_kmech_krb5

/etc/gss/qop 파일에는 설치된 모든 메커니즘에 대해 각 메커니즘이 지원하는 모든 QOP가 ASCII 문자열과 해당 32비트 정수로 저장됩니다.

/etc/gss/mech와 /etc/gss/qop는 해당 시스템에 보안 메커니즘이 처음 설치될 때 작성됩니다.

대부분의 커널 내부 RPC 루틴은 메커니즘과 QOP를 나타낼 때 문자열이 아닌 값을 사용하므로, 응용 프로그램에서 커널 내부 루틴의 기능을 사용해야 할 경우 rpc_gss_mech_to_oid()와 rpc_gss_qop_to_num()함수를 사용하여 이 매개변수에 대한 비 문자열 값을 읽어올 수 있습니다.