Groupe de travail Réseau	N. Williams, Sun	
Request for Comments: 5588	juillet 2009	
Catégorie : Sur la voie de la normalisation 	Traduction Claude Brière de L'Isle	

Extension d'interface générique de programme d'application de service de sécurité (GSS-API) pour mémoriser des accréditifs délégués

Résumé
Le présent document définit une nouvelle fonction pour l'interface générique de programme d'application de service de sécurité (GSS-API, Generic Security Service Application Program Interface) qui permet aux applications de mémoriser les accréditifs délégués (et autres) dans la mémoire implicite d'accréditifs GSS-API. Ceci est nécessaire aux applications GSS-API pour utiliser les accréditifs délégués comme elles utiliseraient d'autres accréditifs.

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. 

Table des matières
1. Introduction	1
2. Conventions utilisées dans le document	2
3. GSS_Store_cred()	2
4. C-Bindings	3
5. Exemples	3
6. Considérations sur la sécurité	4
7. Références normatives	4
Adresse de l'auteur	4

 	1.	Introduction

GSS-API [RFC2743] suppose clairement que des accréditifs existent dans une mémorisation implicite d'où ils peuvent être acquis en utilisant GSS_Acquire_cred() et GSS_Add_cred() ou par l'utilisation de l'accréditif par défaut. Plusieurs mémorisations d'accréditifs peuvent exister sur un hôte donné, mais seulement une mémorisation peut être accédée par GSS_Acquire_cred() et GSS_Add_cred() à un moment donné.

Cette hypothèse peut être vue aux paragraphes 1.1.1.2 et 1.1.1.3 de la [RFC2743] ainsi qu'au paragraphe 3.5 de la [RFC2744].

Les applications peuvent être capables de changer la mémorisation d'accréditifs d'où les accréditifs peuvent être acquis, soit en changeant les contextes d'utilisateur (lorsque les applications ont le privilège de le faire) ou par d'autres moyens (lorsque un utilisateur peut avoir plusieurs mémorisations d'accréditifs).

Certaine applications d'accepteur de GSS-API changent toujours les contextes d'utilisateur, après avoir accepté un contexte de sécurité de GSS-API et fait les vérifications d'autorisation appropriées, pour le contexte d'utilisateur correspondant au nom principal d'initiateur ou pour un contexte demandé par l'initiateur. Les moyens par lesquels les mémorisations d'accréditifs sont générés sortent généralement du domaine d'application de GSS-API.

Dans le cas de brides d'accréditif délégués, de tels accréditifs n'existent cependant pas dans la mémorisation d'accréditif de l'accepteur ou dans les mémorisations d'accréditifs des contextes de l'utilisateur pour lesquels l'application de l'accepteur pourrait changer. GSS-API ne fournit pas de mécanisme pour rendre disponibles les brides d'accréditif délégué pour une acquisition par GSS_Acquire_cred()/GSS_Add_cred(). GSS-API ne fournit pas non plus d'interfaces d'import/export d'accréditif comme les interfaces d'import/export de contexte GSS-API.

Donc, les accepteurs sont limités à faire seulement une utilisation directe des brides d'accréditif délégués et seulement avec GSS_Init_sec_context(), GSS_Inquire_cred*(), et GSS_Release_cred(). Cette limitation est particulièrement onéreuse sur les systèmes Unix où une invocation de exec() pour remplacer l'image de procès oblitère toutes les brides d'accréditifs délégué qui peuvent exister dans ce procès.

Afin de rendre les accréditifs délégués généralement aussi utiles que les accréditifs qui peuvent être acquis avec GSS_Acquire_cred() et GSS_Add_cred(), une primitive est nécessaire qui permette de mémoriser les accréditifs dans la mémoire implicite d'accréditifs. On appelle cette primitive "GSS_Store_cred()".

 	2.	Conventions utilisées dans le document

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	3.	GSS_Store_cred()

Entrées :
o	input_cred_handle CREDENTIAL HANDLE, -- accréditif à mémoriser ; NE DOIT PAS être GSS_C_NO_CREDENTIAL.
o	cred_usage ENTIER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, 2=ACCEPT-ONLY.
o	IDENTIFIANT D'OBJET desired_mech_element, -- si GSS_C_NULL_OID, mémorise alors tous les éléments de input_cred_handle, autrement, mémorise seulement l'élément du mécanisme correspondant.
o	overwrite_cred BOOLÉEN, -- si il est VRAI, remplace tout accréditif pour le même principal dans la mémorisation d'accréditif.
o	default_cred BOOLÉEN-- entrée pour information ; si il est VRAI, rend l'accréditif mémorisé disponible comme accréditif par défaut (pour l'acquisition avec GSS_C_NO_NAME comme nom désiré ou pour être utilisé comme GSS_C_NO_CREDENTIAL).

Résultats :
o	major_status ENTIER.
o	minor_status ENTIER.
o	ENSEMBLE D'IDENTIFIANTS D'OBJET mech_elements_stored, -- ensemble d'OID de mécanisme pour lesquels des éléments d'accréditif ont été mémorisés avec succès.
o	cred_usage_stored ENTIER -- comme cred_usage, mais indique quelle sorte d'accréditif a été mémorisée (utile quand le paramètre d'entrée cred_usage est réglé à INITIATE-AND-ACCEPT).

Codes major_status en retour :
o	GSS_S_COMPLETE indique que les accréditifs ont été mémorisés avec succès.
o	GSS_S_CREDENTIALS_EXPIRED indique que les accréditifs d'entrée ont expiré ou ont expiré avant qu'ils aient pu être mémorisés.
o	GSS_S_NO_CRED indique qu'aucune entrée d'accréditifs n'a été donnée.
o	GSS_S_UNAVAILABLE indique que la mémorisation d'accréditifs n'est pas disponible.
o	GSS_S_DUPLICATE_ELEMENT indique qu'un élément d'accréditif d'entrée pourrait n'être pas mémorisé parce qu'un accréditif pour le même principal existe dans la mémorisation courante d'accréditifs et que l'argument overwrite_cred input était FAUX.
o	GSS_S_FAILURE indique que l'accréditif ne pourrait pas être mémorisé pour une autre raison. Le code d'état mineur peut fournir plus d'informations si un desired_mech_element non GSS_C_NULL_OID a été donné.

GSS_Store_cred() est utilisé pour mémoriser, dans la mémorisation courante d'accréditifs, un accréditif donné qui a été acquis d'une mémorisation d'accréditifs différente ou a été accepté comme accréditif délégué.

Des éléments spécifiques de mécanisme d'un accréditif peuvent être mémorisés un à la fois en spécifiant un OID de mécanisme non GSS_C_NULL_OID comme argument d'entrée de desired_mech_element ; dans ce cas, le résultat d'état mineur DEVRAIT avoir une valeur spécifique du mécanisme quand l'état majeur n'est pas GSS_S_COMPLETE.

L'initiateur, l'accepteur, ou les deux usages de l'entrée d'accréditif peuvent être mémorisés conformément à l'argument d'entrée cred_usage.

Les éléments d'accréditif qui ont été réellement mémorisés, quand l'état majeur est GSS_S_COMPLETE, sont indiqués par les résultats des fonctions cred_usage_stored et mech_elements_stored.

Si les accréditifs existent déjà dans la mémorisation courante pour le principal de input_cred_handle, alors ces accréditifs ne sont pas remplacés dans les entrées d'accréditifs sauf si l'argument d'entrée overwrite_cred est VRAI.

Dans GSS-API, l'accréditif par défaut peut être utilisé en utilisant GSS_C_NO_CREDENTIAL ou une bride de CREDENTIAL acquise en invoquant GSS_Acquire_cred() ou GSS_Add_cred() avec l'entrée de desired_name réglée à GSS_C_NO_NAME.

Si l'argument d'entrée default_cred est VRAI, et si l'accréditif d'entrée peut être mémorisé avec succès, alors l'entrée d'accréditif DEVRAIT être mémorisée comme accréditif par défaut (voir ci-dessus).

Si la mémorisation courante d'accréditifs n'a pas d'accréditif par défaut (voir ci-dessus) alors la mise en œuvre PEUT rendre les accréditifs mémorisés disponibles comme accréditifs par défaut sans considération de la valeur de l'argument d'entrée default_cred.

 	4.	C-Bindings

Les C-Bindings pour GSS_Store_cred() utilisent, et sont conçus sur la base des types du style des C-Bindings de GSS-APIv2 [RFC2744].

         OM_uint32 gss_store_cred(
            OM_uint32         *minor_status,
            gss_cred_id_t     input_cred_handle,
            gss_cred_usage_t  cred_usage,
            const gss_OID     desired_mech,
            OM_uint32         overwrite_cred,
            OM_uint32         default_cred,
            gss_OID_set       *elements_stored,
            gss_cred_usage_t  *cred_usage_stored)

Figure 1

Les deux types d'arguments booléens, "overwrite_cred" et "default_cred", sont OM_uint32 ; 0 correspond à FAUX, les valeurs non zéro correspondent à VRAI.

 	5.	Exemples

L'usage prévu de GSS_Store_cred() est de rendre les accréditifs délégués disponibles pour les processus fils d'applications d'accepteur de GSS-API. Exemple de pseudo-code :

      /*
       * <GSS_Accept_sec_context() boucle résultant en GSS_S_COMPLETE,
       * un nom d'initiateur (ci-après, "src_name") et une bride d'accréditif délégué (ci-après "deleg_cred").>
       *
       * <"requested_username" est un nom d'utilisateur déduit du nom d'initiateur ou explicitement demandé par 
      '* l'application de l'initiateur.>
       */
      ...

      if (authorize_gss_client(src_name, requested_username)) {
         /*
          * Pour les plates-formes de type Unix-type cela peut signifier d'invoquer setuid() et
          * cela peut ou non aussi signifier d'activer/désactiver des variables d'environnement comme 
          * KRB5CCNAME et des détails spécifiques du système d'exploitation.
          */
         if (change_user_context(requested_username))
            (void) gss_store_cred(&minor_status, deleg_cred,
                                  GSS_C_INITIATE, actual_mech,
                                  0, 1, NULL, NULL);
         }
         else ...
      }
      else ...

 	6.	Considérations sur la sécurité

Les applications d'accepteur DOIVENT seulement mémoriser les accréditifs délégués dans les mémorisations d'accréditif appropriées et seulement après une autorisation appropriée de l'initiateur principal authentifié aux services demandés.

Les applications d'accepteur qui n'ont pas l'usage des accréditifs délégués DOIVENT les libérer (de telles applications d'accepteur qui utilisent les C-Bindings GSS-API peuvent simplement fournir une valeur NULLE pour l'argument delegated_cred_handle à gss_accept_sec_context()).

 	7.	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC2743]	J. Linn, "Interface générique de programme d’application de service de sécurité, version 2, mise à jour 1", janvier 2000. (MàJ par RFC5554)

[RFC2744]	J. Wray, "API de service générique de sécurité, version 2 : liaisons C", janvier 2000. (P.S.)

 	Adresse de l'auteur

Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX  78727
US

mél : Nicolas.Williams@sun.com