Uubu.fr

24 décembre 2016

pkaction

Obtenir des détails sur les actions enregistrées

pkaction est utilisé pour obtenir des informations sur les actions PolicyKit.

OPTIONS

--action-id Affiche seulement l'action spécifiée
--verbose Affiche des détails

24 décembre 2016

pkcheck

Vérifier si un processus est autorisé

pkcheck est utilisé pour vérifier si un processus, est autorisé à effectuer une action.

OPTIONS

--process processus pour lequel enregistrer l'agent d'authentification
--system-bus-name Nom du sujet pour lequel enregistrer l'agent d'authentification
--detail key value Peut être spécifié plusieurs fois pour passer des détails sur l'action
--allow-user-interaction Attend pour l'authentification
--list-temp Liste toutes les autorisations temporaires pour la session courante
--revoke-temp Révoque toutes les autorisations temporaires pour la session courante.
--action-id Spécifie l'action à vérifier
--process [pid|pid,pid-start-time|pid,pid-start-time,uid] Spécifie le processus à vérifier
--enable-internal-agent Si aucun agent d'authentification n'est disponible, enregistre son agent d'authentification textuel

Valeurs de retour

   si le processu spécifié est autorisé, pkcheck quitte avec une valeur de retour de 0. Si l'autorisation résultante contient des détails, ils sont affiché sur stdout.

   Si le processus spécifié n'est pas autorisé, pkcheck quitte avec une valeur de 1 et un message de diagnostique est affiché sur stdout.

   Si le processus spécifié n'est pas autorisé parce l'agent d'authentification a été fermé par l'utilisateur, pkcheck quitte avec une valeur 3 et un message de diagnostique affiché sur stderr. Des détails sont affichés sur stdout

   Si une erreur se produit pour l'autorisation, pkcheck quitte avec une valeur de retour de 127 et un message de diagnostique est affiché sur stderr.

   Si une ou plusieurs options passées sont malformées, pkcheck quitte avec une valeur de 126. Si stdin est un tty, ce man est également affiché.

24 décembre 2016

pkexec

Exécuter une commande sous un autre utilisateur

pkexec permet à un utilisateur autorisé d'exécuter le programmes spécifié sous un autre utilisateur. Si l'utilisateur n'est pas spécifié, utilise root.

Valeur de retour

une fois terminé, la valeur de retour est la valeur de retour du programme. Si le processus appelant n'est pas autorisé ou qu'une autorisation ne peut pas être obtenue ou qu'une erreur s'est produite, pkexec quitte avec une valeur de retour de 127. Si l'autorisation ne peut être obtenue, pkexec quitte avec la valeur 126.

l'agent d'authentification

pkexec, comme tout autre application PolicyKit, utilise l'agent d'authentification enregistré pour le procéssus appelant. Cependant, si aucun agent d'authentification n'est disponible, pkexec enregistre son propre agent d'authentification. Ce comportement peut être désactivé avec --disable-internal-agent.

Notes de sécurité

Exécuter un programme sous un autre utilisateur est une opération privilégiée. Par défaut l'autorisation requise nécéssite une authentification administrative. De plus, le dialogue d'authentification présenté à l'utilisateur affiche le chemin complet du programme à exécuter dont l'utilisateur est au courant de se qu'il va se passer.

+----------------------------------------------------------+
|_____________________Authenticate_____________________[X]_|
+----------------------------------------------------------+
|__________________________________________________________|
|__[Icon]__Authentication_is_needed_to_run_`/bin/bash'_____|
|__________as_the_super_user_______________________________|
|__________________________________________________________|
|__________An_application_is_attempting_to_perform_an______|
|__________action_that_requires_privileges._Authentication_|
|__________as_the_super_user_is_required_to_perform_this___|
|__________action._________________________________________|
|__________________________________________________________|
|__________Password_for_root:_[_________________________]__|
|__________________________________________________________|
|_[V]_Details:_____________________________________________|
|__Command:_/bin/bash______________________________________|
|__Run_As:__Super_User_(root)______________________________|
|__Action:__org.freedesktop.policykit.exec_________________|
|__Vendor:__The_PolicyKit_Project__________________________|
|__________________________________________________________|
|__________________________________[Cancel]_[Authenticate]_|
+----------------------------------------------------------+

L'environnement dans lequel le programme tourne, est définis à un environnement minimal et sûr pour éviter d'injecter du code via LD_LIBRARY_PATH ou des mécanismes similaires. De plus, la variable d'environnement PKEXEC_UID est définie avec l'UID invoquant pkexec. En résultat, pkexec n'autorise pas de lancer des application X11 sous un autre utilisateur vu que $DISPLAY et $XAUTHORITY ne sont pas définis. Il y a 2 variables retenus si org.freedesktop.policykit.exec.allow_gui dans une action est définis à une valeur non-nul. C'est découragé, et utilisé uniquement pour compatibilité.

Autorisations requises

Par défaut, org.freedesktop.policykit.exec est requis sauf si un fichier de définition d'action est présent pour le programme en question. pour exiger une autre autorisation, cela peut être spécifié en utilisant l'annotation org.freedesktop.policykit.exec.path dans une action.

Exemple

Pour spécifier un type d'autorisation nécessaire pour exécuter le programme /usr/bin/pk-example-frobnicate sous un autre utilisateur, écrire simplement une définition d'action:
‹?xml version="1.0" encoding="UTF-8"?›
‹!DOCTYPE policyconfig PUBLIC
    "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
    "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"›
‹policyconfig›

    ‹vendor›Examples for the PolicyKit Project‹/vendor›
    ‹vendor_url›http://hal.freedesktop.org/docs/PolicyKit/‹/vendor_url›

    ‹action id="org.freedesktop.policykit.example.pkexec.run-frobnicate"›
        ‹description›Run the PolicyKit example program Frobnicate‹/description›
        ‹description xml:lang="da"›Kør PolicyKit eksemplet Frobnicate‹/description›
        ‹message›Authentication is required to run the PolicyKit example program Frobnicate (user=$(user), program=$(program), command_line=$(command_line))‹/message›
        ‹message xml:lang="da"›Autorisering er påkrævet for at afvikle PolicyKit eksemplet Frobnicate (user=$(user), program=$(program), command_line=$(command_line))‹/message›
        ‹icon_name›audio-x-generic‹/icon_name›
        ‹defaults›
            ‹allow_any›no‹/allow_any›
            ‹allow_inactive›no‹/allow_inactive›
            ‹allow_active›auth_self_keep‹/allow_active›
        ‹/defaults›
        ‹annotate key="org.freedesktop.policykit.exec.path"›/usr/bin/pk-example-frobnicate‹/annotate›
    ‹/action›

‹/policyconfig›

   placer ce fichier dans /usr/share/polkit-1/actions avec un nom qui ait du sens, par exemple l'espace de nom de l'action. Noter que pkexec ne valide pas les arguments passés au programme. Dans un cas normal (où l'authentification administration est requise à chaque fois que pkexec est utilisé), ce n'est pas un problème vu que si l'administrateur est un administrateur il peut simplement lancer pkexec bash pour devenir root.

   Cependant, si une action est utilisée pour laquelle l'utilisateur peut retenir l'authorisation ( ou si l'utilisateur est implicitement autorisé), tel qu'avec pk-example-frobnicate ci-dessus, cela peut être un problème de sécurité. Donc, les programmes pour lesquels l'autorisation requise par défaut est changé, ne devraient jamais implicitement faire confiance à l'entrée utilisateur.

24 décembre 2016

pkttyagent

Helper d'authentification textuel

pkttyagent est utilisé pour démarrer un agent d'authentification textuel pour le sujet spécifié par --process ou --system-bus-name. Si aucun n'est spécifié, utilise le processus parent.

Pour être notifié quand l'agent d'authentification a été enregistré, écouter soit D-Bus ou utiliser --notify-fd pour passer le numéro d'un descripteur de fichier au programme. Ce fd sera fermé quand l'agent d'authentification est enregistré.

Valeur de retour

   Si l'agent d'authentification ne peut pas être enregistré, pkttyagent quitte avec un code de sortie de 127. Des messages de diagnostique sont affichés sur stderr.

   Si une ou plusieurs options sont malformées, pkttyagent quitte avec le code 126. Si stdin est un tty, ce man est également affiché.

   Si l'agent d'authentification a été enregistré avec succès, pkttyagent continue de fonctionner, interagissant avec l'utilisateur si nécessaire. Quand ses services ne sont plus nécessaires, le processus s'arrête.

Notes

Vu que les PID peuvent être recyclés, l'appelant devrait toujours utiliser pid,pid-start-time en utilisant l'option --process. La valeur de pid-start-time peut être déterminé en consultant par exemple proc. Si seul pid est passé à l'option --process, pkttyagent recherche l'heure de début de lui-même.

OPTIONS

--process { pid | pid,pid-start-time} processus pour lequel enregistrer l'agent d'authentification
--system-bus-name busname Nom du sujet pour lequel enregistrer l'agent d'authentification
--notify-fd fd Permet de passer un descripteur de fichier pour connaître quand l'agent d'authentification est enregistré
--fallback Empêche l'agent d'authentification textuel de remplacer un agent d'authentification existant.

24 décembre 2016

polkit

framework d'autorisation

policyKit fournis une API d'autorisation conçue pour être utilisée par des programmes privilégiés (mécanismes) offrant un service à des programmes non privilégiés (clients) sous la forme d'un mécanisme IPC tel que D-Bus ou pipes Unix. Dans ce scénario, le mécanisme traite généralement le client n'étant pas de confiance. Pour toute requête d'un client, le mécanisme doit déterminer si la requête est autorisée ou si elle devrait refuser le service au client. En utilisant l'API PolicyKit, un mécanisme peut décharger cette décision à un tier de confiant: l'autorité PolicyKit.

En plus d'agir comme autorité, PolicyKit permet aux utilisateurs d'obtenir une autorisation temporairement en authentifiant soit un utilisateur administratif ou le propriétaire de la session auquel appartient l'utilisateur. C'est utile pour les scénarios où un mécanisme doit vérifier que l'opérateur du système est réellement l'utilisateur ou réellement un utilisateur administratif.

Architecture système

   L'architecture système de PolicyKit est composé de l'autorité (implémenté comme un service dans D-Bus) et un agent d'authentification par session utilisateur (fournis et démarré par la session utilisateur). Additionnellement, PolicyKit support des points d'extensions - spécifiquement, les vendeurs et/ou sites peuvent écrire des extensions pour contrôler complètement la stratégie d'autorisation. Dans un diagramme block, l'architecture ressemble à ceci:

    +-------------------+
_|___Authentication__|
_|_______Agent_______|
_+-------------------+
_|_libpolkit-agent-1_|
_+-------------------+
________^__________________________________+--------+
________|__________________________________|_Client_|
________+--------------+___________________+--------+
_______________________|________________________^
_______________________|________________________|
User_Session___________|________________________|
=======================|========================|=============
System_Context_________|________________________|
_______________________|________________________|
_______________________|____________________+---+
_______________________V____________________|
_____________________/------------\_________|
_____________________|_System_Bus_|_________|
_____________________\------------/_________|
_______________________^________^___________V
_______________________|________|______+---------------------+
________+--------------+________|______|______Mechanism______|
________|_______________________|______+---------------------+
________V_______________________+----›_|_libpolkit-gobject-1_|
+------------------+___________________+---------------------+
|_org.freedesktop._|
|____PolicyKit1____|
+------------------+
|___Backends_and___|
|____Extensions____|
+------------------+

   libpolkit-gobject-1 enveloppe l'API D-Bus PolicyKit utilisant GObject. Cependant, un mécanisme peut également utiliser l'API D-Bus ou la commande pkcheck pour vérifier les autorisations.

   La librairie libpolkit-agent-1 fournis une abstraction du système d'authentification natif, par exemple pam et également des facilités d'enregistrement et de communication avec le service D-Bus PolicyKit.

   Les extensions PolicyKit et les backends d'autorité sont implémentés en utilisant libpolkit-backend-1

Agents d'authentification

Un agent d'authentification est utilisé pour que l'utilisateur d'une session prouve qu'il est l'utilisateur ou un utilisateur administratif. Pour s'intégrer avec le reste de la session utilisateur, les agents d'authentification sont censés être fournis par la session utilisateur que l'utilisateur utilise. Par exemple, un agent d'authentification peut ressembler à:

+----------------------------------------------------------+
|_____________________Authenticate_____________________[X]_|
+----------------------------------------------------------+
|__________________________________________________________|
|__[Icon]__L'authentification_est_requise_pour_lancer______|
|__________des_tests_ATA_SMART_____________________________|
|__________________________________________________________|
|_________Une_application_tente_d'effectuer_une_action_____|
|_________qui_nécessite_des_privilèges._L'authentification_|
|_________super_utilisateur_est_requis_pour_effectuer______|
|_________cette_action.____________________________________|
|__________________________________________________________|
|__________Password_for_root:_[_________________________]__|
|__________________________________________________________|
|_[V]_Details:_____________________________________________|
|__Drive:__ATA_INTEL_SSDSA2MH08_(045C)_____________________|
|__Device:_/dev/sda________________________________________|
|__Action:_org.fd.devicekit.disks.drive-ata-smart-selftest_|
|__Vendor:_The_DeviceKit_Project___________________________|
|__________________________________________________________|
|__________________________________[Cancel]_[Authenticate]_|
+----------------------------------------------------------+

Si le système est configuré sans un compte root il peut vous autoriser à sélectionner un utilisateur administratif:
+----------------------------------------------------------+
|_____________________Authenticate_____________________[X]_|
+----------------------------------------------------------+
|__________________________________________________________|
|__[Icon]__Authentication_is_required_to_run_ATA_SMART_____|
|__________self_tests______________________________________|
|__________________________________________________________|
|__________An_application_is_attempting_to_perform_an______|
|__________action_that_requires_privileges._Authentication_|
|__________as_one_of_the_users_below_is_required_to________|
|__________perform_this_action.____________________________|
|__________________________________________________________|
|__________[[Face]_Patrick_Bateman_(bateman)_________[V]]__|
|__________________________________________________________|
|__________Password_for_bateman:_[______________________]__|
|__________________________________________________________|
|_[V]_Details:_____________________________________________|
|__Drive:__ATA_INTEL_SSDSA2MH08_(045C)_____________________|
|__Device:_/dev/sda________________________________________|
|__Action:_org.fd.devicekit.disks.drive-ata-smart-selftest_|
|__Vendor:_The_DeviceKit_Project___________________________|
|__________________________________________________________|
|__________________________________[Cancel]_[Authenticate]_|
+----------------------------------------------------------+

Les applications qui tournent pas sous un environnement de bureau peuvent ne pas avoir d'agent d'authentification associé avec lui. De telles applications peuvent utiliser le type PolkitAgentTextListener ou pkttyagent pour que l'utilisateur puisse s'authentifier en utilisant une interface textuelle.

Déclarer des actions

   Un mécanisme doit déclarer un jeu d'actions pour utiliser PolicyKit. Les actions correspondent aux opérations que les clients peuvent demander et sont définis dans des fichiers XML que le mécanisme install dans /usr/share/polkit-1/actions.

Les action PolicyKit sont en namespace et peuvent seulement contenir les caractères "[a-z][0-9].-". Chaque fichier XML peut contenir plus d'une action mais toutes les actions doivent être dans le même espace de nom et le fichier doit être nommé après l'espace de nom et doit avoir l'extension .policy. Le fichier XML doit avoir la déclaration doctype suivante:
‹?xml version="1.0" encoding="UTF-8"?›
‹!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd"›

   L'élément policyconfig doit être présent exactement une fois. Les éléments qui peuvent être utilisés dans policyconfig incluent:

vendor Le nom du projet ou vendeur qui fournis les action dans le document XML.
vendor_url Une URL du projet ou vendeur qui fournis les action dans le document XML.
icon_name Un icône représentant le projet ou vendeur qui fournis les actions.
action Déclare une action. Le nom de l'action est spécifiée en utilisant l'attribut id et peuvent seulement contenir les caractères "[a-z][0-9].-"

   Les éléments qui peuvent être inclus dans les actions sont:

description Une description de l'action
message Le message affiché à l'utilisateur quand les accréditifs sont demandés.
defaults Cet élément est utilisé pour spécifier des autorisation implicites au client

Les éléments qui peuvent être utilisés dans defaults incluents:

allow_any Autorisation implicite qui s'applique à tout client.
allow_inactive Autorisation implicite qui s'applique aux clients dans les sessions inactives dans les consoles locales.
allow_active Autorisation implicite qui s'applique aux clients dans les sessions actives dans les consoles locales.

   Chaque élément allow_any, allow_inactive, et allow_active peuvent contenir les éléments suivants:

no non autorisé
yes autorisé
auth_self Authentification par le propriétaire de la session d'où vient le client requise
auth_admin Authentification par un utiliateur administratif est requis
auth_self_keep Comme auth_self mais l'autorisation est conservé pour une période brève.
auth_admin_keep Comme auth_admin mais l'autorisation est conservée pour une brève période.

annotate Utilisé pour annoter une action avec une paire de clé/valeur. La clé est spécifiée en utilisant l'attribut clé et la valeur est spécifiée en utilisant la valeur attribut. Cet élément peut apparaître 0 ou plusieurs fois.
vendor Utilisé pour remplacer le vendeur sur une base par action
vendor_url Utilisé pour remplacer l'URL vendeur sur une base par action
icon_name Utilisé pour remplacer le nom de l'icône sur une base par action

   Les éléments localization, description et message peuvent exister 0 ou plusieurs fois avec différents attributs xml:lang

   Pour lister les actions installées, utiliser la commande pkaction

Annotations connues

org.freedesktop.policykit.exec.path est utilisé par le programme pkexec fournis par PolicyKit.
org.freedesktop.policykit.imply (sa valeur est une chaîne contenant une liste séparée par un espace d'identifiants d'action). peut être utilisé pour définir des actions méta. La manière dont elles fonctionnent et que si un sujet est autorisé pour une action spécifiée, il est également autorisé pour toutes les autres action de l'annotation. Une utilisation typique est en définissant un shell avec un simple bouton lock qui devrait débloquer plusieurs actions pour des mécanismes distincts.
org.freedesktop.policykit.owner peut être utilisé pour définir un jeu d'utilisateurs qui peuvent demander si un client est autorisé à effectuer cette action. Si cette annotation n'est pas spécifiée, seul root peut vérifier si un client tournant sous un utilisateur différent est autorisé pour une action. La valeur de cette annotation est une chaîne contenant une liste séparée par des espaces d'entrées PolkitIdentity. par exemple "unix-user:42 unix-user:colord". Une utilisation typique est pour les processus qui tournent sous un utilisateur système au lieu de root.

24 décembre 2016

polkitd

Service PolicyKit

polkitd fournis le service D-Bus org.freedesktop.PolicyKit1 dans le bus de message système. Les utilisateurs ou administrateurs ne devraient jamais avoir besoin de démarrer ce service vu qu'il est démarré par dbus-daemon quand une application appèlent le service.

19 octobre 2013

Cyrus SASL

Serveur SASL de Cyrus

Composants SASL

Le premier composant de la librairie SASL est la couche Glue. Il s'occupe des tâches de base:

- Charger les plugins
- Gère les propriétés de sécurité nécessaires de l'application pour l'aider dans le choix du mécanisme ou pour limiter les mécanismes disponibles.
- Lister les plugins disponibles au applications
- Choisir le meilleur mécanisme dans une liste pour une authentification particulière
- Router les paquets de données d'authentification entre l'application et le mécanisme choisi
- Fournir des informations sur la négociation SASL aux applications

Il fournis également d'autres services aux plugins et applications tels que l'encodage MIME base 64, génération de nombres aléatoires, etc. Il permet également aux mécanismes et aux applications d'accéder à types spéciaux de plugin. Auxiliary Property "auxprop" qui fournis une interface de base simple et peut retourner des propriétés sur l'utilisateur tel que le mot de passe, répertoire personnel, ou adresse mail. et Username Canonicalization, qui peut fournir des manières de canoniser un nom d'utilisateur ou effectuer d'autres tâches.

Mécanisme PLAIN et mots de passe en texte clair

auxprop Vérifie les mots de passe dans userPassword fournis par une plugin de propriété auxiliaire. Par exemple, SASL est fournis avec sasldb, qui peut être utilisé pour authentifier avec des mots de passe stockés dans /etc/sasldb2.
saslauthd Permet de vérifier des mots de passe en utilisant divers mécanismes.
courrier-IMAP authdaemond Utilisé pour contacter authdaemond pour vérifier les mots de passe.

Mécanismes à secret partagé

Cyrus SALS fournis plusieurs méthodes d'authentification basé sur un secret partagé: CRAM-MD5 et son successeur DIGEST-MD5.

Mécanismes Kerberos

Cyrus SASL fournis 2 mécanismes qui utilisent kerberos: Kerberos_v4 et GSSAPI qui permet d'utiliser kerberos v5.

Mécanismes OTP

Cyrus SASL support le mécanisme OTP, similaire à CRAM-MD5 et DIGEST-MD5. Ces OTP sont stockés dans /etc/sasldb2. SASL support également OPIE.

Auxiliary Properties

SASLv2 introduit le concept de propriétés auxiliaires. C'est la capacité de rechercher des informations liées à l'authentification ou l'authorisation depuis un répertoire durant le processus d'authentification.

Fichier de configuration par défaut

Par défaut, Cyrus SASL lit ses options depuis /usr/lib/sasl2/App.conf (où App est le nom de l'application). Les applications peuvent redéfinir comment la librairie recherche les informations de configuration.

OPTIONS

authdaemond_path (SASL library) Chemin du socket UNIX de authdaemond (défaut: /dev/null)
auto_transition (SASL library) à yes ou noplain et utilisé avec auxprop. Transferts automatiquement les users à d'autres mécanismes quand ils font une authentification plaintext réussie. à noplain, seul les secrets non plaintext sont écris. (défaut: no)
auxprop_plugin (AuxProp Plugin) Nom(s) de(s) plugin(s) auxiliaire à utiliser. (défaut: null)
canon_user_plugin (SASL library) Nom du plugin canon_user à utiliser (défaut: INTERNAL)
keytab (GSSAPI) Emplacement du fichier keytab (défaut: /etc/krb5.keytab)
ldapdb_uri (LDAPDB plugin) liste d'URI ldap
ldapdb_id (LDAPDB plugin) id d'authentification ldap
ldapdb_mech (LDAPDB plugin) mécanisme pour l'authentification
ldapdb_pw (LDAPDB plugin) password
ldapdb_rc (LDAPDB plugin) Fichier à placer dans l'environnement LDAPRC
ldapdb_starttls (LDAPDB plugin) utiliser StartTls (try, demand).
ldapdb_canon_attr (LDAPDB plugin) attribut contenant le nom canonique de l'utilisateur
log_level (SASL library) Niveau de debug (défaut: 1 (SASL_LOG_ERR))
mech_list (SASL library) liste de mécanisme à autoriser (défaut: tous)
ntlm_server (SASL library) Liste des serveurs
ntlm_v2 (SASL library) Envoyer des réponses ntlmv2 au serveur opiekeys (OPIE) Emplacement du fichier opiekeys (défaut: /etc/opiekeys)
otp_mda (OPIE) Algorithme pour l'OTP (md4, md5, sha1) (défaut: md5)
plugin_list (SASL library) Emplacement de la liste des plugins
pwcheck_method (SASL library) liste des mécanismes utilisés pour vérifier les mots de passe, utilisé par sasl_checkpass (auxprop, saslauthd, pwcheck, authdaemond, alwaystrue). (défaut: auxprop)
reauth_timeout (DIGST-MD5) Temps en minutes de cache de l'authentification pour une réauthentification rapide. défaut: 0
saslauthd_path (SASL library) Chemin vers le répertoire saslauthd, incluant le pipe /mux
sasldb_path (sasldb plugin) Chemin du fichier sasldb (défaut: /etc/sasldb2)
sql_engine (SQL plugin) Nom du moteur SQL à utiliser (mysql, pgsql, sqlite, sqlite3). défaut: mysql
sql_hostnames (SQL plugin) liste de serveurs:ports SQL
sql_user (SQL plugin) Utilisateur SQL pour l'authentification
sql_passwd (SQL plugin) Mode de passe pour l'authentification
sql_database (SQL plugin) Nom de la base de données qui contient les propriétés auxiliaires
sql_select (SQL plugin) Déclaration SELECT à utiliser pour récupérer les propriétés
sql_insert (SQL plugin) Déclaration INSERT pour créer des propriétés
sql_update (SQL plugin) Déclaration UPDATE pour mettre à jours des propriétés
sql_usessl (SQL plugin) à yes, créé une connexion sécurisée
srp_mda (SRP) Algorithme à utiliser pour les calculs SRP (md5, sha1, rmd160).
srvtab (kerberos 4) Emplacement du fichier srvtab (défaut: /etc/srvtab)

Notes sur les options auxprop sql

%U username
%p Nom de la propriété à modifier/ajouter
%r Royaume auquel l'utilisateur appartient
%v Valeur de la propriété

Exemples

sql_select: SELECT %p FROM user_table WHERE username = '%u' and realm = '%r'
Va envoyer la requête suivante pour l'utilisateur bovik et le royaume madoka.surf.org.uk:
SELECT userPassword FROM user_table WHERE username = 'bovik' and realm = 'madoka.surf.org.uk';
sql_insert: INSERT INTO user_table (username, realm, %p) VALUES ('%u', '%r', '%v')
Va générer les requêtes suivante pour l'utilisateur bovik dans le royaume madoka.surf.org.uk et le userPassword "wert":
INSERT INTO user_table (username, realm, userPassword) VALUES ('bovik', 'madoka.surf.org.uk', 'wert');

Notes sur les options LDAPDB

s'active en créant /usr/lib/sasl2/slapd.conf avec:
auxprop_plugin: slapd

Exemples

ldapdb_uri: ldap://ldap.example.com
ldapdb_id: root
ldapdb_pw: secret
ldapdb_mech: DIGEST-MD5
ldapdb_canon_attr: uid
root authcid doit avoir des privilèges de proxy authorization pour tous les comptes authorisés à s'authentifier.
ldapdb_uri: ldapi://
ldapdb_mech: EXTERNAL
Cette configuration assume que le serveur LDAP est sur le même serveurs qui utilise SASL. C'est plus rapide et sécure et n'a pas besoin de stocker de user/password. slapd.conf doit mapper ces usernames en DN ldap:
sasl-regexp uidNumber=(.*)\\+gidNumber=(.*),cn=peercred,cn=external,cn=auth ldap:///dc=example,dc=com ??sub ?(&(uidNumber=$1)(gidNumber=$2))
sasl-regexp uid=(.*),cn=external,cn=auth ldap:///dc=example,dc=com ??sub ?(uid=$1)

19 octobre 2013

gsasl

CLI pour libgsasl

OPTIONS

-c, --client Agit comme client
--client-mechanism Mécanismes supportés par le client
-s, --server Agit comme serveur
--server-mechanism Mécanismes supportés par le serveur
--connect=HOSTNAME[:SERVICE] Serveur distant.
-d, --application-data Après l'authentification lis les données de stdin et le lance dans la couche de sécurité du mécanisme puis l'affiche en base64.
--imap Utilise la procédure de login style IMAP
-m, --mechanism=STRING mécanisme à utiliser
--no-client-first Empêche le client d'envoyer les info en premier (client only)
-n, --anonymous-token=STRING Token pour l'authentification anonyme, générallement l'addresse email.(ANONYMOUS only)
-a, --authentication-id=STRING Identité du propriétaire des acréditations
-z, --authorization-id=STRING Identité de demandeur
--disable-cleartext-validate Désactive la validation cleartext, force le serveur à demander le mot de passe
--enable-cram-md5-validate Valide les challenge/réponse CRAM-MD5 intéractivement
--hostname=STRING Nom du serveur avec le service requis
-p, --password=STRING Mot de passe pour l'authentification
--passcode=NUMBER Passcode pour l'authentification (SECURID only)
--quality-of-protection=‹qop-auth | qop-int | qop-conf› Protection du payload. qop-auth: pas de protection, qop-int: protection de l'intégrité, qop-conf: confidentitalité
-r, --realm=STRING Royaume
--service=STRING Nom du service requis
--service-name=STRING Nom du serveur en cas de serveur répliqué (DIGEST-MD5 only)
-x, --maxbuf=NUMBER Taille de buffer max (DIGEST-MD5 only)
--starttls Force l'utilisation de starttls
--no-starttls désactive starttls
--no-cb Ne définis pas de chanel binding
--x509-ca-file=FILE Fichier contenant les certificats des CA
--x509-cert-file=FILE Fichier contenant le certificat du client
--x509-key-file=FILE Fichier contenant la clé privée du client
--priority Chaîne de priorité de chiffrement
-Q, --QUIET, --SILENT mode silencieux
-v, --verbose mode verbeux

29 juin 2014

.k5identity

Liste de règles pour sélectionner un principal

   Ce fichier, qui réside dans le home d'un utilisateur, contient une liste de règle pour sélectionner un principal client basé sur le serveur accédé. Ces règles sont utilisée pour choisir un cache d'accréditifs dans la collection de cache quand c'est possible. Chaque ligne a la forme

  principal field=value

  Si le principal serveur rencontre toutes les contrainte de champ, le principal est choisi comme principal client. Les champs suivant sont reconnus:

realm Si le domaine du principal du serveur est connus, il est matché avec cette valeur, qui peut être un pattern en utilisant les wildcard shell.
service Si le serveur principal est un principal basé sur l'hôte, son composant service est matché avec la valeur, qui peut être un pattern en utilisant les wildcard shell.
host Si le principal du serveur est un principal basé sur l'hôte, son nom d'hôte est convertis en minuscule et matché avec la valeur, qui peut être un pattern en utilisant les wildcard shell.

   Si le principal du serveur matche plusieurs lignes dans ce fichier, le principal depuis le premier matche est utilisé. Si aucune ligne ne matche, les accréditifs seront sélectionnés d'une autre manière, tel que le realm heuristic ou le cache primaire courant.

L'exemple suivant sélectionne le principal client alice@KRBTEST.COM si le serveur principal est dans ce domaine, le principal alice/root@EXAMPLE.COM si l'hôte serveur est dans un sous-domaine, et le principal alice/mail@EXAMPLE.COM en accédant au service IMAP sur mail.example.com:
alice@KRBTEST.COM realm=KRBTEST.COM
alice/root@EXAMPLE.COM host=*.servers.example.com
alice/mail@EXAMPLE.COM host=mail.example.com service=imap

29 juin 2014

.k5login

Liste de principaux Kerberos

Ce fichier réside dans le home de l'utilisateur, contenant une liste de principaux Kerberos. tous ceux ayant des tickets valide pour un principal dans ce fichier est autorisé à accéder à l'hôte avec l'UID de l'utilisateur dont ce fichier est dans son home. Une utilisation commune est de placer ce fichier dans le home de root, autorisant les administrateurs système à accéder en root à l'hôte via Kerberos.

Exemples

Supposons que l'utilisateur Alice a un fichier .k5login dans son répertoire home contenant la ligne suivante:
bob@FOOBAR.ORG
Celà permet à bob d'utiliser Kerberos tel que SSH, pour accéder au compte Alice, en utilisant les tickets Kerberos de bob.
Supposons qu'Alice est un administrateur système. Alice et les autres administrateurs auront leurs principaux dans le .k5login de root:
alice@BLEEP.COM
joeadmin/root@BLEEP.COM
Cela permet aux administrateurs de se logger en root avec leur tickets.

27 juin 2014

k5srvutil

Commandes

list Liste les clé dans un keytab
change Utilise le protocole kadmin pour mettre à jours les clés dans la base Kerberos avec des clés générées aléatoirement, et met à jours les clés dans le keytab. Si un numéro de version de clé ne matche pas le numéro de version dans la base, l'opération échoue. Les anciennes clés sont laissées dans le keytab pour que des tickets existant continuent à fonctionner. Si le flag -i est donné, k5srvutil demande confirmation avant de changer chaque clé. -e permet de spécifier les types de chiffrement et de salt.
delold Supprime les anciennes clé du keytab.
delete Supprime les clés dans le keytab, demande confirmation.

k5srvutil utilise kadmin pour éditer le keytab.

OPTIONS

-i Demande confirmation pour chaque opération
-f filename Spécifie le fichier keytab
keysalts Spécifie les types de chiffrement et de salt à utiliser.

20 juin 2014

kadm5.acl

Fichier acl pour kadmind

Kadmind utilise un fichier d'acl pour gérer les droits d'accès à la base Kerberos. Pour les opérations qui affectent les principaux, le fichier d'acl contrôle également quels principaux peuvent opérer sur quels autres principaux. L'emplacement par défaut est LOCALSTATEDIR/krb5kdc/kadm5.acl ou la variable acl_file dans kdc.conf.

Syntaxe

   Les lignes vides ou commençant par # sont ignorées. les lignes contenant une entrée acl a le format suivant:

  principal permissions [target_principal [ restrictions] ]

  Note: l'ordre des lignes est importante. La première entrée correspondante va contrôler l'accès pour un acteur principal sur un principal cible.

principal (Nom de principal complet ou partiel) Spécifie le principal dont les permissions sont définies
permissions Spécifie quels opérations peuvent être effectuées ou non par le principal. C'est une chaîne d'un ou plusieurs caractères ou leur opposé majuscule qui désactive cette permission:

a ajout de principaux ou stratégies
c changer les mots de passe pour les principaux
d suppression de principaux ou stratégies
i demandes de renseignements concernant les principaux et stratégies
l lister les principaux ou stratégies
m modification de principaux ou stratégies
p propagation de la base de principaux
s paramétrage explicite des clés pour un principal
x raccourci pour admcil. Tous les privilèges

target_principal (Optionnel. Nom de principal complet ou partiel) Spécifie le principal sur lequel les permissions s'appliquent. chaque composant du nom peut être wildcarded (*). Peut également inclure des référence au principal, dans lequel *number matche le wilcard correspondant dans principal
restrictions (optionnel) Une chaîne de flags. Les restrictions permises sont:

{+|-}flagname flag est forcé à la valeur indiquée. Les flags permissifs sont les même que les flags + et - pour les commandes add_principal et modify_principal de kadmin.
-clearpolicy La stratégie est forcée à être vide
-policy pol La stratégie est forcée à pol
-{expire, pwexpire, maxlife, maxrenewlife} time (chaîne de temps getdate) la valeur associée est forcée à MIN(time, valeur demandée)

Ces flags agissent comme restriction sur toute opération d'ajout ou de modification qui sont permis dans la ligne d'ACL.

Attention: si le fichier d'acl est modifié, kadmind doit être redémarré pour prendre en compte les modifications.

Exemple

Exemple de fichies kadm5.acl:
*/admin@ATHENA.MIT.EDU    *
joeadmin@ATHENA.MIT.EDU ADMCIL
joeadmin/*@ATHENA.MIT.EDU il    */root@ATHENA.MIT.EDU
*/root@ATHENA.MIT.EDU cil    *1@ATHENA.MIT.EDU
*/*@ATHENA.MIT.EDU i
*/admin@EXAMPLE.COM x    *    -maxlife 9h -postdateable

ligne 1 Tout principal dans le domaine ATHENA.MIT.EDU avec une instance admin a tous les privilèges administratifs
ligne 2 et 3 L'utilisateur joeadmin a toutes les permissions avec son instance admin, joeadmin/admin@ATHENA.MIT.EDU (matche de la ligne 1), il n'a aucune permission avec son instance joeadmin@ATHENA.MIT.EDU (matche de la ligne 2). Ses instances root et autre non admin ont les permissions de lister et demander avec tout principal qui a l'instance root (macthe de la ligne 3).
ligne 4 Tout principal root dans ATHENA.MIT.EDU peut demander, lister ou changer les mots de passe de leur instance nul, mais pas les autres instance null.
ligne 5 Tout principal dans ATHENA.MIT.EDU (sauf joeadmin@ATHENA.MIT.EDU comme mentionné plus haut) a les privilèges demander.
ligne 6 Finallement, tout principal avec une instance admin dans EXAMPLE.COM a toutes les permissions, mais tout principal qu'ils créent ou modifient ne seront par capable d'obtenir de tickets post-datés ou avec une durée de vie supérieur à 9 heures.

25 juin 2014

kadmin

Interface CLI pour l'administration de Kerberos

kadmin et kadmin.local sont des interfaces en ligne de commande pour le système d'administration de Kerberos. Ils fonctionnent de manière similaire à l'exception que kadmin.local communique directement avec le fichier de base de données.

Le client distant kadmin utilise Kerberos pour s'authentifier auprès de kadmind en utilisant le principal de service kadmin/ADMINHOST, où ADMINHOST est le fqdn du serveur d'administration, ou kadmin/admin. Si le cache d'accréditifs contient un ticket pour un de ces principaux, et que l'option -c est spécifié, ce ticket est utilisé pour s'authentifier à kadmind. Sinon les options -p et -k sont utilisés pour spécifier le nom du principal client utilisé pour s'authentifier. Une fois que kadmin a déterminé le nom du principal, il demande un ticket de service au KDC, et l'utilise pour s'authentifier à kadmind.

OPTIONS

-r realms Utilise de domaine spécifié par défaut
-p principal Utilise le principal spécifié pour s'authentifier. Sinon, kadmin va ajouter /admin au nom de principal primaire du ccache par défaut, la valeur de la variable d'environnement USER, ou le username obtenu par getpwuid, dans cet ordre.
-k Utilise un keytab pour déchiffrer la réponse du KDC au lieu de demander un mot de passe. Dans ce cas, le principal par défaut sera host/hostname. S'il n'y a par de keytab spécifié avec l'option -t, le keytab par défaut sera utilisé.
-t keytab Utilise keytab pour déchiffrer la réponse du KDC. Peut seulement être utilisé avec l'option -k
-n Demande un traitement anonyme. 2 types de principaux anonyme sont supportés. Pour l'anonymité complète, configurer PKINIT et utiliser l'option -n avec un principal sous la forme @REALM. Si permis par le KDC, un ticket anonyme sera retourné. Une seconde forme est supportée, et cache l'identité du client mais pas le domaine du client. Pour ce mode, utiliser kinit -n avec un principal normal. Si supporté par le KDC, le principal, mais pas le domaine, sera remplacé par le principal anonymous.
-c credentials_cache Utile de cache d'accréditifs spécifié. Le cache devrait contenir un ticket de service pour kadmin/ADMINHOST ou kadmin/admin. Si non spéifié, kadmin demande un nouveau ticket au KDC et le stocke dans son propre cache temporaire.
-w password Utilise le mot de passe au lieu de le demander
-q query Effectue le requête spécifiée et quitte.
-d dbname Spécifie le nom de la base KDC. Ne s'applique par au module de base LDAP
-s admin_server[:port] Spécifie le serveur d'administration à contacter
-m Avec kadmin.local, demande le mot de passe maître de la base au lieu de chercher un fichier stash
-e “enc:salt...” Définis la liste keysalt à utiliser pour toute nouvelle clé créée.
-O Force l'utilisation de l'ancienne authentification AUTH_GSSAPI
-N Empêche l'utilisation de l'ancienne authentification AUTH_GSSAPI
-x db_args Spécifie les arguments spécifique à la base. les options supportée pour le module de base LDAP sont:

-x host=hostname Spécifie le serveur LDAP à contacter
-x binddn=bind_dn DN de l'objet à utiliser par le serveur d'administration pour le bind ldap.
-x bindpwd=bind_password Mot de passe pour le binddn
-x debug=level Niveau de verbosité pour le client OpenLDAP.

Commandes

En utilisant le client distant, les commandes disponible peuvent être restreins en accord avec les privilèges dans kadm5.acl.

add_principal

Crée le principal spécifié, en demandant 2 fois le mot de passe. Si aucune stratégie de mot de passe n'est spécifiée, la stratégie nommée default est assignée au principal si elle existe. Cependant, créer une stratégie default ne va pas assigner automatiquement ce stratégie aux principaux déjà existant. Cette stratégie peut être supprimée avec l'option -clearpolicy

-expire expdate (chaîne getdate_time) Date d'expiration du principal
-pwexpire pwexpdate (chaîne getdate_time) Date d'expiration du mot de passe
-maxlife maxlife (chaîne getdate_time) Durée de vie de ticket max pour le principal
-maxrenewlife maxrenewlife (chaîne getdate_time) Durée de vie de renouvellement max des tickets
-kvno kvno Numéro de version de clé initial
-policy policy Stratégie de mot de passe utilisé par ce principal.
-clearpolicy Empêche l'assignation automatique d'une stratégie si non spécifiée par -policy
{-|+}allow_postdated Droit d'obtenir des tickets post-datés
{-|+}allow_forwardable Droit d'obtenir des tickets forwardable
{-|+}allow_renewable Droit d'obtenir des tickets renouvelable
{-|+}allow_proxiable Droit d'obtenir des tickets proxiable
{-|+}allow_dup_skey Droit d'effectuer une authentification user-to-user
{-|+}requires_preauth force le principal à ce pré-authentifier
{-|+}requires_hwauth Utiisation d'un hardware pour la pré-authentification
{-|+}ok_as_delegate flag okay as delegate dans les tickets fournis avec ce principal en tant que service.
{-|+}allow_svr Droit de délivrer des tickets de service pour ce principal
{-|+}allow_tgs_req Droit d'obtenir un TGS pour un ticket de service pour ce principal
{-|+}allow_tix Droit d'obtenir un ticket pour ce principal
{-|+}needchange Force le changement de mot de passe à la prochaine authentification
{-|+}password_changing_service Marque ce principal comme principal de service de changement de mot de passe
{-|+}ok_to_auth_as_delegate Droit d'obtenir des tickets forwardable à soi-même depuis des utilisateurs arbitraires
{-|+}no_auth_data_required Droit d'ajouter des données PAC ou AD-SIGNEDPATH
-randkey Définis la clé du principal à une valeur aléatoire
-nokey Crée un principal sans clé
-pw password Définis de mot de passe pour ce principal
-e enc:salt,... Utilise la liste de keysalt pour les clés de ce principal.
-x db_princ_args Options spécifique à la base:

-x dn=dn Spécifie l'objet LDAP qui va contenir le principal Kerberos à créer
-x linkdn=dn Spécifie l'objet LDAP pour lequel le nouveau principal Kerberos va pointer
-x containerdn=container_dn Spécifie le conteneur sous lequel le principal Kerberos est créé
-x tktpolicy=policy Associe une stratégie de ticket au principal Kerberos

Note

Les options containerdn et linkdn ne peuvent pas être spécifiés avec l'option dn. Si ces options ne sont pas spécifiées, les principaux sont créés sous le conteneur principal configurés dans le domaine. Ces options devraient pointer dans les sous-arborescences ou le conteneur principal configurés dans le domaine.

Exemple
kadmin: addprinc jennifer
WARNING: no policy specified for "jennifer@ATHENA.MIT.EDU";
defaulting to no policy.
Enter password for principal jennifer@ATHENA.MIT.EDU:
Re-enter password for principal jennifer@ATHENA.MIT.EDU:
Principal "jennifer@ATHENA.MIT.EDU" created.
kadmin:

modify_principal

Modifie le principal spécifié, en changeant les champs spécifiés. Les options de add_principal s'appliquent également à cette commande, excepté -randkey, -pw et -e. Cette commande nécessite les privilège modify. Alias: modprinc

-unlock Débloque un principal.

rename_principal

Renomme l'ancien principal avec le nouveau principal. Demande configuration sauf si -force est donné. Nécessite les privilèges add et delete. Alias: renprinc

delete_principal

Supprime le principal spécifié de la base. emande configuration sauf si -force est donné. Nécessite les privilèges delete. Alias: delprinc

change_password

Change le mot de passe du principal. Demande un nouveau mot de passe si -randkey ou -pw ne sont pas spécifiés. Nécessite les privilège changepw, ou que le principal qui lance ce programme est le même que le principal à changer. Aliar: cpw

-randkey Définis la clé du principal à une valeur aléatoire
-pw password Définis de mot de passe pour ce principal
-e enc:salt,... Utilise la liste de keysalt pour les clés de ce principal.
-keepold Conserve les clés existantes dans la base.

Exemple
kadmin: cpw systest
Enter password for principal systest@BLEEP.COM:
Re-enter password for principal systest@BLEEP.COM:
Password for systest@BLEEP.COM changed.
kadmin:

purgekeys

Purge les anciennes clé du principal. Si -keepkvno est spécifié, alors seul les clés avec des kvno inférieur sont purgés. Si -all est spécifié, purge toutes les clés. Nécessite le privilège modify

get_principal

Récupère les attributs du principal. L'option -terce affiche les champs en tant que chaîne séparés par des tabulations. Nécessite le privilège inquire, ou que le principal utilisant le programme soit le même que le principal cible. Alias: getprinc

Exemple
kadmin: getprinc tlyu/admin
Principal: tlyu/admin@BLEEP.COM
Expiration date: [never]
Last password change: Mon Aug 12 14:16:47 EDT 1996
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Mon Aug 12 14:16:47 EDT 1996 (bjaspan/admin@BLEEP.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, DES cbc mode with CRC-32, no salt
Key: vno 1, DES cbc mode with CRC-32, Version 4
Attributes:
Policy: [none]

kadmin: getprinc -terse systest
systest@BLEEP.COM 3 86400 604800 1
785926535 753241234 785900000
tlyu/admin@BLEEP.COM 786100034 0 0
kadmin:

list_principal

Récupère des noms de principal. L'expression est une expression glob qui peut contenir les caractères *, ? et []. Tous les noms de principaux qui matche l'expression sont affichés. Sans expression, liste tous les principauix. Si l'expression ne contient pas un caractère @, ce caractère est ajouté avec le domaine local à l'expression. Nécessite le privilège list. Alias: listprincs, get_principals, get_princs

Exemple
kadmin: listprincs test*
test3@SECURE-TEST.OV.COM
test2@SECURE-TEST.OV.COM
test1@SECURE-TEST.OV.COM
testuser@SECURE-TEST.OV.COM
kadmin:

get_strings

Affiche les attributs chaîne dans le principal. Nécessite le privilège inquire. Alias: getstr

set_strings

Définis un attribut chaîne dans le principal. Les attributs chaîne sont utilisés pour fournir une configuration par principal au KDC et certaine modules du KDC. Nécessite le privilège modify. Alias setstr. Les attributs suivants sont reconnus par le KDC:

session_enctypes Spécifie les types de chiffrement supportés pour les clés session quand le principal est authentifié en tant que serveur.

del_strings

Supprime un attribut chaîne du principal. Nécessite le privilège delete. Alias: delstr

add_policy

Ajoute une stratégie de mot de passe à la base. Nécessite le privilège add. Alias: addpol

-maxlife time (chaîne getdate_time) Définis la durée de vie max d'un mot de passe
-minlife time (chaîne getdate_time) Définis la durée de vie min d'un mot de passe
-minlength length Définis la longueur maximum d'un mot de passe
-minclasses number Définis le nombre minimum de classes de caractères requis dans un mot de passe. Les 5 classes sont: minuscule, majuscule, nombres, ponctuation et espaces blancs.
-history number Définis le nombre de clé à conserver pour un principal. Non supporté avec le module LDAP
-maxfailure maxnumber Définis le nombre d'échec d'authentification avant que le principal soit bloqué. 0 le désactive.
-failurecountinterval failuretime (chaîne getdate_time) Définis le temps permis entre les échecs d'authentification.
-lockoutduration lockouttime (chaîne getdate_time) Définis la durée pour lequel le principal est bloqué. 0 signifie que le compte est bloqué jusqu'à ce qu'un administrateur le débloque.
-allowedkeysalts Spécifie les tuples key/salt supportés pour les clés à long terme en définissant ou en changeant un mot de passe de principal. Les tuples doivent être séparés par une virgule. Pour enlever le tuple de la stratégie, utiliser "-"

Exemple
kadmin: add_policy -maxlife "2 days" -minlength 5 guests
kadmin:

modify_policy

Modifie la stratégié de mot de passe spécifiée. Les options sont les même que pour add_policy. Nécessite le privilège modify. Alias: modpol

delete_policy

Supprime la stratégie de mot de passe spécifiée. Demande confirmation. Échoue si la stratégie est utilisée par un principal. Nécessite le privilège delete. Alias: delpol

Exemple
kadmin: del_policy guests
Are you sure you want to delete the policy "guests"?
(yes/no): yes
kadmin:

get_policy

Affiche les valeurs de la stratégie spécifiées. -terse affiche les champs séparés par des tabulations. Nécessite le privilège inquire. Alias: getpol

Exemple
kadmin: get_policy admin
Policy: admin
Maximum password life: 180 days 00:00:00
Minimum password life: 00:00:00
Minimum password length: 6
Minimum number of password character classes: 2
Number of old keys kept: 5
Reference count: 17

kadmin: get_policy -terse admin
admin 15552000 0 6 2 5 17
kadmin:

list_policies

Liste des stratégie basée sur l'expression. Nécessite le privilège list. Alias: listpols, get_policies, getpols

Exemple
kadmin: listpols
test-pol
dict-only
once-a-min
test-pol-nopw

kadmin: listpols t*
test-pol
test-pol-nopw
kadmin:

ktadd

   Ajoute un principal, ou tous les principaux matchant l'expression de l'option glob, à chaque fichier keytab. Chaque clé de principal est randomisé dans le processus. Nécessite les privilèges inquire et changepw. pour utiliser -glob, nécessite le privilège list.

-k[eytab] keytab Utilise le fichier keytab spécifié
-e enc:salt,... Utilise la liste keysalt spécifiée
-q mode silencieux
-norandkey Ne randomise pas les clé. Ne peut pas être utilisé avec -e.

Exemple
kadmin: ktadd -k /tmp/foo-new-keytab host/foo.mit.edu
Entry for principal host/foo.mit.edu@ATHENA.MIT.EDU with kvno 3,
    encryption type aes256-cts-hmac-sha1-96 added to keytab
    FILE:/tmp/foo-new-keytab
kadmin:

ktremove

Supprime des entrées pour le principal spécifié du keytab. Ne nécessite aucune permission. Si all est spéficié, toutes les entrées pour le principal sont supprimés; si old est spécifié, toutes les entrée sauf le kvno le plus récent sont supprimés. Si kvno est spécifié, supprime les entrées avec ce kvno.

-k[eytab] keytab Utilise le fichier keytab spécifié
-q mode silencieux

Exemple
kadmin: ktremove kadmin/admin all
Entry for principal kadmin/admin with kvno 3 removed from keytab
FILE:/etc/krb5.keytab
kadmin:

lock

Bloque la base. Ne fonctionne qu'avec le module DB2

unlock

Réactive la base après un lock

list_requests

Liste les demandes kadmin disponible. Alias lr, ?

quit

Quitte le programme. Alias exit,q

25 juin 2014

kadmind

   Les noms de sections sont entre crochets, chaque section peut contenir 0 ou plusieurs relations, sous la forme:

  foo = bar

Sections

Le fichier kdc.conf peut contenir les sections suivantes:

[kdcdefaults] Valeurs par défaut pour le fonctionnement du KDC
[realms] Configuration et paramètres de base de données spécifique au domaine
[dbdefaults] Paramètres de base de données par défaut
[dbmodules] Paramètres par base de données
[logging] Contrôle les logs des services Kerberos

[kdcdefaults]

À une exception près, les relations dans cette section spécifient les valeur par défaut pour les variable du domaine à utiliser si la sous-section [realms] ne contient par de relation pour le tag.

host_based_services
kdc_ports
kdc_tcp_ports
no_host_referral
restrict_anonymous_to_tgt
kdc_max_dgram_reply_size Spécifie la taille de packet maximum que peut être envoyé en UDP. Défaut: 4096

[realms]

   Chaque tag dans cette section est le nom d'un domaine Kerberos. La valeur du tag est une sous-section où les relations définissent les paramètres du KDC pour ce domaine. L'exemple suivant montre comment définir un paramètre pour le domaine ATHENA.MIT.EDU:

[realms]
    ATHENA.MIT.EDU = {
        max_renewable_life = 7d 0h 0m 0s
    }

acl_file (chaîne). Emplacement du fichier d'acl que kadmind utilise pour déterminer quels principaux ont un accès privilégié à la base. Défaut: LOCALSTATEDIR/krb5kdc.acl
database_module (chaîne). Indique le nom de la section de configuration sous [dbmodules] pour les paramètres spécifiques à la base utilisé par la librairie. Défaut: le nom du domaine.
database_name (chaîne, déprécié) Spécifie l'emplacement de la base Kerberos pour ce domaine, si DB2 est utilisé et que la section de configuration [dbmodules] ne spécifie par un nom de base. Défaut: LOCASTATEDIR/krb5kdc/principal
default_principal_expiration (chaîne, temps absolu). Spécifie le temps d'expiration par défaut des principaux créés dans ce domaine. Défaut: 0 qui signifie aucune expiration.
default_principal_flags (Chaîne) Spécifie les attributs par défaut des principaux crées dans ce domaine. Le format est une liste de flags séparés par une ",", avec un "+" avant chaque flag à ajouter, et "-" à enlever. Défaut: les flag suivant sont permis postdateable, forwardable, tgt-based, renewable, proxiable, dup-skey, allow-tickets, et service. Les flags possibles sont:

allow-tickets Le KDC va fournir de tickets pour ce principal
dup-skey permet au principal d'obtenir une clé de session pour un autre utilisateur.
forwardable Permet au principal d'obtenir des tickets forwardable
hwauth Le principal doit utiliser un périphérique hardware pour la pré-authentification
no-auth-data-required Empêche les données PAC et AD-SIGNEDPATH d'être ajoutés au ticket de service pour le principal
ok-as-delegate Indique au client que les accréditifs peuvent et devraient être délégués en s'authentifiant auprès du service
ok-to-auth-as-delegate Permet au principal d'utiliser des tickets S4USelf
postdateable Permet au principal d'obtenir des tickets post-datés.
preauth Le principal doit de pré-authentifier auprès du KDC avant de recevoir un ticket. Pour un principal de service, cela signifie que les tickets de service pour ce principal seront uniquement fournis aux clients avec un TGT qui a le bit preauthenticated mis.
proxiable Permet au principal d'obtenir des tickets proxy
pwchange Force le changement de mot de passe pour ce principal
pwservice Marque ce principal comme service de changement de mot de passe. Devrait être utilisé uniquement dans des cas spéciaux, par exemple, si le mot de passe de l'utilisateur a expiré, alors l'utilisateur doit obtient des tickets pour ce principal sans passer par une authentification normal par mot de passe pour pouvoir changer le mot de passe.
renewable Permet au principal d'obtenir des tickets renouvelable.
service Permet au KDC de fournir des tickets de service pour ce principal
tgt-based Permet au principal d'obtenir des tickets basés sur un TGT au lieu de répéter le process d'authentification utilisé pour obtenir ce TGT.

dict_file (chaîne) Emplacement du fichier dictionnaire contenant les chaînes non permises pour un mot de passe.
host_based_services (liste séparée par des espaces ou des virgules) Liste des services qui vont obtenir un traitement des référants basés sur l'hôte même si le principal du serveur n'est pas marqué comme basé sur l'hôte par le client.
iprop_enable (bool) Spécifie si la propagation incrémentale de la base est permise. Défaut: false.
iprop_master_ulogsize (entier) Spécifie le nombre max d'entrées de log à retenir pour la propagation incrémentale. max: 2500, défaut: 1000
iprop_slave_poll (chaîne de temps delta) Spécifie la fréquence des mises à jours les esclaves auprès du maître. Défaut: 2m (minutes)
iprop_port (numéro de port) Spécifie le numéro de port à utiliser pour la propagation incrémentale. Requis dans les configuration des maître et esclaves.
iprop_resync_timeout (chaîne de temps delta). Spécifie le temps d'attente pour une propagation complète. Optionnel et est utilisé par les esclaves uniquement. Défaut: 5m.
iprop_logfile (Nom de fichier) Spécifie où se situe le fichier de log des mises à jours. Par défaut, utilise database_name.ulog
kadmind_port (numéro de port) Port d'écoute du service kadmind. Défaut: 749
key_stash_file (chaîne) Spécifie l'emplacement du fichier stash. Défaut: LOCALSTATEDIR/krb5kdc/.k5.REALM.
kdc_ports (liste séparée par des espaces ou des virgules) Liste de ports d'écoute du serveur Kerberos pour les requêtes UDP. Défaut: 88,750
kdc_tcp_ports (liste séparée par des espaces ou des virgules) Liste de ports d'écoute du serveur Kerberos pour les requêtes TCP (Défaut: 88).
master_key_name (chaîne) Spécifie le nom du principal associé avec la clé maître. Défaut: K/M
master_key_type (Chaîne de type de clé) Spécifie le type de clé maître. Défaut: aes256-cts-hmac-sha1-96.
max_life (chaîne de temps) Spécifie le temps maximum pour lequel un ticket peut être valide dans le domaine. Défaut: 24heures.
max_renewable_life (chaîne de temps) Spécifie le temps maximum durant lequel un ticket valide peut être renouvelé dans ce domaine. Défaut: 0
no_host_referral (liste séparée par des espaces ou des virgules) Liste
des_crc_session_supported (bool) À true, le KDC assume que les principaux de service supportent des-cbc-crc pour les type de clé de session. Défaut: true.
reject_bad_transit (bool) À true, le KDC vérifie la liste des domaines de transit pour les tickets inter-domaines avec le chemin de transit calculé depuis les noms des domaines et la section capaths de son fichier krb5.conf; si le chemin dans le ticket contient un domaine qui n'est pas dans le chemin calculé, le ticket ne sera pas délivré. Si cette valeur est à false, de tels tickets seront toujours émis. si le flag disable-transited-check est mis dans la requête entrante, cette vérification n'est pas effectuée. L'option reject_bad_transit force de telles requête à être toujours rejetées. Défaut: true
restrict_anonymous_to_tgt (bool) À true, le KDC rejète les demandes de tickets pour des principaux anonymes au principaux de service autre que le domaine du TGS. Cette option permet les PKINIT anonymes pour les tickets FAST sans autoriser l'authentification anonyme aux services. Défaut: false.
supported_enctypes (liste de key:salt) Spécifie les combinaisons key/salt par défaut des principaux pour ce domaine. Tout principal créé via kadmin aura des clé de ce type. Défaut: aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal arcfour-hmac-md5:normal.

[dbdefaults]

Cette section spécifie les valeur par défaut pour certains paramètres de base, à utiliser si la sous-section dbmodules ne contient pas de relation pour ce tag.

ldap_kerberos_container_dn
ldap_kdc_dn
ldap_kadmind_dn
ldap_service_password_file
ldap_servers
ldap_conns_per_server

[dbmodules]

   Cette section contient des paramètres utilisés par les bases du KDC et les modules. Chaque tag dans cette section est le nom d'un domaine Kerberos ou un nom de section spécifié par le paramètre database_module du domaine. L'exemple suivant montre comment définir un paramètre de base pour le domaine ATHENA.MIT.EDU:

[dbmodules]
    ATHENA.MIT.EDU = {
        disable_last_success = true
    }

database_name Ce tag spécifique à db2 indique l'emplacement de la base dans le système de fichier. Défaut: LOCALSTATEDIR/krb5kdc/principal
db_library Indique le nom du module de base à charger. peut être db2 ou kldap
disable_last_success À true, supprime les mises à jours KDC du champ "last successful authentication" des entrées de principal nécessitant une pré-authentification. Positionner ce flag peut améliorer les performances. (Les entrées de principal qui ne nécessitent par de pré-authentification ne mettent jamais ce champ)
disable_lockout À true, supprime les champs "last failed authentication" et "failed password attempts" des entrées de principal nécessitant une pré-authentification. peut améliorer les performances.
ldap_conns_per_server Indique le nombre de connexios à maintenir par serveur LDAP
ldap_kadmind_dn Indique le bind DN par défaut pour le service kadmind. Cet objet devrait avoir les droits de lire et écrire dans la base Kerberos dans la base LDAP.
ldap_kdc_dn Indique le bind DN par défaut pour le service krb5kdc. Cet objet devrait avoir les droits de lire dans la base Kerberos dans la base LDAP et d'écrire les données sauf si disable_lockout et disable_last_success sont à true.
ldap_kerberos_container_dn Indique le DN de l'objet conteneur où les objets de domaine sont localisés.
ldap_servers Liste les serveur LDAP à contacter.
ldap_service_password_file Indique le fichier contenant les mots de passe stashed (créés par kdb5_ldap_util stashsrvpw) pour les objets ldap_kadmind_dn et ldap_kdc_dn.
db_module_dir contrôle l'emplacement les modules de base de données. devrait être un chemin absolu. Ce tag pour être spécifié directement dans la section dbmodules.

[logging]

   Cette section indique comment krb5kdc et kadmind effectuent les logs. Les clés dans cette section sont les noms des services, qui peut être un parmi:

admin_server Spécifie comment kadmind effectue les logs
kdc Spécifie comment krb5kdc effectue les logs
default Spécifie comment les 2 services effectuent les logs.

   Les valeurs sont sous la forme suivante:

FILE=filename ou FILE:filename Log les messages dans le fichier spécifié. si la 1ère forme est utilisée, le fichier est écrasé.
STDERR Log les message sur stderr
CONSOLE Log les messages dans la console
DEVICE=‹devicename› Log les messages dans le périphérique spécifié
SYSLOG[:severity[:facility]] Los les messages dans syslog

Dans l'exemple suivant, les messages du KDC vont dans la console et dans syslog. Les messages de kadmind vont dans /var/adm/kadmin.log et dans le périphérique /dev/tty04
[logging]
    kdc = CONSOLE
    kdc = SYSLOG:INFO:DAEMON
    admin_server = FILE:/var/adm/kadmin.log
    admin_server = DEVICE=/dev/tty04

[otp]

   Chaque sous-section de [opt] est le nom du type de token OTP. Les tags dans la sous-section définis la configuration requise pour forwarder une requête OTP au serveur radius. Pour chaque type de token, les tags suivants peuvent être spécifiés:

server Serveur où envoyer les requêtes RADIUS. Peut être un nom d'hôte et un port optionnel, une adresse IP ou un socket UNIX. Défaut LOCALSTATEDIR/krb5kdc/‹name›.socket
secret Indique le fichier qui peut être relatif à LOCALSTATEDIR/krb5kdc contenant le secret utilisé pour chiffré les packets RADIUS. Le secret devrait apparaître sur la première ligne du fichier. Si server indique un socket unix, ce tag est optionnel.
timeout Entier qui spécifie le temps en secondes durant lequel de KDC devrait attendre pour contacter le serveur RADIUS. Ce tag est le temps total entre toutes les tentatives et devrait être inférieur au temps de validité de l'OTP. Défaut: 5 secondes
retries Nombre de re-tentatives auprès du serveur RADIUS. Défaut: 3
strip_realm À true, le principal sans le domaine sera passé au serveur RADIUS, sinon le domaine est inclus. Défaut: true.

Dans l'exemple suivant, les requêtes sont envoyées à un serveur distant via UDP:
[otp]
    MyRemoteTokenType = {
        server = radius.mydomain.com:1812
        secret = SEmfiajf42$
        timeout = 15
        retries = 5
        strip_realm = true
    }

Un token par défaut implicite nommé DEFAULT est définis pour les type de token non spécifiés. Sa configuration est décrite ci-dessous.
[otp]
    DEFAULT = {
        strip_realm = false
    }

Options PKINIT

   Cet valeurs peuvent être spécifiées dans [kdcdefaults] comme valeur par défaut, ou dans une sous-section de [realms]. Noter qu'une valeur spécifique à un domaine remplace, n'ajoute pas, une spécification kdcdefaults. L'ordre de recherche est:

1. sous-section de [realms]:
    [realms]
        EXAMPLE.COM = {
            pkinit_anchors = FILE:/usr/local/example.com.crt
        }

2. Valeur générique dans la section [kdcdefaults]:
    [kdcdefaults]
        pkinit_anchors = DIR:/usr/local/generic_trusted_cas/

pkinit_anchors Spécifie l'emplacement des certificats de confiance racine que le client utilise pour signer les certificats KDC. Peut être spécifié plusieurs fois.
pkinit_dh_min_bits Taille de la clé Diffie-Hellman que le client va tenter d'utiliser. les valeur acceptable sont 1024, 2048 (défaut), et 4096.
pkinit_allow_upn Spécifie que le KDC est prêt à accepter les certificats client avec un SAN UPN. Défaut: false. Sans cette option, le KDC accepte uniquement les certificats avec id-pkinit-san comme définis dans la rfc4556. Il n'y a actuellement aucune option pour désactiver la vérification SAN dans le KDC.
pkinit_eku_checking spécifie quelle valeur d'Extended Key Usage le KDC est prêt à accepter dans les certificats client. Les valeurs reconnues sont:

kpClientAuth C'est la valeur par défaut et spécifie que les certificats client doivent avoir le id-pkinit-KDKdc EKU comme définis dans la rfc4556.
scLogin Les certificats client avec id-ms-sc-logon seront acceptés
none Les certificats client ne seront pas vérifiés pour un EKU acceptable.

pkinit_identity Spécifie l'emplacement des information d'identité X.509 du KDC. Cette option est requise si pkinit est supportée par le KDC
pkinit_kdc_ocsp Spécifie l'emplacement de l'OCSP du KDC
pkinit_mapping_file Spécifie le nom du fichier de mappage d'acl pkinit. Ce fichier map les principaux aux certificats qu'ils utilisent.
pkinit_pool Spécifie l'emplacement des certificats intermédiaires qui peuvent être utilisés par le KDC pour compléter le chaîne. Peut être spécifiée plusieurs fois
pkinit_revoke Spécifie l'emplacement de la CRL. Peut être spécifié plusieurs fois
pkinit_require_crl_checking Spécifie que la vérification de révocation est requise.

Types de chiffrement

des-cbc-crc DES cbc mode avec CRC-32 (weak)
des-cbc-md4 DES cbc mode avec RSA-MD4 (weak)
des-cbc-md5 DES cbc mode avec RSA-MD5 (weak)
des-cbc-raw DES cbc mode raw (weak)
des3-cbc-raw Triple DES cbc mode raw (weak)
des3-cbc-sha1 des3-hmac-sha1 des3-cbc-sha1-kd Triple DES cbc mode avec HMAC/sha1
des-hmac-sha1 DES avec HMAC/sha1 (weak)
aes256-cts-hmac-sha1-96 aes256-cts AES-256 CTS mode avec 96-bit SHA-1 HMAC
aes128-cts-hmac-sha1-96 aes128-cts AES-128 CTS mode avec 96-bit SHA-1 HMAC
arcfour-hmac rc4-hmac arcfour-hmac-md5 RC4 avec HMAC/MD5
arcfour-hmac-exp rc4-hmac-exp arcfour-hmac-md5-exp Exportable RC4 avec HMAC/MD5 (weak)
camellia256-cts-cmac camellia256-cts Camellia-256 CTS mode avec CMAC
camellia128-cts-cmac camellia128-cts Camellia-128 CTS mode avec CMAC
des Fammille DES: des-cbc-crc, des-cbc-md5, and des-cbc-md4 (weak)
des3 Famille triple DES: des3-cbc-sha1
aes Famille AES: aes256-cts-hmac-sha1-96 and aes128-cts-hmac-sha1-96
rc4 Famille RC4: arcfour-hmac
camellia Famille Camellia: camellia256-cts-cmac and camellia128-cts-cmac

La chaîne DEFAULT peut être utilisé pour les type de jeu par défaut pour les variables en question. Les types ou familles peuvent être supprimées de la liste courante en les préfixant avec un "-". Les types ou familles peuvent être préfixés avec un "+" pour la symétrie; il a la même signification que simplement lister le type ou la famille. Par exemple, DEFAULT -des sera le jeu de chiffrement par défaut avec les types DES supprimés, et des3 DEFAULT sera le jeu de chiffrement par défaut avec triple DES supprimé.

Alors que aes128-cts et aes256-cts sont supportés pour toutes les opérations Kerberos, ils ne sont pas supportés par d'anciennes versions de l'implémentation GSS-API.

Listes de keysalt

   Les clés Kerberos pour les utilisateurs sont généralement dérivés des mots de passe. Les commandes et les paramètres de configuration Kerberos qui affectent la génération de clés prennent la liste des paires enctype-salttype, appelés "liste keysalt". Chaque paire keysalt est un nom de type de chiffrement suivi par un nom de salttype, dans le format enc:salt. Par exemple:

  kadmin -e aes256-cts:normal,aes128-cts:normal

  va lancer kadmin pour qu'il génère par défaut des clé dérivés pour les types de chiffrement aes256-cts et aes128-cts, en utilisant un salt normal.

   Pour s'assurer que les gens qui utilisent le même mot de passe n'aient pas la même clé, Kerberos 5 incorpore plus d'informations dans la clé en utilisant un salt. Les types de salt supportés sont les suivant:

normal Défaut pour Kerberos v5
v4 Utilisé uniquement par Kerberos v4 (pas de salt)
norealm Idem au défaut, sans utiliser d'information de domaine.
onlyrealm Utilise seulement les information de domaine comme salt
afs3 AFS version 3, utilisé uniquement pour la compatibilité avec Kerberos v4
special Génère un salt aléatoire.

Exemple

Exemple de fichier de configuration kdc.conf
[kdcdefaults]
    kdc_ports = 88

[realms]
    ATHENA.MIT.EDU = {
        kadmind_port = 749
        max_life = 12h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal des-cbc-crc:v4
        database_module = openldap_ldapconf
    }

[logging]
    kdc = FILE:/usr/local/var/krb5kdc/kdc.log
    admin_server = FILE:/usr/local/var/krb5kdc/kadmin.log

[dbdefaults]
    ldap_kerberos_container_dn = cn=krbcontainer,dc=mit,dc=edu

[dbmodules]
    openldap_ldapconf = {
        db_library = kldap
        disable_last_success = true
        ldap_kdc_dn = "cn=krbadmin,dc=mit,dc=edu"
        ldap_kadmind_dn = "cn=krbadmin,dc=mit,dc=edu"
        ldap_service_password_file = /etc/kerberos/service.keyfile
        ldap_servers = ldaps://kerberos.mit.edu
        ldap_conns_per_server = 5
    }

30 juin 2014

kdestroy

Supprimer les caches d'accréditifs

kdestroy est un utilitaire pour supprimer des tickets d'autorisation Kerberos actifs en supprimant les caches d'accréditifs. Si le cache n'est pas spécifié, le cache par défaut est supprimé.

OPTIONS

-A Supprime tous les caches dans la collection, si une collection de cache est disponible
-q mode silencieux
-c cache_name Supprime le cache spécifié

Notes

Le cache d'accréditifs par défaut peut varier entre les systèmes. Si la variable d'environnement KRB5CCNAME est définie, sa valeur est utilisée comme cache de tickets par défaut.

Il est recommandé de placer la commande kdestroy dans le fichier .logout pour supprimer tous les tickets à la deconnexion.

Variable d'environnement

KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5

01 juillet 2014

Kerberos - Formats

Formats et données diverses

Format de temps supportés

   Le format time_duration est utilisé pour exprimé une durée de temp dans les fichiers de configuration Kerberos est les commandes utilisateur. Les formats permis sont:

Format____Exemple____valeure
h:m[:s]___36:00______36 hours
NdNhNmNs__8h30s______8 hours 30 seconds
N_________3600_______1 hour

   Note: l'interval de temps ne devrait pas excéder 2147483647 secondes.

   Le format getdate_time spécifie une date. Les formats permis sont:

Date___________mm/dd/yy______07/27/12
_______________month dd, yyyy_Jul 27, 2012
_______________yyyy-mm-dd____2012-07-27
Absolute time__HH:mm[:ss]pp__08:30 PM
_______________hh:mm[:ss]____20:30
Relative time__N tt__________30 sec
Time zone______Z_____________EST
_______________z_____________-0400

   Le format absolute_time, rarement utilisé peut être noté selon un des formats suivants:

Format__________________Example_______________Value
yyyymmddhhmmss__________20141231235900________One minute before 2015
yyyy.mm.dd.hh.mm.ss_____2014.12.31.23.59.00
yymmddhhmmss____________141231235900
yy.mm.dd.hh.mm.ss_______14.12.31.23.59.00
dd-month-yyyy:hh:mm:ss__31-Dec-2014:23:59:00
hh:mm:ss________________20:00:00______________8 o’clock in the evening

Types de chiffrement

   Kerberos peut utiliser divers algorithmes de chiffrement pour protéger des données. Un type de chiffrement Kerberos est une combinaison spécifique d'un algorithme de chiffrement avec un algorithme d'intégrité pour fournir la confidentialité et l'intégrité des données. Les clients effectuent 2 types de demandes (KDC-REQ) au KDC: AS-REQ et TGS-REQ. Le client utilise l'AS-REQ pour obtenir des tickets initiaux ( appelés TGT ), et utilisent TGS-REQ pour obtenir des tickets de service. Le KDC utilise 3 types de clé différentes en fournissant un ticket au client.

La clé long-terme du service: Le KDC l'utilise pour chiffrer le ticket de service actuel. Le KDC utilise la première clé long-terme dans le kvno le plus récent.
La clé de session: Le KDC choisis aléatoirement cette clé et place une copie dans le ticket et une autre copie dans la partie chiffrée de la réponse.
La clé de chiffrement de réponse: Le KDC l'utilise pour chiffrer la réponse qu'il envoie au client. Pour les réponses AS, c'est une clé long-terme du client. Pour les réponses TGS, c'est soit la clé de session du ticket authentifiant, ou une clé de sous-session.

   Chaque type de demande permet au client d'envoyer une liste de type de chiffrement qu'il accepte. Pour AS-REQ, cette liste affecte la sélection de la clé de session et la clé de chiffrement de la réponse. Pour TGS-REQ, cette liste affecte uniquement la sélection de la clé de session.

   Compatibilité des types de chiffrement:
   des-cbc-crc_____________weak____all_____›=2000
   des-cbc-md5_____________weak____all__ __›=2000
   arcfour-hmac____________ _______›=1.3___›=2000
   aes128-cts-hmac-sha1-96_ _______›=1.3___›=Vista
   camellia128-cts-cmac____ _______›=1.9___none

Variables d'environnement

KRB5_CONFIG Spécifie l'emplacement de krb5.conf
KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf
KRB5_KTNAME Fichier keytab par défaut
KRB5_CLIENT_KTNAME Fichier keytab client par défaut
KRB5CCNAME fichier du cache d'accréditifs par défaut, sous la forme type:residual
KRB5RCACHETYPE Type de cache replay par défaut. (défaut: dfl) none pour le désactiver
KRB5RCACHEDIR Répertoire du cache replay par défaut.
KPROP_PORT port kprop à utiliser. Défaut: 754
KRB5_TRACE Fichier pour les logs.

18 juin 2014

Kerberos - Installer les KDC

Introduction à la configuration initiale des KDC

En implémentant Kerberos dans un environnement de production, il est préférable d'avoir plusieurs KDC esclave avec un KDC maître pour s'assurer de la disponibilité continue des service kerberisés. Chaque KDC contient une copie de la base de donnée Kerberos. Le KDC maître contient la copie modifiable de la base, qui est répliquée au esclaves à intervalle régulier. Tous les changements de base sont faites sur le maître. Les esclave fournissent les services TGS, mais pas d'administration de la base, quand le KDC maître n'est pas disponible. Le MIT recommande d'installer tous les KDC pour être en mesure de fonctionner soit en tant que maître ou un esclave. Celà permet de facilement basculer un esclave en maître si nécessaire.

Attention

Le système Kerberos s'appuyent du la disponibilité des informations de temps correcte, assurez vous que le maître et les esclaves ont une horloge synchronisée correctement. Il est préférable d'installer les KDC sur du hardware dédié et sécurisé avec un accès limité.

Installer et configurer le KDC maître

Dans ce document, nous utilisons les noms suivants:
kerberos.mit.edu____-_master KDC
kerberos-1.mit.edu__-_slave KDC
ATHENA.MIT.EDU______-_realm name
.k5.ATHENA.MIT.EDU__-_stash file
admin/admin_________-_admin principal

Éditer les fichiers de configuration du KDC

Modifier les fichiers de configuration, krb5.conf et kdc.conf, pour refléter les informations telles que le mappage domain-realm et les noms des serveurs kerberos. Beaucoup de tags dans la configuration ont des valeurs par défaut qui sont adéquat à la plupart des sites. Les variables KRB5_CONFIG et KRB5_KDC_PROFILE permettent de spécifier les fichiers altérnatifs:

export KRB5_CONFIG=/yourdir/krb5.conf
export KRB5_KDC_PROFILE=/yourdir/kdc.conf

krb5.conf

   Si vous n'utilisez pas les enregistrements DNS TXT, vous devez spécifier le default_realm dans la section [libdefault]. Si vous n'utilisez par les enregistrements DNS SRV, vous devez inclure le tag kdc pour chaque realm dans la section [realms]. Pour communiquer avec le serveur kadmin dans chaque realm, le tag admin_server doit être définis dans la section [realms].

Exemple de fichier krb5.conf
[libdefaults]
    default_realm = ATHENA.MIT.EDU

[realms]
    ATHENA.MIT.EDU = {
        kdc = kerberos.mit.edu
        kdc = kerberos-1.mit.edu
        admin_server = kerberos.mit.edu
    }

kdc.conf

   Ce fichier peut être utilisé pour contrôler les ports d'écoute du KDC en de kadmind, et les paramètres par défaut spécifique au realm, le type de base et son emplacement et le logging.

Exemple de fichier kdc.conf
[kdcdefaults]
    kdc_ports = 88,750

[realms]
    ATHENA.MIT.EDU = {
        kadmind_port = 749
        max_life = 12h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = aes256-cts
        supported_enctypes = aes256-cts:normal aes128-cts:normal
        # If the default location does not suit your setup,
        # explicitly configure the following values:
        #    database_name = /var/krb5kdc/principal
        #    key_stash_file = /var/krb5kdc/.k5.ATHENA.MIT.EDU
        #    acl_file = /var/krb5kdc/kadm5.acl
    }

[logging]
    # By default, the KDC and kadmind will log output using
    # syslog. You can instead send log output to files like this:
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmin.log
    default = FILE:/var/log/krb5lib.log

   Remplacer ATHENA.MIT.EDU et kerberos.mit.edu avec le nom de votre domaine et serveur Kerberos, respectivement.

  Note: vous devez avoir les droits d'écriture sur les répertoires cibles ( et doivent exister ) utilisés par database_name, key_stash_file, et acl_file.

Créer la base KDC

   Il faut utiliser la commande kdb5_util sur le KDC maître pour créer la base Kerberos et le fichier optionnel stash.

  Note: Si vous choisissez de ne pas installer un fichier stash, le KDC va vous demander la clé maître chaque fois qu'il démarre.

   kdb5_util va vous demander le mot de passe maître pour la base Kerberos. L'exemple suivant montre comment créer une base Kerberos et le fichier stash sur le KDC maître.

shell% kdb5_util create -r ATHENA.MIT.EDU -s

Initializing database '/usr/local/var/krb5kdc/principal' for realm 'ATHENA.MIT.EDU',
master key name 'K/M@ATHENA.MIT.EDU'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: ‹= Type the master password.
Re-enter KDC database master key to verify: ‹= Type it again.
shell%

   Cela va créer 5 fichiers dans LOCALSTATEDIR/krb5kdc ( ou l'emplacement spécifié dans kdc.conf ):

- 2 fichiers de base de données, principal et principal.ok
- Le fichier de base de données administrative, principal.kadm5
- Le fichier de lock de la base administrative, principal.kadm5.lock
- Le fichier stash, dans cet exemple .k5.ATHENA.MIT.EDU. utiliser l'option -s pour ne pas générer ce fichier.

Ajouter les administrateurs au fichier d'ACL

Ensuite, vous devez créer un fichier d'acl et y placer le principal Kerberos d'au moins un administrateur. Ce fichier est utilisé par kadmind pour contrôler quel principaux peuvent voir et effectuer des modifications privilégiées dans les fichiers de base Kerberos. Le nom du fichier d'acl est déterminé par la variable acl_file dans kdc.conf ( défaut: LOCALSTATEDIR/krb5kdc/kadm5.acl )

Ajouter les administrateurs à la base kerberos

   Vous devez ajouter les principaux administratifs à la base de données Kerberos. Vous devez ajouter au moins un principal pour permettre la communication entre kadmind et kadmin sur le réseaux. Pour cela, utiliser l'utilitaire kadmin.local sur le KDC maître. Il est conçus pour être lancé sur un KDC maître sans utiliser d'authentification Kerberos. Vous devez avoir un accès en lecture/écriture à la base Kerberos.

   Les principaux administratifs que vous créez devraient être ceux ajoutés dans le fichier d'acl.

Dans l'exemple suivant, le principal administratif admin/admin est créé:
shell% kadmin.local

kadmin.local: addprinc admin/admin@ATHENA.MIT.EDU

WARNING: no policy specified for "admin/admin@ATHENA.MIT.EDU";
assigning "default".
Enter password for principal admin/admin@ATHENA.MIT.EDU: ‹= Enter a password.
Re-enter password for principal admin/admin@ATHENA.MIT.EDU: ‹= Type it again.
Principal "admin/admin@ATHENA.MIT.EDU" created.
kadmin.local:

Démarrer le service Kerberos sur le KDC maître

À ce point, vous êtes prêt à démarrer le KDC (krb5kdc) et les services administratifs sur le KDC maître:
shell% krb5kdc
shell% kadmind

Chaque service va se forker en tâche de fond.

Vous pouvez vérifier qu'ils sont lancés correctement en vérifiant les messages de démarrage dans les emplacement le logging spécifiés dans krb5.conf:
shell% tail /var/log/krb5kdc.log
Dec 02 12:35:47 beeblebrox krb5kdc[3187](info): commencing operation
shell% tail /var/log/kadmin.log
Dec 02 12:35:52 beeblebrox kadmind[3189](info): starting

En vérification additionnelle, vérifier si kinit réussit avec les principaux administratifs:
shell% kinit admin/admin@ATHENA.MIT.EDU

Installer les KDC esclave

Maintenant vous être prêt à configurer les KDC esclaves.

Note: en assumant que vous paramètrez le KDC de manière à facilement basculer le maître avec un des esclaves, vous devriez effectuer chaque étape sur de maître sur les esclaves, sauf les ces instructions spécifient le contraire.

Créer les keytabs pour les KDC esclave

   Chaque KDC a besoin d'un clé host dans la base Kerberos. Ces clés sont utilisée pour l'authentification mutuelle lors de la propagation des dump de la base de donnée depuis le maître.

   Sur le KDC maître, se connecter à l'interface administrative et créer le principal de l'hôte pour chaque service host des KDC. Par exemple, si le maître s'appel kerberos.mit.edu, et l'esclave s'appel kerberos-1.mit.edu:

shell% kadmin
kadmin: addprinc -randkey host/kerberos.mit.edu
NOTICE: no policy specified for "host/kerberos.mit.edu@ATHENA.MIT.EDU"; assigning "default"
Principal "host/kerberos.mit.edu@ATHENA.MIT.EDU" created.

kadmin: addprinc -randkey host/kerberos-1.mit.edu
NOTICE: no policy specified for "host/kerberos-1.mit.edu@ATHENA.MIT.EDU"; assigning "default"
Principal "host/kerberos-1.mit.edu@ATHENA.MIT.EDU" created.

   Il n'est pas nécessaire d'avoir le maître dans la base Kerberos, mais peut être nécessaire si vous souhaitez basculer le maître en esclave. Ensuite, extraire chaque clé host pour tous les KDC participants et les stocker dans chaque fichier keytab de l'hôte. Idéalement, vous devriez extraire chaque keytab localement dans son propre KDC. Si cela n'est pas faisable, vous devriez utiliser une session chiffrée pour les envoyer sur le réseau. Pour extraire un keytab sur un serveur esclave:

kadmin: ktadd host/kerberos-1.mit.edu
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type des3-cbc-sha1 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
    type arcfour-hmac added to keytab FILE:/etc/krb5.keytab.

Configurer les KDC esclave

   La propagation de la base de données copie le contenu de la base du maître, mais ne propage pas les fichiers de configuration, les fichiers stash, ou le fichier d'acl. Les fichiers suivants doivent être copiés à la main pour chaque esclave:

- krb5.conf
- kdc.conf
- kadm5.acl
- master key stash file

   Déplacer les fichiers copiés dans leur répertoires appropriés, exactement comme sur le KDC maître. La base est propagée du maître vers les esclaves via le service kpropd. Vous devez explicitement spécifier les principaux qui sont autorisé à fournir les mises à jours Kerberos sur les esclaves avec une nouvelle base de données. Créer un fichier nommé kpropd.acl dans le répertoire d'état KDC contenant les principaux host pour chaque KDC:

host/kerberos.mit.edu@ATHENA.MIT.EDU
host/kerberos-1.mit.edu@ATHENA.MIT.EDU

   Note: si vous souhaitez que le maître et l'esclave puis être inversés, listez les principaux hôtes depuis tous les KDC participants dans les fichiers kpropd.acl dans tous les KDC. Sinon, vous avez seulement besoin de lister le principal de l'hôte du KDC maître dans kpropd.acl des KDC esclaves.

Ensuite, ajoutez la ligne suivante dans /etc/inetd.conf dans chaque KDC:
krb5_prop 754/tcp # Kerberos slave propagation

   Redémarrez inetd. Alternativement, démarrer kpropd comme service standalone. Cela est nécessaire quand la propagation incrémental est activé.

   Maintenant que le KDC est capable d'accepter la propagation de la base, vous avez besoin de propager la base depuis le maître. Note: Ne pas démarrer le KDC esclave avant d'avoir une copie du maître.

Propager la base à chaque esclave

Premièrement, créer un fichier dump de la base sur le maître:
shell% kdb5_util dump /usr/local/var/krb5kdc/slave_datatrans
Puis, propager manuellement la base à chaque esclave:
shell% kprop -f /usr/local/var/krb5kdc/slave_datatrans kerberos-1.mit.edu
Database propagation to kerberos-1.mit.edu: SUCCEEDED

   Vous aurez besoin d'un script pour dumper et propager la base. voici un exemple de script shell. Rappelez vous que vous avez besoin de remplacer /usr/local/var/krb5kdc avec le nom du répertoire d'état KDC.

#!/bin/sh

kdclist = "kerberos-1.mit.edu kerberos-2.mit.edu"

kdb5_util dump /usr/local/var/krb5kdc/slave_datatrans

for kdc in $kdclist
do
    kprop -f /usr/local/var/krb5kdc/slave_datatrans $kdc
done

Vous avez besoin du définir un cron pour lancer ce script à intervalle régulier. Maintenant que l'esclave a une copie de la base Kerberos, vous pouvez démarrer krb5kdc:
shell% krb5kdc

Erreurs de propagation

kprop: No route to host while connecting to server
Assurez vous que le nom d'hôte de l'esclave est correct et que les firewalls entre le maître et l'esclave autorisent le port 754.
kprop: Connection refused while connecting to server
Si l'esclave tente de lancer kpropd via inetd, assurez vous que inetd est configuré pour accepter les connections krb5_prop. inetd a besoin de relire sa configuration pour qu'un changement soit pris en compte.
kprop: Server rejected authentication (during sendauth exchange) while authenticating to server
assurez vous que:

1. L'heure est synchonisée
2. Le fichier stash du maître a été copié sur l'esclave à l'emplacement attendu
3. L'esclave a un fichier keytab contenant un principal host pour le nom d'hôte de l'esclave.

Ajouter des principaux à la base

Une fois les KDC définis et fonctionnels, vous êtes prêt à utiliser kadmin pour charger les principaux pour vos utilisateurs, hôtes, et autres services dans la base kerberos. Vous pouvez occasionnellement utiliser un des esclaves comme maître. Cela peut se produire si vous mettez à jour le maître, ou si le maître crash.

Basculer de maître et d'esclave

Si le KDC maître fonctionne, effectuez les étapes suivantes sur l'ancien maître:

1. Tuer kadmind
2. Désactiver le job cron qui propage la base
3. Lancer le script de propagation manuellement, pour s'assurer que tous les esclaves ont la dernière copie de la base.

Sur le nouveau maître:

1. Démarrer Kadmind
2. Définir un cron pour propager la base
3. Bascules les CNAME de l'ancien vers le nouveau maître. Si vous ne pouvez pas le faire, vous aurez besoin de changer le fichier krb5.conf sun chaque client dans le domaine kerberos.

30 juin 2014

kinit

Obtenir un TGT initial

OPTIONS

27 juin 2014

kproplog

Affiche le contenu les logs de mise à jours de la base Kerberos

kproplog affiche le contenu des logs de mise à jours du KDC sur la sortie standard. Il peut être utilisé pour garder une trace des mises à jours incrémental de la base principal. Le fichier de log contient les logs maintenus par le processus kadmind sur le serveur maître, et kpropd sur les serveurs esclaves. Quand une mise à jours se produit, elle est loggée dans ce fichier. kproplog nécessite un accès en lecture à ce fichier, il va afficher uniquement les mises à jours pour le KDC sur lequel il est lancé. Sans options, affiche un sommaire des logs. Si invoqué sur le maître, affiche uniquement un sommaire des mises à jours.

OPTIONS

-R Ré-initialise le fichier de log. Force une re-synchronisation complète. Si utilisé sur un esclave, il va tout synchroniser. Sur un maître, tous les esclaves vont demander une synchronisation complète.
-h Affiche un sommaire des logs. Inclus le numéro de version, l'état de la base, le nombre d'updates, le timestamp du premier et dernier update, et le numéro de version de la première et dernière entrée.
-e num Affiche le num dernières entrées dans le log.
-v Affiche les attributs individuels par update. Exemple de sortie générée pour une entrée:

Update Entry
    Update serial # : 4
    Update operation : Add
    Update principal : test@EXAMPLE.COM
    Update size : 424
    Update committed : True
    Update time stamp : Fri Feb 20 23:37:42 2004
    Attributes changed : 6
        Principal
        Key data
        Password last changed
        Modifying principal
        Modification time
        TL data

Variables d'environnement

KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf

30 juin 2014

krb5-config

Indique quels flags utiliser pour compiler et lier les programmes avec Kerberos

Krb5-config indique au programmeur d'application quels flags utilisés pour compiler et linker les programmes avec les librairies Kerberos installées.

OPTIONS

--all Affiche la version, vendeur, préfixe, et exec-prefix
--version Affiche le numéro de version de Kerberos
--vendor Affiche le nom du vendeur de l'installation Kerberos
--prefix Affiche le préfixe pour lequel l'installation Kerberos a été construite
--exec-prefix Affiche le préfixe pour les exécutables pour lequel l'installation Kerberos a été construite
--defccname Affiche l'emplacement du cache d'accréditifs par défaut.
--defktname Affiche l'emplacement du keytab par défaut
--defcktname Affiche l'emplacement du keytab client par défaut
--cflags Affiche les flags de compilation utilisés pour construire l'installation Kerberos
--libs [library] Affiche les options du compileur nécessaire pour linkerà la librairie spécifiée. les valeurs permises sont:

krb5 Kerberos 5 applications (default)
gssapi GSSAPI applications with Kerberos 5 bindings
kadm-client Kadmin client
kadm-server Kadmin server
kdb Applications qui accèdent à la base Kerberos

18 juin 2014

krb5.conf

Fichier de configuration Kerberos

Ce fichier contient la configuration Kerberos, incluant l'emplacement des serveurs KDC et admin pour les domaines Kerberos, les valeurs par défaut pour le domaine courant et pour les applications kerberos, et les mappages de nom d'hôte dans les royaumes Kerberos. Normallement, ce fichier est dans /etc mais son emplacement peut être spécifié dans la variable KRB5_CONFIG.

Structure

   Les noms de sections sont entre crochets, chaque section peut contenir 0 ou plusieurs relations, sous la forme:

  foo = bar



ou:
fubar = {
    foo = bar
    baz = quux
}

   Placer un * à la fin d'une ligne indique que c'est la valeur final pour le tag. Cela signifie que ni le reste du fichier de configuration, ni un autre fichier de configuration ne sera vérifié pour une autre valeur pour ce tag.

Par exemple, les lignes suivantes:
foo = bar*
foo = baz
Alors la seconde valeur ne sera jamais lue.

Le fichier krb5.conf peut inclure d'autres fichiers en utilisant une des directives suivantes au début d'une ligne:
include FILENAME
includedir DIRNAME

   FILENAME et DIRNAME doivent être des chemin absolus. Le fichier ou le répertoire nommé doit exister et lisible. Inclure un répertoire inclue tous les fichiers dans le répertoire dont le nom consiste uniquement de caractères alphanumériques, "-" ou "_". Les fichiers de profils sont syntaxiquement indépendants de leurs parent, donc chaque fichier inclus doit commencer avec un en-tête de section. Le fichier krb5.conf peut spécifier que la configuration devrait être obtenue depuis un module chargeable, au lieu du fichier lui-même, en utilisant le directive suivante au début de la ligne avant toute section headers:

  module MODULEPATH:RESIDUAL

  MODULEPATH peut être relatif au chemin de librairies de l'installation de krb5, ou peut être un chemin absolus. RESIDUAL est fournis au module à l'initialisation. Si krb5 utilise une directive module, kdc.conf devrait également l'utiliser.

Sections

krb5.conf peut contenir les sections suivantes:

[libdefaults] Paramètres utilisés par la libraire Kerberos v5
[realms] information et paramètres de contact spécifique au domaine
[domain_realm] Map les noms d'hôte serveur à des domaines Kerberos
[capaths] Chemins d'authentification pour les inter-domaines non-hiérarchiques
[appdefaults] Paramètres utilisés par certaines applications Kerberos
[plugins] Contrôle l'enregistrement des plugins

Additionnellement, krb5.conf peut inclure une des relations décrites dans kdc.conf, mais n'est pas une pratique recommandée.

[libdefaults]

allow_weak_crypto à false (défaut), les type de chiffrements faibles seront exclus des listes default_tgs_enctypes, default_tkt_enctypes, et permitted_enctypes.
ap_req_checksum_type Un entier qui spécifie le type de checksum AP-REQ à utiliser dans l'authentifiant. Doit être non définis pour le checksun approprié pour la clé de chiffrement soit utilisé.
canonicalize A true (défaut: false), la requête du ticket initial va demander la canonicalisation du nom du principal, et que répondre avec des principaux du client différent du principal demandé sera accepté.
ccache_type Détermine le format du cache d'accéditifs créés par kinit ou autre. défaut: 4, qui représente le format le plus courant.
clockskew Définis la quantité maximum permise de décalage d'horloge en seconde que la librairie va tolérer. Défaut: 300.
default_ccache_name Cette relation spécifie le nom du cache d'accréditifs par défaut. Défaut: DEFCCNAME.
default_client_keytab_name Cette relation spécifie le nom du keytab par défaut pour obtenir les accréditifs du client. Défaut: DEFCKTNAME.
default_keytab_name Cette relation spécifie le nom du keytab par défaut à utiliser par les serveurs d'application tels que sshd. Défaut: DEFKTNAME.
default_realm Identifie le domaine Kerberos par défaut pour le client. Si non définis, un domaine doit être spécifié avec tout principar Kerberos en invoquant un programme tel que kinit
default_tgs_enctypes Identifie la liste supportée de type de chiffrement de clé de session que le client devrait demander dans un TGS-REQ, par ordre de préférence. Défaut: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
default_tkt_enctypes Identifie la liste supportée de type de chiffrement de clé de session que le client devrait demander dans un AS-REQ, par ordre de préférence. Défaut: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
dns_canonicalize_hostname Indique si la recherche de noms sera utilisée pour canoniser les noms d'hôte à utiliser dans les nom principal de service. Définis ce flag à false pour améliorer la sécurité en réduisant le dépendance à DNS. Défaut: true.
dns_lookup_kdc Indique si les enregistrements DNS SRV dervaient pour localiser le KDC et d'autre serveurs pour un domaine, s'il ne sont pas listés par krb5.conf. (noter que l'entrée admin_server doit être dans krb5.conf pour pouvoir contacter kadmin, parce que l'implémentation DNS pour kadmin est incomplète).
extra_addresses Permet à un ordinateur d'utiliser plusieurs adresses locales, pour permettre à Kerberos de travailler dans un réseau qui utilise le NAT. Les adresses devraient être listée séparées par une virgule. n'a pas d'effet si noaddresses est à true.
forwardable À true, les tickets initiaux ne seront pas forwardable par défaut, si permis par le KDC. Défaut: false
ignore_acceptor_hostname En acceptant les contextes de sécurité GSSAPI ou krb5 pour les principaux de service basés sur l'hôte, ignore tout nom d'hôte passé par l'application appelante, et permet aux clients d'authentifier tout principal de service dans le keytab correspondant au nom du service et au nom du domaine. peut compromettre la sécurité des environnements d'hôte virtuels. Défaut: false.
k5login_authoritative À true, les principaux doivent listés dans le fichier k5login de l'utilisateur pour avoir un accès login, si un fichier .k5login existe. Si ce flag est à false, un principal peut avoir l'accès login au travers d'autre mécanismes même si un k5login existe mais ne liste pas le principal. Défaut: true.
k5login_directory Si définis, la librairie va rechercher le fichier k5login de l'utilisateur local dans le répertoire spécifié, avec un nom de fichier correspondant au nom de l'utilisateur local. Sinon, recherche un fichier nommé .k5login dans le home de l'utilisateur. Pour des raisons de sécurité, .k5login doit être possédé par l'utilisateur local ou par root.
kdc_req_checksum_type Un entier qui spécifie le type de checksum à utilise pour les demande KDC, pour la compatibilité avec de vieille version de KDC.
noaddresses À true, les demandes pour les tickets initiaux ne seront pas faites avec des jeux de restriction d'adresse, permettant aux tickets d'être utilisés via les NAT. Défaut: true.
permitted_enctypes Identifie tous les types de chiffrement permis pour le chiffrement de clé de session. Défaut: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
plugin_base_dir Répertoire de base où se trouvent les plugins krb5. Défaut: krb5/plugins
preferred_preauth_types Permet de définir le type de pré-authentification préféré du client. Défaut: "17, 16, 15, 14" qui force libkrb5 à utiliser PKINIT si supporté.
proxiable À true, les tickets initiaux seront mandatables, si permis par le KDC. Défaut: false
rdns À true, la recherche de noms inversée sera utilisée en plus de la recherche de nom pour canoniser les nom d'hôte à utiliser dans les noms de principaux de service. Si dns_canonicalize_hostname est à false, ce flag n'a pas d'effet. défaut: true.
realm_try_domains Indique si les composants de domaine des hôte devraient être utilisés pour déterminer de domaine Kerberos de l'hôte. La valeur de cette variable est un entier: -1 signifie ne pas rechercher, 0 tente le domaine de l'hôte, 1 tente le domaine immédiatement parent, etc. Le mécanisme usuel de la librairie pour localiser les domaines Kerberos est utilisé pour déterminer si un domaine est un domaine valide, qui peut impliquer de consulter DNS si dns_lookup_kdc est mis. Défaut: -1
renew_lifetime Définis la durée de vie de renouvellement pour les demandes de tickets initiaux. Défaut: 0
safe_checksum_type Un entier qui spécifie le type de checksum à utiliser pour les demandes KRB-SAFE. Défaut: 8 (RSA MD5 DES). Ce champ est ignoré quand ça valeur est incompatible avec le type de clé de session.
ticket_lifetime Durée de vie par défaut pour les demandes de tickets initiaux. Défaut: 1 jour
udp_preference_limit En envoyant un message au KDC, la librairie tente d'utiliser TCP avant UDP si la taille du message est supérieur à udp_preference_limit.
verify_ap_req_nofail À true, une tentative de vérifier des accréditifs initiaux va échouer si la machine client n'a pas de keytab. Défaut: false

[realms]

Chaque tag dans cette section est le nom d'un domaine Kerberos. La valeur du tag est une sous-section qui définis les propriétés de ce domaine. Pour chaque domaine, les tags suivants peuvent être spécifiés dans la sous-section:

admin_server Identifie l'hôte où le serveur d'administration réside. Typiquement, c'est le serveur maître. Ce tag doit avoir une valeur pour permettre la communication avec le serveur kadmind
auth_to_local Permet de définir un règle générale pour le mappage des noms des principaux aux nom des utilisateurs locaux. Est utilisé s'il n'y a pas de mappage explicite pour le nom principal. Les valeurs possible sont:

RULE:exp Le nom local sera formulé depuis exp. Le format est [n:string](regexp)s/pattern/replacement/g. L'entier n indique combien de composants le principal cible devrait avoir. Si cela matche, alors un chaîne sera formée depuis string, en substituant le domaine du principal pour $0 et le n-ième composant du principal pour $n ( exemple, si le principal était johndoe/admin alors [2:$2$1foo] va résulter dans la chaîne adminjohndoefoo). Si la chaîne matche regexp, alors la substitution de commande s//[g] ne va jamais parcourir la chaîne. le g optionnel matche toutes les occurences.
DEFAULT Le nom du principal sera utilisé tel que le nom d'utilisateur. Si le principal a plus d'un composant ou n'est pas le domaine par défaut, cette règle n'est pas applicable et la conversion va échouer.

Par exemple:
[realms]
    ATHENA.MIT.EDU = {
        auth_to_local = RULE:[2:$1](johndoe)s/^.*$/guest/
        auth_to_local = RULE:[2:$1;$2](^.*;admin$)s/;admin$//
        auth_to_local = RULE:[2:$2](^.*;root)s/^.*$/root/
        auto_to_local = DEFAULT
    }

va résulter en tout principal sans root ou admin comme second composant à traduire avec la règle par défaut. Un principal avec un second composant admin va devenir son premier composant. root sera utilisé comme nom local pour tout principal avec un second composant root. L'exception à ces règles sont tout principal johndoe/* qui sera toujours le nom local guest.

auth_to_local_names Cette sous-section vous permet de définir explicitement des mappages de noms de principaux à des noms locaux. Le tag est le nom mappé, et la valeur est l'utilisateur local
default_domain Ce tag spécifie le domaine utilisé pour étendre les noms d'hôte en traduisant les principaux Kerberos v4 en principaux v5.
kdc Le nom ou l'adresse d'un hôte hébergeant un KDC pour ce domaine. Un numéro de port optionnel peut être inclus. Si le nom ou l'adresse contient des ":", utiliser des crochets pour distinguer le ":" de l'adresse du numéro de port. Pour que la machine puisse communiquer avec le KDC, ce tag doit être donné, ou il doit y avoir des enregistrements DNS SRV.
kpasswd_server Pointe vers le serveur où tous les changements de mot de passe sont effectués. S'il n'y a pas de telles entrées, le port 464 de l'hôte admin_server sera tenté.
master_kdc Identifie le KDC maître. Actuellement, ce tag est utilisé dans un cas: si la tentative d'obtention des accréditifs échoue à cause d'un mot de passe invalide, le client va tenter de contacter le KDC maître, dans le cas où le mot de passe de l'utilisateur vient juste d'être changé.

[domain_realm]

   Cette section fournis une traduction depuis un nom de domaine ou un nom d'hôte en un nom de domaine Kerberos. Le nom du tag peut être un nom d'hôte ou un nom de domaine, où les noms de domaine sont identifiés par un préfixe point (.). La valeur est le nom de domaine Kerberos pour un hôte ou un domaine particulier. Une relation de nom d'hôte fournis implicitement la relation de nom de domaine correspondante, sauf si une relation de nom de domaine explicite est fournie. Le domaine Kerberos peut être identifié soit dans la section realm ou en utilisant les enregistrements DNS SRV. Les noms d'hôte et domaine devraient être en minuscules. Par exemple:

[domain_realm]
    crash.mit.edu = TEST.ATHENA.MIT.EDU
    .dev.mit.edu = TEST.ATHENA.MIT.EDU
    mit.edu = ATHENA.MIT.EDU

   mappe l'hôte crash.mit.edu dans le domaine Kerberos TEST.ATHENA.MIT.EDU. La seconde entrée map tous les hôtes sous le domaine dev.mit.edu dans le domaine Kerberos TEST.ATHENA.MIT.EDU sauf l'hôte dev.mit.edu qui est mappé au domaine ATHENA.MIT.EDU.

   Si aucune traduction ne s'applique au nom d'hôte utilisé pour un principal de service pour une demande de ticket de service, la librairie va tenter d'obtenir un référant au domaine approprié depuis le KDC du domaine du client. Si cela échoue, le domaine de l'hôte est considéré être la portion de domaine du nom d'hôte convertit en majuscules, sauf le paramètre realm_try_domains dans la section libdefaults qui force un domaine parent différent à utiliser.

[capaths]

   Pour pouvoir effectuer une authentification inter-domaine directe ( non hiérarchique ), une configuration est nécessaire pour déterminer les chemins d'authentification entre les domaines.

   Un client va utiliser cette section pour trouver le chemin d'authentification entre son domaines et le domaine du serveur. Le serveur va utiliser cette section pour vérifier le chemin d'authentification utilisé par le client, en vérifiant le champ transited.

   Il y a un tag pour chaque domaine client participant, et chaque tag a des sous-tags pour chaque domaine serveur. La valeur des sous-tags est un domaine intermédiaire qui peuvent participer dans l'authentification inter-domaine. Les sous-tags peuvent être répétés s'il y a plus d'un domaine intermédiaire. Une valeur "." signifie que le 2 domaines partagent les clés directement, et aucun intermédiaire ne devrait être autorisé à participer.

   Seul ces entrées qui sont nécessaire dans le client ou le serveur doivent être présent. Un client a besoin d'un tag pour son domaine local avec des sous-tags pour tous les domaines des serveurs auquel il aura besoin de s'authentifier. Un sereur a besoin d'un tag pour chaque domaine des clients qu'il désert, avec un sous-tag pour chaque domaine serveur.

   Par exemple, ANL.GOV, PNL.GOV et NERSC.GOV veulent utiliser le domaine ES.NET comme domaine intermédiaire. ANL a un sous-domaine TEST.ANL.GOV qui va s'authentifier avec NERSC.GOV mais pas PNL.GOV. La section capaths pour les systèmes ANL.GOV ressembleraient à:

[capaths]
    ANL.GOV = {
        TEST.ANL.GOV = .
        PNL.GOV = ES.NET
        NERSC.GOV = ES.NET
        ES.NET = .
    }
    TEST.ANL.GOV = {
        ANL.GOV = .
    }
    PNL.GOV = {
        ANL.GOV = ES.NET
    }
    NERSC.GOV = {
        ANL.GOV = ES.NET
    }
    ES.NET = {
        ANL.GOV = .
    }

La section capaths du fichier de configuration utilisé dans les systèmes NERSC.GOV ressembleraient à:
    [capaths]
        NERSC.GOV = {
            ANL.GOV = ES.NET
            TEST.ANL.GOV = ES.NET
            TEST.ANL.GOV = ANL.GOV
            PNL.GOV = ES.NET
            ES.NET = .
        }
        ANL.GOV = {
            NERSC.GOV = ES.NET
        }
        PNL.GOV = {
            NERSC.GOV = ES.NET
        }
        ES.NET = {
            NERSC.GOV = .
        }
        TEST.ANL.GOV = {
            NERSC.GOV = ANL.GOV
            NERSC.GOV = ES.NET
        }

   Quand un sous-tag est utilisé plus d'une fois dans un tag, les clients utilisent l'ordre des valeurs pour déterminer le chemin. L'ordre des valeurs n'est pas important pour les serveurs.

[appdefault]

   Chaque tag dans cette section nomme une application Kerberos v5 ou un option qui est utilisé par certaines applications Kerberos v5. La valeur du tag définis le fonctionnement par défaut pour cette application.

par exemple:
[appdefaults]
    telnet = {
        ATHENA.MIT.EDU = {
            option1 = false
        }
    }
    telnet = {
        option1 = true
        option2 = true
    }
    ATHENA.MIT.EDU = {
        option2 = false
    }
    option2 = true

   Les 4 manières présentées de spécifier la valeur d'une option sont affichés dans l'ordre de précédence descendante. Dans cet exemple, si telnet fonctionne dans le domaine EXAMPLE.COM, il devrait, par défaut, avoir option1 et option2 à true. Cependant, un programme telnet dans le domaine ATHENA.MIT.EDU devrait avoir l'option1 à false et option2 à true. Tout autre programme dans ATHENA.MIT.EDU devrait avoir l'option2 à false par défaut. Tout programme fonctionnant dans d'autre domaine devraient avoir option2 à true.

   La liste d'options spécifiable pour chaque application peut être trouvée dans les man des applications.

[plugins]

   Les tags dans cette section peuvent être utilisées pour enregistrer les modules dynamique et pour activer/désactiver les modules. Tous les interface activable n'utilisent pas cette section. Celles qui l'utilise sont documentées ici. Chaque interface pluggable correspond à une sous-section. Toutes les sous-sections supportent les même tags:
   [SECTION]
   [SECTION] name="-" table="paragraphes" imbrication="0"
   Ce tag peut avoir plusieurs valeurs. S'il y a des valeur pour ce tag, alors les modules nommés seront désactivés pour l'interface pluggable.
   Ce tag peut avoir plusieurs valeurs. S'il y a des valeur pour ce tag, alors les modules nommés seront activés pour l'interface pluggable.
   Ce tag peut avoir plusieurs valeurs. Chaque valeur est une chaîne sous la forme modulename:pathname. chaque module est enregistré comme module dynamique pour l'interface pluggable. Si pathname n'est pas un chemin absolus, il est considéré relatif à plugin_base_dir.

   Pour les interfaces pluggable où l'ordre des modules est importante, les modules enregistrés avec un tag module viennent en premier, dans l'ordre qu'il sont enregistrés. Si enable_only est utilisé, alors l'ordre de ces tags remplace l'ordre des modules normal.

  Les sections suivantes sont actuellement supportées dans la section plugins.

interface ccselect

La sous-section ccselect contrôle les modules pour la sélection du cache d'accréditifs dans une collection de cache. En plus des modules dynamique enregistrés, les modules embarqués suivant existent:

k5identity Utilise un fichier .k5identity dans le home de l'utilisateur pour sélectionner un principal
realm Utilise le domaine de service pour deviner un cache approprié depuis la collection.

interface pwqual

Cette sous-section contrôle les modules pour l'interface de qualité de mot de passe, qui est utilisé pour rejeter les mots de passe faibles lors des changements de mot de passe. Les modules embarqués suivant existent pour cette interface:

dict Vérifie avec un fichier dictionnaire du domaine
empty Rejète les mots de passe vide
hesiod Vérifie avec les informations utilisateurs stockés dans Hesiod ( seulement si Kerberos est construit avec le support de Hesiod )
princ Vérifie avec les composant du nom du principal

interface kadm5_hook

Fournis des plugins avec des informations sur la création de principaux, la modification, changement de mot de passe et suppression. Cette interface peut être utilisée pour écrire un plugin pour synchroniser Kerberos MIT avec celui de Microsoft.

interface clpreauth et kdcpreauth

Ces interfaces permettent aux modules de fournir des mécanisme de pré-authentification au client et au KDC. Les modules intégrés suivant existent pour ces interfaces:

pkinit Implémente le mécanisme de pré-authentification pkinit
encrypted_challenge Implémente FAST
encrypted_timestamp Implément le mécanisme de timestamp chiffré

interface hostrealm

Cette section contrôle les modules pour l'interface host-to-realm, qui affecte le mappage locale des noms d'hôte et le choix du domaine par défaut. Les module intégré suivant existent pour cette interface:

profile Consulte la section [domain_realm] du profile pour les mappages host-to-realm autoritatifs, et la variable default_realm pour le domaine par défaut.
dns Recherche les enregistrements DNS pour les mappages et le domaine par défaut. n'opère que si dns_lookup_realm est à true.
domain Applique de l'heuristique pour les mappages host-to-realm. Implémente la variable realm_try_domains, et utilise le domaine parent en majuscule du nom d'hôte si cela ne produit pas de résultat.

interface localauth

Contrôle les modules pour l'interface d'autorisation local, qui affecte la relation entre les principaux Kerberos et les comptes système locaux. Les modules intégrés suivant existent pour cette interface:

default Implémente le type DEFAULT pour les valeurs auth_to_local
rule Implémente le type RULE pour les valeur auth_to_local
names Recherche un mappage auth_to_local_names pour le nom du principal
k5login Autorise un principal à un compte local en accord avec le .k5login du compte
an2ln Autorise un principal à un compte local si le nom du principal se mappe au nom local

Options PKINIT

   Les options suivante sont spécifique à PKINIT. Ces valeur peuvent être spécifiées dans [libdefaults] comme valeurs globales par défaut, ou dans une sous-section spécifique au domaine, ou peuvent être spécifiés comme valeurs spécifique au domaine dans la section [realms]. Les valeurs spécifique au domaine écrase, n'ajoutent pas à une spécification libdefaults par défaut. L'ordre de recherche est:

1. sous-section spécifique au domaine de [libdefaults]
[libdefaults]
    EXAMPLE.COM = {
        pkinit_anchors = FILE:/usr/local/example.com.crt
    }

2. Valeurs spécifique au domaine dans [realms]
[realms]
    OTHERREALM.ORG = {
        pkinit_anchors = FILE:/usr/local/otherrealm.org.crt
    }

3. Valeur générique dans [libdefaults]
[libdefaults]
    pkinit_anchors = DIR:/usr/local/generic_trusted_cas/

Spécifier les informations d'identité PKINIT

FILE:filename[,keyfilename] Cette option est dépendante du contexte.

Dans pkinit_identity ou pkinit_identities, filename spécifie le nom d'un fichier PEM contenat le certificat de l'utilisateur. Si Keyfilename n'est pas spécifié, la clé privée de l'utilisateur est attendue dans filename.

Dans pkinit_anchors ou pkinit_pool, filename est assumé être le nom d'un fichier ca-bundle style OpenSSL.

DIR:dirname Cette option est dépendante du contexte.

Dans pkinit_identity ou pkinit_identities, dirname spécifie un répertoire avec des fichiers .crt et .key.

Dans pkinit_anchors ou pkinit_pool, dirname est assumé être un répertoire CA hashé style OpenSSL où chaque certificat CA est stocké dans un fichier nommé hash-of-ca-cert.#

PKCS12:filename filename est le nom d'un pkcs#12, contenant le certificat de l'utilisateur en la clé privée.
PKCS11:[module_name=]modname[:slotid=slot-id][:token=token-label][:certid=cert-id][:certlabel=cert-label] Tous les mots clé sont optionnels. modname spécifie l'emplacement de la librairie PKCS#11. Si une valeur est rencontrée sans mot clé, il est assumé être le modname. Si aucun nom de module n'est spécifié, le défaut est opensc-pkcs11.so. slotid= et/ou token= peuvent être spécifiés pour forcer l'utilisation d'un lecteur de carte ou un token spécifique. certid= et/ou certlabel peuvent être utilisés pour forcer la sélection d'un certificat particulier sur un périphérique.
ENV:envvar envvar spécifie le nom d'une variable d'environnement qui a été définie à une valeur se conformant à une des valeur précédente. Par exemple, ENV:X509_PROXY où la variable d'environnement X509_PROXY a été définie à FILE:/tmp/my_proxy.pem

options krb5.conf pour PKINIT

pkinit_anchors Spécifie l'emplacement des certificats de confiance racine que le client utilise pour signer les certificats KDC. Peut être spécifié plusieurs fois.
pkinit_cert_match Spécifie les règles de correspondance que le certificat client doit matcher avant d'être utilisé pour l'authentification PKINIT. Peut être spécifié plusieurs fois. Tous les certificats sont vérifiés avec chaque règle jusqu'à ce qu'un certificat matche. La comparaison de chaîne Issuer et Subject sont des représentations chaîne rfc2253 des valeurs Issuer DN et Subject DN du certificat. La syntaxe de la règle est [relation-operator]component-rule ... où:

relations-operator peut être soit && signifiant toutes les composantes des règles doivent matcher, ou || signifiant que seul un composant de règle doit matcher. Défaut: &&
component-rule Peut être un des suivant. Noter qu'il n'y a pas de ponctuation ou d'espace blanc entre les composantes de règle:

‹SUBJECT› regular-expression
‹ISSUER› regular-expression
‹SAN› regular-expression
‹EKU› extended-key-usage-list
‹KU› key-usage-list

extended-key-usage-list est une liste de valeurs Extended Key Usage. Toutes les valeurs dans la liste doivent être présents dans le certificat. Les valeurs sont:

pkinit
msScLogin
clientAuth
emailProtection

key-usage-list est une liste de valeurs requises Key Usages. Toutes les valeurs dans la liste doivent être présentes dans le certificat. Les valeurs sont:

digitalSignature
keyEncipherment

exemple:
pkinit_cert_match = ||‹SUBJECT›.*DoE.*‹SAN›.*@EXAMPLE.COM
pkinit_cert_match = &&‹EKU›msScLogin,clientAuth‹ISSUER›.*DoE.*
pkinit_cert_match = ‹EKU›msScLogin,clientAuth‹KU›digitalSignature

pkinit_eku_checking spécifie quelle valeur d'Extended Key Usage le certificat KDC présenté au client doit contenir. (Noter que si le certification du KDC a le pkinit SubjectAlternativeName encodé comme nom Kerberos TGS, la vérification EKU n'est pas nécessaire vu que la CA fournie a certifié cela comme certificat KDC). Les valeurs reconnues sont:

kpKDC C'est la valeur par défaut et spécifie que le KDC doit avoir le id-pkinit-KDKdc EKU comme définis dans la rfc4556.
kpServerAuth Un certificat KDC avec le id-kp-serverAuth EKU tel qu'utilisé par Microsoft sera accepté
none Le certificat du KDC ne sera pas vérifié pour savoir s'il a un EKU acceptable.

pkinit_dh_min_bits Taille de la clé Diffie-Hellman que le client va tenter d'utiliser. les valeur acceptable sont 1024, 2048 (défaut), et 4096.
pkinit_identities Spécifie les emplacements à utiliser pour trouver les information d'identité X.509 du client. Peut être spécifié plusieurs fois. Ces valeur ne sont pas utilisées si l'utilisateur spécifie X509_user_identity sur la ligne de commande.
pkinit_kdc_hostname La présence de cette option indique que le client est prêt à accepter un certificat KDC avec un dNSName SAN au lieu de nécessiter de id-pkinit-san comme définis dans la rfc4556. peut être spécifié plusieurs fois.
pkinit_longhorn À true, on parle au KDC Longhorn
pkinit_pool Spécifie l'emplacement des certificats intermédiaires qui peuvent être utilisés par le client pour compléter la validation de la chaîne. Peut être spécifié plusieurs fois.
pkinit_require_crl_checking Vérifie les informations de révocation.
pkinit_revoke Spécifie l'emplacement de la CRL à utiliser pour vérifier les informations de révocations.
pkinit_win2k Spécifie si le domaine cible est supporte l'ancienne version, pré-rfc, de Kerberos
pkinit_win2k_require_binding À true, le KDC cible attendu est patché pour retourner une réponse avec un checksum. Défaut: false

Expansion de paramètres

De nombreuses variables, telles que default_keytab_name, permettent d'étendre les paramètres:

%{TEMP} Répertoire temporaire
%{uid} User ID réel ou Windows SID
%{euid} User ID effectif ou Windows SID
%{USERID} Idem à %{uid}
%{null} Chaîne vide
%{LIBDIR} Répertoire d'installation des librairies
%{BINDIR} Répertoire d'installation des binaires
%{SBINDIR} Répertoire d'installation des binaires administratifs
%{username} nom de l'utilisateur unix ou user ID effectif
%{APPDATA} (Windows) Roaming application data for current user
%{COMMON_APPDATA} (Windows) Application data for all users
%{LOCAL_APPDATA} (Windows) Local application data for current user
%{SYSTEM} (Windows) Windows system folder
%{WINDOWS} (Windows) Windows folder
%{USERCONFIG} (Windows) Per-user MIT krb5 config file directory
%{COMMONCONFIG} (Windows) Common MIT krb5 config file directory

Exemple de fichier krb5.conf

[libdefaults]
    default_realm = ATHENA.MIT.EDU
    default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
    default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
    dns_lookup_kdc = true
    dns_lookup_realm = false

[realms]
    ATHENA.MIT.EDU = {
        kdc = kerberos.mit.edu
        kdc = kerberos-1.mit.edu
        kdc = kerberos-2.mit.edu:750
        admin_server = kerberos.mit.edu
        master_kdc = kerberos.mit.edu
        default_domain = mit.edu
    }
    EXAMPLE.COM = {
        kdc = kerberos.example.com
        kdc = kerberos-1.example.com
        admin_server = kerberos.example.com
    }

[domain_realm]
    .mit.edu = ATHENA.MIT.EDU
    mit.edu = ATHENA.MIT.EDU

[capaths]
    ATHENA.MIT.EDU = {
         EXAMPLE.COM = .
    }
    EXAMPLE.COM = {
         ATHENA.MIT.EDU = .
    }

26 juin 2014

krb5kdc

Service d'authentification Kerberos et centre de distribution des clés

OPTIONS

-r realm Spécifie le domaine Kerberos
-d dbname Spécifie le nom sous lequel la base principale peut être trouvée. Ne s'applique pas aux base LDAP
-k keytype Spécifie le type de clé de la clé maître.
-M mkeyname Spécifie le nom du principal pour la clé maître dans la base.
-m Spécifie que le mot de passe maître de la base devrait être lu depuis le clavier au lieu d'un fichier sur disque.
-n Spécifie que le KDC ne se place pas en tâche de fond.
-P pid_file PID du service
-p portnum Numéros de port UDP d'écoute. Liste séparé par "," Défaut 88,750
-w numworkers Fork le nombre de processus spécifié pour écouter et traiter en parallèle. Le processus parent agit comme superviseur et relai les signaux SIGHUP.

Note: Sur les OS qui supportent pktinfo, utiliser les sous-processus empêche de KDC d'écouter les paquets UDP sur les interfaces créés après que le KDC ait démarré.

-x nconns=number_of_connections Spécifie le nombre de connexion à maintenir par serveur LDAP
-x host=ldapuri Spécifie le serveur LDAP à contacter
-x binddn=binddn Spécifie le DN de l'objet à utiliser par le serveur d'administration
-x bindpwd=bind_password Mot de passe du binddn
-x debug=level Définis le niveau de verbosité de la librairie cliente OpenLDAP
-T offset Spécifie un offset de temps, en secondes, pendant lequel le KDC va opérer.

Exemples

Le KDC peut désservir jusqu'à 32 domaines. Les domaines sont listés sur la ligne de commande, les options par domaine peuvent être spécifiés avant chaque domaine:

krb5kdc -p 2001 -r REALM1 -p 2002 -r REALM2 -r REALM3

Variables d'environnement

KRB5_CONFIG Spécifie l'emplacement de krb5.conf
KRB5_KDC_PROFILE Spécifie l'emplacement de kdc.conf

30 juin 2014

ksu

Version kerberisé de su

ksu est une version Kerberisé du programme su qui a 2 objectifs: sécuriser les changements d'ID d'utilisateur réel et effctifs, et de pouvoir créer de nouveaux contextes de sécurité.

Authentification

ksu opère en 2 phases: l'authentification et l'autorisation. Résoudre le nom du principal de la cible est la première étape de l'authentification. L'utilisateur peut soit spécifier sont nom de principal avec -n, ou un nom de principal par défaut sera assigné en utilisant l'heuristique. Le nom de l'utilisateur cible doit être le premier argument du ksu; si non spécifié, root est le défaut. Si . est spécifié, l'utilisateur cible sera l'utilisateur source, Si l'utilisateur source est root ou l'utilisateur cible est l'utilisateur source, aucune authentification est aucune autorisation ne sera effectuée. Sinon, ksu recherche un ticket Kerberos approprié dans le cache de la source.

Ce ticket peut être soit pour un serveur final, ou un TGT pour le domaine du principal cible. Si le ticket pour le serveur final est déjà dans le cache, il est déchiffré et vérifié. S'il n'est pas dans le cache mais que le TGT l'est, le TGT est utilisé pour obtenir le ticket. Si aucun de cet tickets n'est présent, et ksu est compilé avec GET_TGT_VIA_PASSWD, l'utilisateur devra entrer son mot de passe qui sera ensuite utilisé pour obtenir un TGT. Si l'utilisateur est loggé à distance et n'a pas de canal sécure, le mot de passe peut être exposé. Si ni le ticket ni GET_TGT_VIA_PASSWD ne sont présent, l'authentification échoue.

Autorisation

Cette section décris l'autorisation de l'utilisateur source quand ksu est appelé sans l'option -e.Une fois l'authentification réussie, ksu vérifie que le principal cible est autorisé pou accéder au compte cible. Dans le home de l'utilisateur cible, ksu tente d'accéder à .k5login et .k5users Pour vérifier les autorisations.

Si le nom du principal cible est trouvé dans le .k5login, l'utilisateur source, est autorisé à accéder au compte cible. Sinon, ksu recherche le fichier .k5users. Si le nom de principal cible est trouvé sans commandes ou suivi uniquement par *, l'utilisateur source est autorisé. Si les 2 fichiers ne sont trouvés mais qu'aucune entrée appropriée pour le principal cible n'existe, l'accès est refusé. Si les 2 fichiers n'existent pas le principal aura accès au compte en accord avec la règle de mappage aname-›lname. Sinon l'autorisation échoue.

Exécution du shell cible

Une fois l'autorisation réussie, ksu se comporte comme su. L'environnement n'est pas modifié sauf USER, HOME, et SHELL. Si l'utilisateur cible n'est pas root, USER est l'utilisateur cible. Sinon USER reste inchangé. La variable d'environnement KRB5CCNAME est définie au nom du cache de la cible. L'ID utilisateur réel et effectif sont changés à l'utilisateur cible. Une fois le shell terminé, ksu supprime le cache cible, sauf si -k.

Créer un nouveau contexte de sécurité

ksu peut être utilisé pour créer un nouveau contexte de sécurité pour le programme cible ( soit le shell, soit la commande spécifiée avec -e). Le programme cible hérite d'un jeu d'accréditifs de l'utilisateur source. Par défaut, ce jeu inclue tous les accréditifs dans le cache source, plus tout type d'accréditifs obtenus durant l'authentification. L'utilisateur source est capable de limiter les accréditifs dans le jeu avec les options -z ou -Z. -z restreins la copie des tickets du cache source dans le cache cible aux seuls tickets où le client == le nom principal cible. -Z fournis à l'utilisateur cible un cache neuf, sans accréditifs. Noter que pour des raisons de sécurité, quand l'utilisateur source est root et l'utilisateur cible non-root, -z est le mode par défaut.

Note: durant l'authentification, seul les tickets qui pourraient être obtenus sans fournir de mot de passe sont cachés dans le cache source.

OPTIONS

-n target_principal_name Spécifie un nom de principal cible. non spécifié, un nom de principal par défaut est assigné via les cas suivant:

Cas 1: l'utilisateur source est non-root Si l'utilisateur cible est l'utilisateur source, le nom de principal par défaut est définis au principal par défaut du cache source. Si le cache n'existe pas, le nom de principal par défaut est target_user@local_realm. Si les utilisateurs source et cible sont différent et que .k5users et .k5login n'existent pas, le nom de principal est target_user_login_name@local_realm. Sinon, en commençant avec le premier principal listé ci-dessous, ksu vérifie si le principal est autorisé à accéder au compte cible et s'il y a un ticket pour ce principal dans le cache source.

a. Principal par défaut du cache source
b. target_user@local_realm
c. source_user@local_realm

Cas 2: l'utilisateur source est root Si l'utilisateur cible est non-root, le nom de principal par défaut est target_user@local_realm. Sinon, si le cache source existe, le nom est un principal par défaut du cache source. Si le cache source n'existe pas, le nom est root\@local_realm.

-c source_cache_name Spécifie le nom du cache source. Non spécifié, utilise KRB5CCNAME, ou définis à krb5cc_‹target uid›.(gen_sym()).
-k Ne supprime pas le cache cible à la sortie du shell ou de la commande.
-d mode debug
-z Restreins la copie de tickets du cache source dans le cache cible aux seuls tickets où client==le nom du principal cible.
-Z Ne copie aucun tickets du cache source dans le cache cible.
-q mode silencieux
-l lifetime (chaîne time_duration) Spécifie la durée de vie pour les tickets demandés. défaut 12 heures.
-r time (chaîne time_duration) spécifie l'option renewable à demander pour les tickets.
-p Spécifie que l'option proxiable devrait être demandé pour le ticket
-f Spécifie que l'option forwardable devrait être demandé pour le ticket
-e command [args ...] Exécute la commande spécifiée au lieu d'exécuter le shell cible.

Le fichier .k5users a le format suivant: Une seul entrée par ligne qui peut être suivie par une liste de commandes que le principal est autorisé à exécuter. Un nom de principal suivi par un * signifie que l'utilisateur est autorisé à exécuter une commande. Ainsi, l'exemple suivant:

jqpublic@USC.EDU ls mail /local/kerberos/klist
jqpublic/secure@USC.EDU *
jqpublic/admin@USC.EDU

La première ligne autorise à exécuter ls, mail et klist. La deuxième ligne autorise à exécuter toute commande, et la troisième autorise uniquement à exécuter le shell cible, tout comme la deuxième ligne, mais pas la première.

-a args Spécifie les arguments à passer au shell cible. cette option peut être utilisé pour simuler l'option -e avec: -a -c[command [arguments]].

Instructions d'installation

ksu peut être compilé avec les flags suivant:

GET_TGT_VIA_PASSWD Si aucun ticket approprié n'est trouvé dans le cache source, demande à l'utilisateur son mot de passe.
PRINC_LOOK_AHEAD Durant la résolution du nom de principal par défaut, permet à ksu de trouver les noms des principaux dans le fichier .k5users.
CMD_PATH Spécifie une liste de répertoires contenant les programmes que les utilisateur sont autorisés à exécuter (via le fichier .k5users)
HAVE_GETUSERSHELL Si l'utilisateur source est non-root, ksu insiste pour que le shell de l'utilisateur invoqué soit un shell légal.

ksu devrait être possédé par root et avoir le set user bit mis.

30 juin 2014

kswitch

Spécifier le cache primaire dans une collection

OPTIONS

-c cachename Spécifie le cache d'accréditifs à rendre primaire
-p principal Recherche un cache contenant des accréditifs pour le principal, dans la collection.

Variable d'environnement

KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5

27 juin 2014

ktutil

Utilitaire de gestion de fichiers keytab

Commandes

list Affiche la keylist courante. Alias: l
read_kt keytab Lit le keytab Kerberos v5 dans la keylist courante. Alias: rkt
read_st srvtab Lis le srvtab Kerberos v4 dans la keylist courante. Alias: rst
write_kt keytab Écrit la keylist courant dans le keytab. Alias: wkt
write_st srvtab Écrit la keylist courant dans le srvtab. Alias: wst
clear_list Efface le keylist courante. Alias: clear
delete_entry supprime l'entrée dans le numéro de slot de la keylist courante. Alias: delent
add_entry {-key|-password} -p principal -k kvno -e enctype Ajoute un principal dans la keylist en utilisant une clé ou un mot de passe. Alias: addent
list_requests Affiche une liste des commande disponibles. Alias: lr,?
quit quitte. Alias: exit,q

Exemples

ktutil: add_entry -password -p alice@BLEEP.COM -k 1 -e
aes128-cts-hmac-sha1-96
Password for alice@BLEEP.COM:
ktutil: add_entry -password -p alice@BLEEP.COM -k 1 -e
aes256-cts-hmac-sha1-96
Password for alice@BLEEP.COM:
ktutil: write_kt keytab
ktutil:

30 juin 2014

kvno

Acquière un ticket de service pour les principaux spécifiés et affiche les numéros de version de clé pour chaque.

OPTIONS

-c ccache Spécifie le nom du cache d'accréditifs à utiliser
-e etype Spécifie le enctype à demander pour la clé de session de tous les services nommés.
-q Mode silencieux en cas de réussite.
-P Spécifie que les arguments service1 service2 ... sont interprétés comme noms d'hôte, et les principaux de service sont à construire depuis ces nom et le nom de service sname. Les noms d'hôte de service seront canonisés en accord avec les règles pour construire les principaux de service.
-U for_user Spécifie que S4U2Self est utilisé pour obtenir un ticket pour for_user. Si la délégation de contraintes n'est pas requise, le nom de service doit matcher le cache d'accréditifs du principal du client.

Variable d'environnement

KRB5CCNAME peut contenir un nom de cache d'autorisations Kerberos5

fichiers

DEFCCNAME Emplacement par défaut pour le cache d'accréditifs Kerberos 5

07 mai 2017

/etc/selinux/newrole_pam.conf

Configuration pour newrole

Ce fichier est utilisé par la commande newrole et mappe les applications ou commandes en fichiers de configuration PAM. Chaque ligne contient le nom du fichier exécutable suivi par le nom d'un fichier de configuration pam qui existe dans /etc/pam.d

Ajouter cette ligne dans /etc/pam.d/login pour définir une message au login
auth optional pam_issue.so issue=/etc/issue

06 octobre 2010

pam_keyinit

Affiche le fichier keyinit

pam_keyinit s'assure que le process invoque une session keyring autre que la session keyring par défaut de l'utilisateur. Il vérifie si la session keyring du processus est le défaut de l'utilisateur, et si c'est le cas, crée une nouvelle session keyring anonyme. Ce module est utilié principalement pour les processus de login. Ce module ne devrait pas être invoqué par des programmes comme su. Le package keyutils est utilisé pour manipuler les clés plus directement.

OPTIONS

debug Affiche des informations de debuggage
force force le session keyring du processus invoquant pour être remplacé inconditionnellement
revoke Force le session keyring du processus invoquant pour être révoqué quand ce processus quitte si le session keyring pour ce processus

Valeurs retournées

ne fournit que le type de module session. Retourne PAM_SUCCESS, pam_ATH_ERR, PAM_BUF_ERR, PAM_IGNORE, PAM_SERVICE_ERR, PAM_SESSION_ERR et PAM_USER_UNKNOWN

Exemples

Ajouter cette ligne dans les entrées logins pour commencer chaque session login avec sa propre session keyring
session required pam_keyinit.so

02 juillet 2014

pam_krb5

Module d'authentification Kerberos

OPTIONS

ccache=‹pattern› Utilise le pattern pour créer le cache d'accréditifs. doit être sous la forme ‹type›:‹residual›. %u est remplacé avec l'id de l'utilisateur. %p est remplacé avec le PID courant. Si pattern se termine avec la chaîne XXXXXX, une chaîne aléatoire est utilisée. (auth et session)
ccache_dir=‹directory› Stocke les caches utilisateur dans le répertoire spécifié au lieu de /tmp (auth et session)
debug mode debug
forwardable Obtient des tickets forwardable (auth)
ignore_k5login Ne regarde jamais dans le fichier .k5login dans le home de l'utilisateur (auth et account)
ignore_root Ne fait rien si l'utilisateur est root.
minimum_uid=‹uid› ID minimum pour authoriser l'authentification
no_ccache ne créé pas de cache de ticket après l'authentification (auth). non définissable dans krb5.conf
realm=‹realm› Obtient des accréditifs dans le domaine spécifié au lieu de celui par défaut. non définissable dans krb5.conf
renew_lifetime=‹lifetime› Obtient des tickets renouvelable (auth)
retain_after_close Ne détruit pas le cache de ticket temporaire lorsque pam_end() ou pam_close_session() sont appelés. (auth et session)
search_k5login Utilise .k5login de l'utilisateur pour l'authentification.
try_first_pass Utilise le mot de passe d'un module précédent au lieu d'en demander un. En cas d'échec, demande un mot de passe.
use_authtok Utilise le mot de passe d'un module précédent au lieu d'en demander un. Ne demande jamais de mot de passe.
use_first_pass Utilise le mot de passe d'un module précédent au lieu d'en demander un. En cas d'échec, si aucun module n'a de mot de passe, en demande un, si un mot de passe est trouvé et ne fonctionne pas, échoue sans en demander un.

Variables d'environnement

KRB5CCNAME Définis par pam_setcred(). Fichier du cache d'accréditifs par défaut, sous la forme type:residual
PAM_KRB5CCNAME Définis par pam_authenticate() pour pointer vers le cache de ticket temporaire utilisé pour l'authentification.

Fichiers

/tmp/krb5cc_UID_RANDOM Nom du cache d'accréditifs par défaut.
/tmp/krb5cc_pam_RANDOM no du cache d'accréditifs utilisé pour le cache temporaire crée par pam_authenticate(). il est supprimé à la fin de la session pam ou quand pam_setcred() est appelé.
~/.k5login Fichier contenant les principaux Kerberos autorisés à accéder à ce compte.

Exemples

Exemple de configuration PAM:
auth sufficient pam_krb5.so ignore_root
session optional pam_krb5.so ignore_root
account required pam_krb5.so ignore_root
password optional pam_krb5.so ignore_root

Exemple de configuration krb5.conf
[appdefaults]
forwardable = true
    pam = {
        minimum_uid = 100
        EXAMPLE.COM = {
            ignore_k5login = true
        }
    }

06 octobre 2010

pam_lastlog

Affiche une ligne d'information sur la dernière connexion de l'utilisateur

Le module maintient le fichier /var/log/lastlog.

OPTIONS

debug Affiche des informations de debuggage
silent N'informe par 'utilisateur sur le précédent login, met simplement à jours /var/log/lastlog
never Si /var/log/lastlog est vide, indique à l'utilisateur qu'il n'a jamais été loggé
nodate N'affiche pas la date du dernier login
noterm N'affiche pas le nom du terminal
nohost N'indique pas depuis quel hôte le dernier login a eu lieu
nowtmp Ne met pas à jour l'entrée wtmp
noupdate Ne met aucun fichier à jour
showfailed Affiche le nombre de logins échoués et la date de la dernier tentative échouée depuis btmp

Valeurs retournées

PAM_SUCCESS tout est ok
PAM_SERVICE_ERR Erreur interne
PAM_USER_UNKNOWN utilisateur inconnu

Exemples

Ajouter cette ligne dans /etc/pam.d/login pour afficher le dernier login d'un utilisateur
session required pam_lastlog.so wtmp

13 novembre 2010

pam_ldap

Authentification via un serveur ldap

   pam_ldap fournit l'authentification, l'autorisation et le changement de mot de passe depuis un serveur ldap. Il inclus le support sécurisé, authentification sasl, les politiques de mot de passe renforcés pas le serveur, les autorisations de login basés sur les hôtes et groupes.

  Quand il autorise ou authentifie un utilisateur, pam_ldap map le nom de login de l'utilisateur à un DN en cherchant dans l'annuaire. Cela doit être possible en utilisant l'identité du système local, spécifié dans ldap.conf (cette étape initial ne supporte que l'authentification simple pour le moment).

  Pour authentifier ou autoriser un utilisateur, pam_ldap tente de se lier au serveur en utilisant le DN de l'utilisateur. pam_ldap est généralement configuré dans ldap.conf, mais certaines options peuvent être configurées dans le fichier de configuration PAM, pour permettre une granularité par service.

   Les options du fichier de configuration consistent d'un mot clé suivi par un espace et des arguments. Il est possible de configurer certains aspects de pam_ldap par service dans les fichiers de configuration de pam

OPTIONS

config=‹path› Spécifie le fichier de configuration à utiliser au lieu de ldap.conf. Il n'est pas possible d'utiliser plusieurs instances de configuration.
use_first_pass Spécifie que pam_ldap devrait toujours utiliser le premier mot de passe fournis dans la pile d'authentification
try_first_pass Spécifie que pam_ldap devrait d'abord essayer le premier mot de passe fournis dans la pile d'authentification, puis de demander à l"utilisateur le mot de passe LDAP si l'authentification échoue.
ignore_unknown_user Spécifie que pam_ldap devrait retourner PAM_IGNORE pour les utilisateurs non présents dans l'annuaire.
ignore_authinfo_unavail Spécifie que pam_ldap devrait retourner PAM_IGNORE s'il ne peut contacter le serveur LDAP
no_warn Spécifie que les messages d'alerte ne devraient pas être propagés dans l'application PAM
use_authok Identique à use_first_pass pour le changement de mot de passe uniquement

06 octobre 2010

PAM_BUF_ERR erreur tampon mémoire
PAM_SERVICE_ERR argument malformé
PAM_SUCCESS succès
PAM_USER_UNKNOWN utilisateur inconnu

Exemples

Ajouter cette ligne dans /etc/pam.d/login pour indiquer que l'utilisateur a de nouveau mails quand il se log sur le système
session optional pam_mail.so standard

06 octobre 2010

pam_mkhomedir

Créer un répertoire home

ce module crée un répertoire home utilisateur s'il n'existe pas quand la session commence. Cela permet aux utilisateurs d'être présent dans la base central (tel que NIS, kerberos ou LDAP) sans utiliser un système de fichier distribué ou en pré-créant un grand nombre de répertoires. Le répertoire squelette (généralement /etc/skel/) est utilisé pour copier les fichiers par défaut et définir également un umask pour l'utilisateur.

OPTIONS

silent N'affiche pas d'information
skel=/path/to/skel/directory Spécifie le répertoire squelette
umask Spécifie le masque de création de fichiers

Valeurs retournées

PAM_BUF_ERR Erreur de tampon mémoire
PAM_CRED_INSUFFICIENT insufficient credentials to access authentification data
PAM_PERM_DENIED Pas assez de permission pour créer le nouveau répertoire ou lire le dossier squelette
PAM_USER_UNKNOWN utilisateur inconnu
PAM_SUCCESS variables d'environnement définis

Exemples

un exemple du fichier /etc/pam.d/login
auth requisite pam_securetty.so
auth sufficient pam_ldap.so
auth required pam_unix.so
auth required pam_nologin.so
account sufficient pam_ldap.so
account required pam_unix.so
password required pam_unix.so
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
session required pam_unix.so
session optional pam_lastlog.so
session optional pam_mail.so standard

06 octobre 2010

pam_motd

Afficher le fichier motd

pam_motd permet d'afficher le contenu d'un fichier motd une fois loggé avec succès. par défaut /etc/motd. La taille du message est limitée à 64Ko. Ne fournit que le type de module session.

Valeurs retournées

PAM_IGNORE c'est la seule valeur retournée par ce module

Exemples

pam_permit

Permet de toujours autoriser l'accès

Dans le cas d'une authentification, le nom d'utilisateur est nobody si l'application n'est fournis pas un. Ce module est dangereux.

Exemples

Ajouter cette ligne dans les entrées other pour désactiver la gestion des comptes, mais continue de permettre aux utilisateurs de se logger
account required pam_permit.so

12 février 2012

pam_pkcs11

Module PAM d'authentification via une librairie PKCS #11

Module PAM pour faire de l'authentification au moyen d'un certificat X509 au travers d'une librairie PKCS #11. Pour la vérification des certificats utilisateurs, le certificat de l'autorité stocké localement et la CRL en ligne ou locale sont utilisés. Les modules PKCS #11 doivent remplir les prérequis de RSA Asymmetric Client Signing Profil. Pour permettre au propriétaire d'un certificat de se connecter, pam_pkcs11 utilise des modules appelés des mappers, qui effectuent des mappages cert-to-login.

Configurer le package

1. créer le répertoire de base /etc/pam_pkcs11/
2. Copier ${base}/etc/pam_pkcs11.conf.example dans /etc/pam_pkcs11/ et le renommer en /etc/pam_pkcs11/pam-pkcs11.conf
3. créer /etc/pam_pkcs11/crls/ et /etc/pam_pkcs11/cacerts/. Le répertoire tools/ fournis un outil pkcs11_make_hask_link qui peut être utilisé pour créer les fichiers de hash pour chaque fichier certificat et crl valide.
4. Choisir un ou plusieurs mappers à installer, les configurer.
5. Éditer et configurer /etc/pam.d/xxx
6. Utiliser pkcs11_inspect et pklogin_finder pour voir si vous pouvez lire le certificat et effectuer un mappage correct
7. tester un login.

Configurer pam_pkcs11

la configuration de pam-pkcs11 se fait en 2 étapes:
1. configurer pam-pkcs11
2. Configurer les options PAM.

Vous devez connaître

- quel module PKCS #11 vous allez utiliser, et son fichier
- quels mappers vous voulez et comment le créer et l'éditer
- Les fichiers de l'authorité de certification et le fichier de révocation
- Une liste d'utilisateurs autorisés à se connecter, et leur certificats correspondant.

Spécifier la CRL et la CA

pam-pkcs11 a besoin d'une liste d'authorité de certification reconnue pour valider l'utilisateur. Celà s'applique également à la CRL :

1. Créer les répertoire ca_dir et crl_dir en accord avec le fichier de configuration
2. Copier les certificats de la CA au format DER ou PEM
3. Créer un hash link vers les certificats CA, fournis avec pkcs11_make_hash_link. Noter que openSSL doit être installé :
cd /etc/pam_pkcs11/cacerts
/usr/bin/pkcs11_make_hash_link
4. Répéter la procédure pour la CRL
5. Sélectionner la stratégie de vérification de certificat (cert_policy)

NOTE : Du à des limitations de librairie OpenSSL, les certificats de la CA doivent résider dans le système de fichier local.

Un fichier de map a la syntaxe suivante:
Certificate1 data -› login1
Certificate2 data -› login2
Certificate3 data -› login3
Ce fichier est parsé du début àla fin et la première occurence qui match est retournée.

Configuration PAM

Configurer les fichiers pam.d

auth sufficient pam_pkcs11.so ...

OPTIONS

debug mode debug
err_display_time Secondes à attendre après un message d'erreur pour lire le message
config_file Spécifier le fichier de configuration (défaut : /etc/pam_pkcs11/pam_pkcs11.conf)
nullok Autorise les mots de passe vide
use_first_pass Ne demande pas le mot de passe à l'utilisateur, mais le prend depuis le PAM_items.
try_first_pass Ne demande pas le mot de passe à l'utilisateur à moins que PAM_(OLD)AUTHOK ne soit pas mis.
use_authok Comme try_first_pass mais échoue si le nouveau PAM_AUTHOK n'a pas été précédemment mis.
pkcs11_module=‹file› Nom de fichier du module PKCS11 (défaut : /etc/pam_pkcs11/pkcs11_module.so)
slot_num=‹nb› Numéro de slot à utiliser (défaut = 0 = utiliser le premier slot disponible)
ca_dir=‹path› Répertoire contenant les certificats CA (défault : /etc/pam_pkcs11/cacerts/)
crl_dir=‹path› Répertoire contenant la CRL (défault : /etc/pam_pkcs11/crls/)
cert_policy=none, ca, signature, crl_online, crl_offline, crl_auto Spécifier la stratégie de vérification par défaut.

Utiliser la fonction d'auto-détection de LOGIN

Depuis pam-pkcs11-0.4.2 pam-pkcs11 peut déduire le username depuis le certificat utilisateur sans utiliser le login prompt.

Quand pam_get_user() retourne null ou une chaîne vide, pam-pkcs11 va alors utiliser la fonction ’find’ du mapper au lieu du match normal. Si le finder retourne un succès, le username est définit avec pam_set_item(PAM_USER) et PAM_AUTH_OK est retourné.

Il y’a 2 manières d’utiliser cette fonctionnalité :
a. Patcher gdm et login pour détecter la présence d’un carte et retourner null comme nom d’utilisateur
b. Utiliser une version non patchée et entrée un espace pour login et entrée pour gdm.

12 février 2012

pam_pkcs11.conf

fichier de configuration pour pam_pkcs11

   Le fichier de configuration utilise la librairie scconf. Les paramètres et données sont groupées dans des blocks. ils peuvent être imbriqués.

Un fichier de configuration pam_pkcs11 ressemble à:
pam-pkcs11
    global options
    [...]
    use_pkcs11_module = pkcs11 module to be used
    pkcs11_module module1 {
        module1 specific options
    }
    pkcs11_module module2 {
        module2 specific options
    }
    [...]
    use_mappers = mapper1, mapper2,... ;
    mapper mapper1 {
        mapper1 specific options
    }
    mapper mapper2 {
        mapper2 specific options
    }
    [...]
    mapper mapperN {
        mapperN specific options
    }
}

Exemple de fichier pam_pkcs11.conf
pam_pkcs11 {
    nullok = true ; # Allow empty passwords
debug = true ; # Enable debugging support.
    use_first_pass = false ; # Do not prompt for the passwords but take them from the PAM_ items instead
    try_first_pass = false ; # Do not prompt for the passwords unless PAM_(OLD)AUTHTOK is unset.
    use_authtok = false ; # Like try_first_pass, but fail if the new PAM_AUTHTOK has not been previously set (intended for stacking password modules only).
    use_pkcs11_module = opensc ; # Filename of the PKCS #11 module. The default value is "default"

pkcs11_module opensc {
    module = /usr/lib/opensc-pkcs11.so ;
    description = "OpenSC PKCS#11 module" ;
    slot_description = "none" ; # spécifier le slot à utiliser. préférer cette option à slot_num.
    # slot_num = 0 ; # spécifier soit slot_description, soit slot_num.
    ca_dir = /etc/pam_pkcs11/cacerts ; # répertoire contenant les certificats de l’autorité au format pem ou asn1 oui des liens hash.
    crl_dir = /etc/pam_pkcs11/crls ; # répertoire contenant la CRL offline
    support_threads = false ; # certaines librairies supportent le multi-thread
    cert_policy = ca,signature ; # définis la vérification de certificat
    # none aucune vérification
    # ca vérfication de la CA
    # crl_online télécharge la CRL
    # crl_offline utilise la crl offline
    # crl_auto tente d’abord la online, puis la offline
    # signature vérifie la signature
    token_type = "Smart card" ; # spécifie le type de token. sera utilisé dans le message de prompt.
    pkcs11_module etoken { # Aladdin eTokenPRO 32
        module = /usr/local/lib/libetpkcs11.so
        description = "Aladdin eTokenPRO-32" ;

        slot_num = 0 ;
        support_threads = true ;
        ca_dir = /etc/pam_pkcs11/cacerts ;
        crl_dir = /etc/pam_pkcs11/crls ;
        cert_policy = ca,signature ;
    }
    pkcs11_module nss { # NSS (Network Security Service) config
        nss_dir = /etc/ssl/nssdb ;
        crl_policy = none ;
    }
    pkcs11_module default { # Default pkcs11 module
        module = @libdir@/pam_pkcs11/pkcs11_module.so ;
        description = "Default pkcs#11 module" ;
        slot_num = 0 ;
        support_threads = false ;
        ca_dir = /etc/pam_pkcs11/cacerts ;
        crl_dir = /etc/pam_pkcs11/crls ;
        cert_policy = none ;
    }
    use_mappers = digest, cn, pwent, uid, mail, subject, null ;    # spécifie les mappers à utiliser:
        # subject    Sujet du certificat
        # pwent     CN ou gecos
        # ldap        mapper LDAP
        # opensc    Cherche le certificat dans ${HOME}/.eid/authorized_certificates
        # openssh    Cherche la clé public du certificat dans ${HOME}/.ssh/authorized_keys
        # mail        compare le champs email du certificat
        # ms        Utilise l’UPN
        # krb        Compare avec le Kerberos Principal Name
        # cn        Compare le CN
        # uid        Compare l’UID
        # digest    Certificat Digest
        # generic    Contenu définis par l’utilisateur
        # null        blind access/deny mapper
    mapper_search_path = @libdir@/pam_pkcs11 ;    # chemin des module mapper.
    mapper subject {                # Mapper le sujet du certificat pour le login, fournis dans un fichier sous la forme "Subject -› login"
        debug = false ;
        #module = @libdir@/pam_pkcs11/subject_mapper.so ;
        module = internal ;
        ignorecase = false ;
        mapfile = file :///etc/pam_pkcs11/subject_mapping ;
    }
    mapper pwent {                # map le CN à getpwent()
        debug = false ;
        ignorecase = false ;
        module = internal ;
        #module = @libdir@/pam_pkcs11/pwent_mapper.so ;
    }
    mapper ldap {                # mapper d’annuaire
        debug = false ;
        module = @libdir@/pam_pkcs11/ldap_mapper.so ;
        ldaphost = "" ;                 # fqdn du serveur ldap (utilise l’URI ldap pour en spécifier plusieurs)
        ldapport = ;                 # port du serveur ldap s’il n’est pas donné dans l’URI
        URI = "" ;                # list d’URI utilisés dans l’ordre
        scope = 2 ;                 # scope de recherche : 0 (base), 1 (one), 2 (sub)
        binddn = "cn=pam,o=example,c=com" ;     # DN du bind. doit avoir un accès en lecture
        passwd = "" ;                 # password du binddn
        base = "ou=People,o=example,c=com" ;    # base de recherche
        attribute = "userCertificate" ;        # attribut qui contient le certificat
        filter = "(&(objectClass=posixAccount)(uid=%s))" # Filtre de recherche pour les entrées utilisateurs ( doit seulement laisser passer l’entrée pour le login utilisateur )
        ssl = tls                # off (désactiver), tls (activer tls), on|ssl (activer ssl)
        tls_randfile =                 # chemin de la source entropie
        tls_cacertfile = /etc/ssl/cacert.pem    # Chemin vers le certification pour l’authentification du pair
        tls_cacertdir =                # Répertoire contenant les certificats X509 pour l’authentification du pair
        tls_checkpeer = 0            # 0 ou 1. spécifie de vérifier le certificat.
        tls_ciphers =                 # Chiffrement à utiliser
        tls_cert = ...                # Chemin du fichier contenant le certificat local pour l’authentification TLS client
        tls_key = ...                # Chemin du fichier contenant la clé privée pour l’authentification TLS client
    }
    mapper opensc {                 # recherche les certificats depuis $HOME/.eid/autorized_certificates qui match l’utilisateur
        debug = false ;
        module = @libdir@/pam_pkcs11/opensc_mapper.so ;
    }
    mapper openssh {                # Cherche les clés publique dans $HOME/.ssh/authorized_keys qui match l’utilisateur
        debug = false ;
        module = @libdir@/pam_pkcs11/openssh_mapper.so ;
    }
    mapper mail {                # Compare le champ email du certificat
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/mail_mapper.so ;
        mapfile = file :///etc/pam_pkcs11/mail_mapping ;    # Déclarer un fichier de map, ’empty’ ou vide pour ne pas utiliser de fichier de map
        ignorecase = true ;            # ignorer la casse
        ignoredomain = false ;            # Vérifie le domaine mx. en utilisant un fichier de map, cette option est ignorée.
    }
    mapper ms {                    # utilise l’UPN (login@AD_domain)
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/ms_mapper.so ;
        ignorecase = false ;
        ignoredomain = false ;
        domain = "domain.com" ;
    }
    mapper krb {                # Compare avec le principal kerberos
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/krb_mapper.so ;
        ignorecase = false ;
        mapfile = "none" ;
    }
    mapper cn {                    # le CN est le login
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/cn_mapper.so ;
        ignorecase = true ;
        # mapfile = file :///etc/pam_pkcs11/cn_map ;
        mapfile = "none" ;
    }
    mapper uid {                # l’uid (s’il existe) est le login
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/uid_mapper.so ;
        ignorecase = false ;
        mapfile = "none" ;
    }
    mapper digest {                # Evalue le digest du certificat et le map dans un fichier
        debug = false ;
        module = internal ;
        # module = @libdir@/pam_pkcs11/digest_mapper.so ;
        algorithm = "sha1" ;             # Algorithme utilisé pour évaluer le digest ("null","md2","md4","md5","sha","sha1","dss","dss1","ripemd160")
        mapfile = file :///etc/pam_pkcs11/digest_mapping ;
        # mapfile = "none" ;
    }
    mapper generic {                # mapper de contenu générique
        debug = true ;
        #module = @libdir@/pam_pkcs11/generic_mapper.so ;
        module = internal ;
        ignorecase = false ;            # ignirer la casse
        cert_item = cn ;             # ( "cn" , "subject" , "kpn" , "email" , "upn" ou "uid" )
        mapfile = file :///etc/pam_pkcs11/generic_mapping ;
        use_getpwent = false ;            # utiliser petpwent() pour mapper le login
    }
    mapper null {                # Pas de mappage. Quand un utilisateur match à NULL ou nobody
        debug = false ;
        # module = @libdir@/pam_pkcs11/null_mapper.so ;
        module = internal ;
        default_match = false ;            # match toujours (true) ou échoue toujours (false)
        default_user = nobody ;            # en cas de match, retourner cet utilisateur
    }
}

06 octobre 2010

PAM_AUTH_ERR Ne peut pas récupérer ou définir de contexte valide
PAM_SUCCESS le contexte de sécurité a été définis
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

auth required pam_unix.so
session required pam_permit.so
session optional pam_selinux.so

06 octobre 2010

pam_shells

Vérifie les shells de login valides

pam_shells autorise l'accès au système si le shell utilisateur est listé dans /etc/shells. Il vérifie également si /etc/shells est un fichier texte et n'est pas writable. Ne fournis que les type de module auth et account.

Valeurs retournées

PAM_AUTH_ERR l'accès a été refusé
PAM_SUCCESS l'accès est autorisé
PAM_SERVICE_ERR le module n'est pas capable d'obtenir le nom de l'utilisateur

Exemples

auth required pam_shells.so

06 octobre 2010

pam_succeed_if

Test les caractéristiques des comptes

pam_succeed_if est conçu pour réussir ou non l'authentification en se basant sur les caractéristiques du compte de l'utilisateur. Une utilisation est de sélectionner si d'autres modules sont chargés en fonction de ce test.

OPTIONS

debug syslog les informations de debuggage
use_uid Évalue les conditions en utilisant le compte utilisateur de l'application au lieu de l'utilisateur qui s'authentifie
quiet mode silencieux
quiet_fail ne log pas les echecs
quiet_success ne log pas les réussites
audit syslog les utilisateurs inconnus

Conditions

Les conditions sont composés de 3 mots un champs, un test et une valeur de test.

field ‹ number
field ‹= number
field eq number
field ›= number
field › number
field ne number
field = string
field != string
field = glob
field in item:item :...
user ingroup group
user notingroup group
user innetgr netgroup
user notinnetgr group

Exemples

Pour émuler de principe de pam_wheel, excepté qu'il ne revient pas au group 0
auth required pam_succeed_if.so quiet user ingroup wheel
charge seulement les autres modules si l'UID est › 500
type [ default=1 success=ignore ] pam_succeed_if.so quiet uid › 500
type required othermodule.so arguments

07 octobre 2010

pam_tally2

Module compteur de login

   Ce module maintient un compteur de tentative d'accès, peut ré-initialiser ce compteur en cas de succès et peut refuser l'accès si trop de tentatives échouent.

  pam_tally2 est composé de 2 parties: pam_tally2.so et pam_tally2. Ce dernier est une application optionnelle qui peut être utilisé pour interroger et manipuler le fichier compteur. Il peut afficher le compteur de l'utilisateur, définir les compteurs individuels ou reset tous les compteurs Définir des compteurs élevés peut être utile pour bloquer les utilisateurs sans changer leur mot de passe. Par exemple, il peut être utile effacer tous les compteurs à minuit depuis un cron.

  Normalement, les tentatives échouées au compte root ne bloque pas ce compte, pour prévenir les DOS. Fournit les types de module auth et account.

Options globales

PAM_AUTH_ERR Authentification échouée
PAM_AUTHOK_RECOVERY_ERR Les informations d'authentification ne peut être récupérées
PAM_BUF_ERR Erreur de tampon mémoire
PAM_CONV_ERR Erreur de conversation
PAM_SERVICE_ERR Erreur dans le module
PAM_SUCCESS succès
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

auth sufficient pam_userdb.so icase db=/etc/dbtest.db

11 novembre 2010

pam_warn

Log tous les éléments PAM

pam_warn est un module qui log le service, terminal, user, remote user et remote host dans syslog(3). Ce module retourne toujours PAM_IGNORE. Ce module fournis tous les types de module.

Exemples

Si on a pas d'entrée de config pour un service, l'entrée other est utilisé. Par sécurité on refuse et on log tout
other auth required pam_warn.so
other auth required pam_deny.so
other account required pam_warn.so
other account required pam_deny.so
other password required pam_warn.so
other password required pam_deny.so
other session required pam_warn.so
other session required pam_deny.so

11 novembre 2010

pam_wheel

Permet l'accès root aux membres du groupe wheel

pam_wheel permet un accès root au système si l'utilisateur est un membre du groupe wheel. Si aucun groupe avec ce nom n'existe, le module utilise le groupe avec l'ID de groupe 0. Fournit les types de module auth et account.

OPTIONS

debug Affiche des informations de debuggage
deny Renverse le sens de l'opération auth: si l'utilisateur essaye d'avoir l'accès UID 0 et est membre du groupe wheel, l'accès est refusé. si l'utilisateur n'est pas dans le groupe, retourne PAM_IGNORE.
group=name au lieu de vérifier les groupes 0 ou wheel, utilise le nom du groupe pour effectuer l'authentification
root_only ne vérifie que l'appartenance au groupe wheel
trust retourne PAM_SUCCESS au lieu de PAM_IGNORE si l'utilisateur est un membre du groupe wheel
use_uid La vérification de l'appartenance au groupe wheel est faite avec l'uid courant au lieu de l'original. (utile en passant avec su d'un compte à un autre)

Valeurs retournées

PAM_AUTH_ERR Erreur d'authentification
PAM_BUF_ERR Erreur de tampon mémoire
PAM_IGNORE La valeur retournée devrait être ignorée par PAM
PAM_PERM_DENY Permission refusée
PAM_SERVICE_ERR Ne peut pas déterminer le nom de l'utilisateur
PAM_SUCCESS succès
PAM_USER_UNKNOWN Utilisateur inconnus

Exemples

Le compte root a accès par défaut (rootok), seul les membres du groupe wheel peuvent devenir root, mais l'authentification UNIX non-root s'applique
su auth sufficient pam_rootok.so
su auth required pam_wheel.so
su auth required pam_unix.so

11 novembre 2010

pam_xauth

Forward xauth keys between users

pam_xauth est conçu pour forwarder les clés xauth (parfois appelées cookies) entre les utilisateurs. Sans pam_xauth, quand xauth est activé et qu'un utilisateur utilise su pour obtenir les privilèges d'un autre utilisateur, cet utilisateur n'est plus capable d'accéder à l'affichage X de l'utilisateur parce que le nouvel utilisateur n'a pas la clé necessaire pour accéder à l'affichage. pam_xauth résoud le problème en forwardant la clé. Celà veut dire par exemple, que quand vous lancez su depuis une session xterm, vous être capable de lancer des programmes X sans explicitement utiliser la commande xauth ou les fichier ./Xauthority.

pam_xauth ne forward les clés seulement si xauth peut lister une clé connectée à la varialbe d'environnement DISPLAY. Le contrôle d'accès est fournis par /.xauth/export dans le répertoire home de l'utilisateur qui invoke et /.xauth/import dans le home de l'utilisateur cible.

OPTIONS

debug Affiche des informations de debuggage
xauthpath=/path/to/xauth Spécifie le chemin du programme xauth (par défaut /usr/X11R6/bin/xauth, /usr/bin/xauth ou /usr/bin/X11/xauth)
systemuser=UID Spécifie le plus haut UID qui sera assumé devenir l'utilisateur système. pam_xauth varefuser de forwarder aux utilisateurs avec un UID inférieur ou égal à ce nombre, excépté pour root et le "targetuser" si spécifié.
targetuser=UID Spécifie un simple UID cible quiest exempt de la vérification systemuser

Ne fournis que le type de module session

Valeurs retournées

PAM_BUF_ERR Erreur de tampon mémoire
PAM_PERM_DENIED permission refusée par le fichier import/export
PAM_SESSION_ERR Ne peut pas déterminer le nom d'utilisateur, l'UID ou accéder au hom de l'utilisateur
PAM_SUCCESS succès
PAM_USER_UNKNOWN utilisateur inconnu

Exemples

Exemple pour /etc/pam.d/su pour forwarder les clés xauth entre les utilisateurs
session optional pam_xauth.so

07 juillet 2014

rfc4120

Le protocole Kerberos v5

Le protocole Kerberos

   Kerberos fournit un moyen de vérifier les identités des principaux sur un réseau non-sûr. Ceci est fait sans s'appuyer sur la confiance des assertions par le système hôte, sans confiance basé sur les adresses de l'hôte, sans nécessiter de sécurité physique des hôtes sur le réseau, et en assumant qui les paquets sur le réseau peuvent être lus, modifiés et insérés. Kerberos effectue une authentification dans ces conditions en tant que service d'authentification tiers en utilisant la cryptographie conventionnelle. Les extensions Kerberos peuvent permettre l'utilisation de chiffrements à clé publique durant certaines phases de l'authentification.

   Le processus d'authentification de base de Kerberos se déroule comme suit: Un client envoie une demande au serveur d'authentification (AS) pour les accréditations pour un serveur donné. l'AS répond avec ces accréditations, chiffrés avec la clé du client. les accréditations consistent d'un ticket pour le serveur et une clé de chiffrement temporaire (souvent appelé un clé de session). Le client transmet le ticket ( qui contient l'identité du client et une copie de la clé de session, le tout chiffré avec la clé du serveur) au serveur. La clé de session (maintenant partagée par le client et le serveur) est utilisé pour authentifier le client et peut optionnellement être utilisé pour authentifier le serveur. Il peut être utilisé également pour chiffrer d'autres communications entre les 2 parties ou pour échanger une clé de sous-session séparée à utiliser pour chiffrer d'autres communications.

   L'implémentation du protocole de base consiste d'un ou plusieurs serveurs d'authentification fonctionnant sur un hôte sécurisé. Les serveurs d'authentification maintiennent une base de données de principaux et leur clés secrète. Pour ajouter l'authentification à ses transactions, une application réseaux ajoute des appels à la librairie Kerberos directement ou via GSS-API. Ces appels résultent en la transmission des messages nécessaires pour accomplir l'authentification.

   Le protocole de base consiste de nombreux sous-protocoles ( ou échanges ). Il y a 2 méthodes de base pour lequel un client peut demander des accréditations. Dans la première approche, le client envoie une requête en texte clair pour le serveur désiré au serveur AS. La réponse est envoyée chiffrée avec la clé secrète du client. Généralement cette requête est pour un TGT (Ticket-Granting Ticket), qui peut être utilisé ultérieurement avec le TGS (Ticket-Granting Server). Dans la seconde méthode, le client envoie une requête au TGS. Le client utilise de TGT pour s'authentifier lui-même auprès du TGS de la même manière que s'il avait contacté un serveur d'application qui nécessitait une authentification Kerberos. La réponse est chiffrée dans la clé de session du TGT. Bien que la spécification du protocole décrive l'AS et le TGT comme des serveurs séparés, en pratique il sont souvent implémentés comme points d'entrée différents du protocole dans seul serveur Kerberos.

   Une fois obtenues, les accréditations peuvent être utilisés pour vérifier l'identité des principaux dans une transaction, pour s'assurer de l'intégrité des messages échangés entre eux, ou pour préserver la confidentialité des messages. L'application est libre de choisir qu'elle protection est nécessaire.

   Pour vérifier les identités des principaux dans une transaction, le client transmet le ticket au serveur d'application. Parce que le ticket est envoyé en clair (de partie sont chiffrés, mais ce chiffrement ne déjoue pas la répétition) et peut être intercepté et réutilisé par un attaquant, des informations additionnelles sont envoyées pour prouver que le message a bien pour origine le principal à qui le ticket a été fourni. Cette information ( appelée l'authentifiant) est chiffrée dans la clé de session et inclus un horodatage. l'horodatage prouve que le message a été récemment envoyés et n'est pas rejouée. Chiffrer l'authentifiant dans la clé de session prouve qu'il a été généré par un partie possédant la clé de session. Vu que personne excepté le principal et le serveur ne connaît la clé de session ( qui n'est jamais envoyée sur le réseau en clair ), cela garantis l'identité du client.

   L'intégrité des messages échangés entre les principaux peut également être garantis en utilisant la clé de session ( passée dans le ticket et contenus dans les accréditations ). Cette approche fournis la détection contre les attaques à répétition et les attaques par modification de flux. C'est accomplis en générant et en transmettant un checksum à l'épreuve des collisions du message du client, entrée avec la clé de session. La confidentialité et l'intégrité des messages échangés entre les principaux peuvent êrte sécurisé en chiffrant le données en utilisant la clé de session contenus dans le ticket ou la clé de sous-session trouvée dans l'authentifiant.

   les échanges d'authentification mentionnés plus haut nécessitent un accès lecture seule à la base de données Kerberos. Parfois, cependant, les entrées dans la base de données doit être modifiée, par exemple pour ajouter des principaux ou changer la clé d'un principal. Pour cela on utilise un protocole entre un client et un serveur Kerberos tiers, le serveur d'administration Kerberos (KADM). Il y a aussi un protocole pour maintenir plusieurs copies de la base Kerberos. Aucun de ces protocoles n'est décris dans ce document.

Fonctionnement inter-domaine

   Le protocole Kerberos est conçus pour opérer au delà des limites organisationnelle. Un client dans une organisation peut être authentifié pour un serveur dans une autre organisation. Chaque organisation souhaitant utiliser un serveur Kerberos établis son propre "domaine" (realm). Le nom de ce domaine dans lequel un client est enregistré fait partie du nom du client et peut être utilisé par le service final pour décider d'honorer ou non une requête.

   En établissant des clé inter-domaine, les administrateurs de 2 domaines peuvent permettre à un client authentifié dans le domaine local de prouver son identité aux serveurs dans les autres domaines. Les échanges de clé inter-domaines ( une clé séparée peut être utilisé pour chaque direction ) enregistrent le service d'allocation de ticket de chaque domaine comme un principale dans l'autre domaine. Un client est ainsi capable d'obtenir un TGT pour le service d'allocation de ticket du royaume distant depuis le domaine local. Quand ce TGT est utilisé, le service d'allocation de ticket distant utilise la clé inter-domaine ( qui généralement diffère de sa propre clé TGS normale ) pour déchiffrer le TGT; ainsi il est certain que le ticket a été fournis par le TGS du client. Les tickets fournis par le service d'allocation de ticket distant va indiquer au service final que le client a été authentifié depuis un autre domaine.

   Sans opération inter-domaine et avec les permissions appropriées, le client peut l'enregistrement d'un principal nommé séparément dans en royaume distant et engager un échange normal avec ce domaine. Cependant, même pour un petit nombre de clients, cela devient lourd à gérer, et méthodes plus automatiques sont nécessaires.

   Un domaine est dit communiquer avec un autre si les 2 domaines partagent un clé inter-domaine, ou si le domaine local partage une clé inter-domaine avec un domaine intermédiaire qui communique avec le domaine distant. Un chemin d'authentification est la séquence de domaines intermédiaire qui servent de transit d'un domaine à un autre.

   Les domaines peuvent être organisés hiérarchiquement. Chaque domaine partage une clé avec son parent et une clé différente avec chaque enfant. Si une clé inter-domaine n'est pas directement partagée par 2 domaines, l'organisation hiérarchique permet de construire facilement un chemin d'authentification. Si une organisation hiérarchique n'est pas utilisée, il peut être nécessaire de consulter une base de données pour construire un chemin d'authentification entre les domaines.

   Bien que les domaines sont typiquement hiérarchiques, les domaines intermédiaire peuvent être bypassés pour effectuer une authentification inter-domain au travers d'un chemin alternatif. Il est important pour le service final de connaître les domaines traversés. Pour simplifier cette décision, un champ dans chaque ticket contient les noms des domaines qui ont servis dans l'authentification du client.

   Le serveur d'application est responsable au final d'accepter ou non l'authentification et devrait vérifier le champ de transit. Le serveur d'application peut choisir de s'appuyer sur le KDC pour la vérification de ce champ. Le KDC du serveur d'application va mettre le flag TRANSITED-POLICY-CHECKED dans ce cas. Les KDC des domaines intermédiaire peuvent également vérifier ce champ vu qu'ils fournissent des TGT pour d'autre domaines, mais ils sont encouragés à ne pas le faire. Un client peut demander que les KDC ne vérifient pas ce champ en mettant le flag DISABLE-TRANSITED-CHECK. Les KDC devraient honorer ce flag.

Choisir un principal avec lequel communiquer

   Le protocole Kerberos fournis un moyen de vérifier que l'entité avec laquelle il communique est la même que celle enregistrée avec le KDC en utilisant l'identité revendiquée (le principal). Il est nécessaire de déterminer que cette identité correspond à l'entité avec laquelle on tente de communiquer.

   Quand des données appropriées ont été échangées en avance, l'application peut effectuer cette détermination syntaxiquement basé sur la spécification du protocole de l'application, les informations fournies par l'utilisateur, et les fichiers de configuration. Par exemple, le nom principal du serveur (incluant le domaine) pour un serveur telnet peut être dérivé du nom d'hôte spécifié par l'utilisateur (depuis la ligne de commande), le préfixe "host/" spécifié dans la spécification du protocole de l'application, et un mappage à un domaine Kerberos dérivé syntaxiquement depuis la partie domaine du nom d'hôte et des informations spécifiées depuis la base de domaines Kerberos locale.

   On peut également s'appuyer sur les tiers de confiance qui font cette détermination, mais seulement quand les données obtenues depuis un tiers sont convenablement protégées en intégrité lorsqu'elles résident sur le serveur du tiers de confiance et lors de leur transmission. Par exemple, on ne devrait pas pas se fier à un enregistrement DNS non protégé pour

   Les implémentations de Kerberos et les protocoles basés sur Kerberos ne doivent pas utiliser de requêtes DNS non sécurisés pour canoniser les composants du nom d'hôte des noms de principal de service. Dans un environnement sans service de nom sécurisé, les auteurs d'application peuvent ajouter un nom de domaine configuré statiquement pour les noms d'hôtes non qualifiés avant de passer ce nom aux mécanismes de sécurité. Les facilités de service de nom sécurisés, si disponible, peuvent être trustés pour la canonisation de nom d'hôte, mais une telle canonisation par le client ne devrait pas être requise par les implémentations du KDC.

Authorisation

   En tant que service d'authentification, Kerberos fournis un moyen de vérifier l'identité des principaux sur un réseau. L'authentification est généralement la première étape dans le processus d'autorisation, déterminant si un client peut utiliser un service, à quels objets le client à accès, et le type d'accès permis pour chacun. Kerberos ne fournis pas par lui-même d'autorisation. La possession d'un ticket client pour un service fournis uniquement l'authentification de ce client pour ce service, et en l'absence de procédure d'autorisation, une application ne devrait pas lui autoriser l'utilisation de ce service.

   Des méthodes d'autorisation séparés peuvent être implémentés comme fonctions de contrôle d'accès spécifique à l'application et peut utiliser des fichiers sur le serveur d'application, sur des accréditations d'autorisation fournis séparément tels que ceux fournis dans les proxys. Ces accréditations peuvent être embarqués dans une donnée d'authentification du ticket lorsqu'il est encapsulé par l'élément de données d'autorisation produit par le KDC.

   Les applications ne devraient pas accepter la délivrance d'un ticket de service par le serveur Kerberos (même par un serveur Kerberos modifié) comme accordant l'autorisation d'utiliser le service, car de telles applications peuvent devenir vulnérables au détournement de cette vérification d'autorisation dans un environnement où sont fournies d'autres options pour l'authentification d'application, ou si elles interopèrent avec d'autres KDC.

Étendre Kerberos sans rupture d'intéropérabilité

   Avec la base d'implémentation de Kerberos déployée grandissante, étendre Kerberos devient de plus en plus important. Malheureusement, certaines extensions du protocole existant créent des problèmes d'intéropérabilité à cause de l'incertitude au regard du traitement de certaines options d'extentions par certaines implémentations.

   Kerberos fournis un mécanisme général pour l'extensibilité du protocole. Certains messages du protocole contiennent des trous typés -- des sous-messages qui contiennent une chaîne d'octet et un entier qui définis comment interpréter cette chaîne d'octet. Les types entier sont enregistrés centralement, mais ils peuvent être utilisés par les vendeurs d'extension et pour les extensions standardisés.

   Dans ce document, le mot extension réfère à une extension en définissant un nouveau type à insérer dans un trou typé existant dans un message du protocole. Il ne réfère pas à l'extension en ajoutant de nouveaux champs ASN.1, sauf mention.

Envoyer des messages extensibles

If faut s'assurer que les anciennes implémentations peuvent comprendre les messages envoyés, même si elles ne comprennent pas une extension utilisée. À moins que l'emeteur sache qu'une extension est supportée, l'extension ne peut pas changer les sémantiques du coeur du message ou des extensions définies précédemment.

Par exemple, une extension incluant des information de clé nécessaire à déchiffrer la partie chiffrée d'un KDC-REP pourrait seulement être utilisé dans les situations où le receveur est connus pour supporter l'extension. Donc en définissant de tels extensions il est important de fournir une manière pour le receveur de notifier à l'envoyeur la prise en charge de l'extension. Par exemple dans le cas d'une extension qui change la clé de réponse de KDC-REP, le client pourrait indiquer la prise en charge de l'extension en incluant un élément padata dans la séquence AS-REQ. Le KDC ne devrait utiliser l'extension que si cet élément padata est présent dans le AS-REQ. Même si la politique exige l'utilisation de l'extension, il est préférable de retourner une erreur en indiquant que l'extension est exigée que d'utiliser l'extension alors que le receveur peut ne pas la prendre en charge.

Hypothèse sur l'environnement

Kerberos impose quelques hypothèses sur l'environnement dans lequel il peut fonctionner de façon appropriées, qui sont les suivantes:

- Les attaques DOS ne sont pas résolues avec Kerberos. Il y a des endroits dans le protocoles où un intrus peut empêcher une application de participer aux étapes d'authentification appropriées.
- Les principaux doivent garder secrètes leurs clés secrète. Si un intrus s'empare d'une manière un d'une autre de la clé d'un principal, il sera capable de se faire passer pour ce principal ou de se déguiser en n'importe quel serveur du principal légitime.
- Les attaques en devinant le mot de passe ne sont pas résolues par Kerberos. Si un utilisateur choisit un mot de passe faible, il est possible à un agresseur de monter avec succès une attaque de dictionnaire.
- Chaque hôte sur le réseaux doit avoir une horloge synchronisée à l'heure des autres hôtes. Cette synchronisation est utilisée pour réduire les besoins d'enregistrement des serveurs d'application lorsqu'ils refont effectivement la détection. Si les horloges sont synchronisées sur le réseaux, le protocole doit lui-même être synchronisé. Le degré d'approximation normal est de l'ordre de 5 minutes
- Les identifiants de principal ne sont pas recyclés à court terme. Un contrôle de mode d'accès normal utilise des ACL pour accorder les permissions à des principaux particuliers. Si une entrée d'acl périmée subsiste pour un principal supprimé et si l'identifiant du principal est réutilisé, le nouveau principal va hériter des droits spécifiés dans l'entrée d'acl périmée. On supprime ce problème en ne réutilisant pas les identifiants de principal.

Glossaire

Authentification Vérifier l'identité revendiquée par un principal
En-tête d'authentification Enregistrement qui contient un ticket et un authentifiant à présenter à un serveur au titre du processus d'authentification.
Chemin d'authentification Séquence de domaines intermédiaires traversés dans le processus d'authentification lors de la communication d'un domaine à l'autre.
Authentifiant Enregistrement contenant des informations dont on peut montrer qu'elles ont été générées récemment en utilisant la clé de session connue seulement du client et du serveur.
Autorisation Processus pour déterminer si un client a la permission d'utiliser un service, à quels objets le client a la permission d'accès et le type d'accès permis pour chacun.
Capacité Jeton qui accorde au porteur la permission d'accéder à un objet ou service. Dans Kerberos, ce peut être un ticket dont l'utilisation est restreinte par le contenu du champ de données d'autorisation, mais qui ne donne pas d'adresse réseau, avec la clé de session nécessaire pour utiliser le ticket.
Texte chiffré Résultat d'une fonction de chiffrement. Le chiffrement transforme le texte clair en texte chiffré
Client Processus qui utilise un service réseau au nom d'un utilisateur. Noter que dans certains cas, un serveur peut être lui-même un client de quelque autre serveur (par exemple, un serveur d'impression peut être un client d'un serveur de fichiers)
Accréditifs Un ticket plus la clé de session secrète nécessaire pour utiliser ce ticket avec succès dans un échange d'authentification
Type de chiffrement (etype) Associé à des données chiffrées; un type de chiffrement identifie l'algorithme utilisé pour chiffrer les données et est utilisé pour choisir l'algorithme approprié pour déchiffrer les données. Les étiquettes de type de chiffrement sont communiquées dans d'autres messages pour énumérer les algorithmes qui sont souhaités, pris en charge, préférés, ou permis en utilisation pour le chiffrement des données entre les parties. Cette préférence est combinée aux informations et politiques locales pour choisir l'algorithme à utiliser.
KDC (Key Distribution Center) Centre de distribution de clés. Service réseau qui fournit les tickets et les clés de sessions temporaires ; ou instance de ce service ou l'hôte sur lequel il fonctionne. Le KDC sert à la fois le ticket initial et les demandes de ticket d'allocation de ticket. La portion de ticket initial est parfois appelée serveur (ou service) d'authentification. La portion de ticket d'allocation de ticket est parfois appelée serveur (ou service) d'allocation de ticket.
Kerberos Nom donné au service d'authentification du Projet Athéna, protocole utilisé par ce service, ou code utilisé pour mettre en œuvre le service d'authentification. Le nom vient de celui du chien à trois têtes qui garde l'Hadès
Numéro de version de clé (kvno,Key Version Number) Étiquette associée aux données chiffrées qui identifie quelle clé a été utilisée pour le chiffrement lorsque une clé à longue durée associée à un principal change au fil du temps. Il est utilisé durant la transition vers une nouvelle clé de sorte que la partie qui déchiffre un message puisse dire si les données ont été chiffrées avec la vieille ou la nouvelle clé
Texte en clair Entrée dans une fonction de chiffrement ou sortie d'une fonction de chiffrement. Le déchiffrement transforme le texte chiffré en texte clair.
Principal Entité client ou serveur nommée qui participe à une communication réseau, avec un nom qui est considéré comme canonique.
Identifiant de principal Nom canonique utilisé pour identifier de façon univoque chaque différent principal.
Sceau Pour chiffrer un enregistrement contenant plusieurs champs de telle sorte que les champs ne puissent pas être remplacés individuellement sans connaissance de la clé de chiffrement ou sans laisser de traces d'altération.
Clé secrète Clé de chiffrement partagée par un principal et le KDC, distribuée en dehors des limites du système, avec une durée de vie longue. Dans le cas du principal d'un utilisateur humain, la clé secrète peut être déduite d'un mot de passe.
Serveur Principal particulier qui fournit une ressource aux clients réseau. Le serveur est parfois appelé serveur d'application.
Service Ressource fournie aux clients réseau; souvent fournie par plus d'un serveur (par exemple, un service de fichier distant)
Clé de session Clé de chiffrement temporaire utilisée entre deux principaux, avec une durée de vie limitée à la durée d'une seule "session" de connexion. Dans le système Kerberos, une clé de session est générée par le KDC. La clé de session est distincte de la sous-clé de session, décrite ci-après
Sous-clé de session Clé de chiffrement temporaire utilisée entre deux principaux, choisie et échangée par les principaux en utilisant la clé de session, et avec une durée de vie limitée à la durée d'une seule association. La sous-clé de session est aussi appelée sous-clé.
Ticket Enregistrement qui aide un client à s'authentifier auprès d'un serveur; il contient l'identité du client, une clé de session, un horodatage, et d'autres informations, toutes scellées en utilisant la clé secrète du serveur. Il ne sert qu'à authentifier un client lorsqu'il est présenté avec un authentifiant frais.

Utilisation et demandes de flags de ticket

Chaque ticket Kerberos contient un ensemble de flags utilisés pour indiquer les attributs de ce ticket. La plupart des flags peuvent être demandés par un client lorsque le ticket est obtenu; certains sont automatiquement activés et désactivés en fonction des besoins du serveur. À l'exception du flag INVALID, les clients doivent ignorer les flags qu'ils ne reconnaissent pas. Les KDC doivent ignorer les options KDC qui ne sont pas reconnus. Certaines mises en œuvre de la rfc1510 sont connues pour rejeter les options KDC si la demande a été rejetée alors qu'elle avait été envoyée avec des options ajoutées depuis la rfc1510. Comme les nouveaux KDC ignorent les options inconnues, les clients doivent confirmer que le ticket retourné satisfait leur besoins.

Noter qu'il n'est en général pas possible de déterminer si une option n'a pas été satisfaite parce qu'elle n'a pas été comprise ou si elle a été rejetée à cause de la configuration ou de la politique. Lors de l'ajout d'une nouvelle option au protocole Kerberos, les concepteurs devraient examiner si la distinction est importante pour leur option. Si elle l'est, il faut fournir un mécanisme pour que le KDC retourne une indication comme quoi l'option a été comprise mais rejetée, dans la spécification de l'option. Souvent dans de tels cas, le mécanisme doit être suffisamment tolérant pour permettre qu'une erreur soit retournée.

Ticket initial, pré-authentification, et matériel authentifié

Le flag INITIAL indique qu'un ticket a été produit en utilisant le protocole d'AS, plutôt que produit sur la base d'un TGT. Les serveurs d'application qui veulent demander la preuve de la connaissance de la clé secrète d'un client (par exemple, un programme à changement de mot de passe) peut insister pour que ce flag soit établi dans tous les tickets qu'il accepte, et peut donc être assuré que la clé du client a été récemment présentée au serveur d'authentification.

Les flags PRE-AUTHENT (pré-authentifié) et HW-AUTHENT (matériel-authentifié) donnent des informations supplémentaires sur l'authentification initiale, que le ticket en cours ait été produit directement (dans ce cas le flag INITIAL est établi) ou qu'il soit produit sur la base d'un TGT (le flag INITIAL n'est pas mis, mais PRE-AUTHENT et HW-AUTHENT sont ramenés du TGT).

Tickets invalides

Le flag INVALID indique qu'un ticket est invalide. Les serveur d'application doivent rejeter les tickets qui ont ce fjag. Un ticket postdaté sera toujours produit sous cette forme. Les tickets invalides doivent être validés par le KDC avant utilisation, en étant présentés au KDC dans une demande TGS avec l'option VALIDATE spécifié. Le KDC ne validera le ticket qu'après l'heure de début soit passée. La validation est exigée de sorte que les tickets postdatés qui ont été volés avant leur heure de début puissent être rendus invalides de façon permanente (grâce à un mécanisme de liste noire)

Tickets renouvelables

   Les applications peuvent désirer détenir des tickets qui soient valides pour de longues durées. Cependant, cela peut exposer leurs accréditifs à des menaces de vol. Utiliser simplement des tickets à courte durée de vie et en obtenir périodiquement de nouveaux exige que le client ait un accès à long terme à sa clé secrète, ce qui présente un risque encore plus grand. Les tickets renouvelables peuvent être utilisés pour atténuer les conséquences d'un vol. Les tickets renouvelables ont 2 heures d'expiration: la première est quand l'instance actuelle du ticket expire, et la seconde est la valeur permissible la plus tardive pour une heure d'expiration individuelle. Un client d'application doit périodiquement présenter au KDC un ticket renouvelable, avec l'option RENEW dans la demande.

   Le KDC va produire un nouveau ticket avec une nouvelle clé de session et une nouvelle heure d'expiration. Tous les autres champs du ticket sont laissés inchangés par le processus de renouvellement. Lorsque arrive l'heure d'expiration la plus tardive permissible, le ticket est expiré de façon permanente. À chaque renouvellement, le KDC peut consulter une liste noire pour déterminer si le ticket a été noté volé depuis son dernier renouvellement.

   Le flag RENEWABLE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut habituellement être ignoré par les serveurs d'application. Cependant, certains serveurs d'application particulièrement soigneux peuvent interdire les tickets renouvelables.

   Si un ticket renouvelable n'est pas renouvelé à son heure d'expiration, le KDC ne renouvellera pas le ticket. Le flag RENEWABLE est rétabli par défaut, mais un client peut demander qu'il soit établi en mettant l'option RENEWABLE dans le message KRB_AS_REQ. S'il est établi, le champ renew-till dans le ticket contient l'heure après laquelle le ticket ne peut plus être renouvelé.

Tickets postdatés

   Les applications peuvent parfois avoir besoin d'obtenir des tickets à utiliser beaucoup plus tard; par exemple, un système de soumission par lots aura besoin de tickets valides au moment où le lot est à traiter. Cependant, il est dangereux de détenir des tickets valides dans une file d'attente. Les tickets postdatés fournissent le moyen d'obtenir ces tickets du KDC au moment de la soumission de la tâche, mais de les laisser dormants jusqu'à ce qu'ils soient activés et validés par une demande ultérieure du KDC. Si un vol de ticket devait être rapporté dans l'intervalle, le KDC refuserait de valider le ticket.

   Le flag MAY-POSTDATE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut être ignoré par les serveurs d'application. Ce flag doit être établi dans un TGT afin de produire un ticket postdaté sur la base du ticket présenté. Il est rétabli par défaut; un client peut le demander en établissant l'option ALLOW-POSTDATE dans le KRB_AS_REQ. Ce flag ne permet pas à un client d'obtenir un TGT postdaté; les TGT postdatés ne peuvent être obtenus qu'en demandant le postdatage dans le KRB_AS_REQ. La durée de vie d'un ticket postdaté sera la durée de vie restante du TGT au moment de la demande. Sauf si l'option RENEWABLE est aussi établie, auquel cas elle peut être la durée de vie complète du TGT. Le KDC peut limiter la durée d'un ticket postdaté.

   Le flag POSTDATED indique qu'un ticket a été postdaté. Le serveur d'application peut vérifier le champ authtime dans le ticket pour voir quand est survenue l'authentification originale. Certains services peuvent choisir de rejeter ces tickets, ou ne les accepter que dans une certaine période après l'authentification originale. Lorsque le KDC produit un ticket POSTDATED, il sera aussi marqué INVALID, de sorte que le client d'application doit présenter le ticket au KDC pour validation avant utilisation.

Tickets mandatables et mandataires

   Il peut être nécessaire qu'un principal permette à un service d'effectuer une opération en son nom. Le service doit être capable de prendre l'identité du client, mais seulement pour un objet particulier. Un principal peut permettre à un service de faire cela en lui accordant un mandat (proxy).

   Le processus de délivrance d'un mandat en utilisant les flags proxy et proxiable est utilisé pour fournir des accéditifs à utiliser avec des services spécifiques. Bien que ce soit conceptuellement aussi un mandat, les utilisateurs qui souhaitent déléguer leur identité dans une forme utilisable à tous propos doivent utiliser le mécanisme de transmission de ticket décrit au paragraphes suivant pour transmettre un TGT.

   Le flag PROXIABLE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut être ignoré par les serveurs d'application. Lorsqu'il est établi, ce flag dit au TGS qu'il est d'accord pour produire un nouveau ticket (mais pas un TGT) avec une adresse réseau différente fondée sur ce ticket. Ce flag est établi s'il est demandé par le client à l'authentification initiale. Par défaut, le client demandera qu'il soit établi lorsqu'il demande un TGT, et gu'il soit rétabli lorsqu'il demande tout autre ticket.

   Ce flag permet à un client de passer au serveur proxy d'effectuer une demande distante en son nom (par exemple, un client de service d'impression peut donner mandat au serveur d'impression d'accéder aux fichiers du client sur un serveur de fichiers particulier afin de satisfaire à une demande d'impression).

   Afin de compliquer l'utilisation des accréditifs volés, les tickets Kerberos sont souvent valides pour les seules adresses réseau spécifiquement incluses dans le ticket, mais il est permis, comme option de politique de permettre des demandes et de produire des tickets sans aucune adresse réseau spécifiée. Lorsqu'il accorde un mandat, le client doit spécifier la nouvelle adresse réseau à partir de laquelle le mandat sera utilisé ou indiquer que le mandat est produit pour être utilisé sur toute adresse.

   Le flag PROXY est établi dans un ticket par le TGS lorsqu'il produit un ticket proxy. Les serveurs d'application peuvent vérifier ce flag; et optionnellement peuvent demander une authentification supplémentaire de la part de l'agent qui présente de mandat afin de fournir une trace d'audit.

Tickets transmissibles

   La transmission d'authentification est une instance de mandat dans laquelle le service qui est accordé est l'utilisation complète de l'identité du client. Exemple: Un usager qui s'enregistre sur un système distant et veut l'authentification pour travailler à partir de ce système comme si l'enregistrement était local.

   Le flag FORWARDABLE dans un ticket n'est normalement interprété que par le service d'allocation de tickets. Il peut être ignoré par les serveurs d'application. Le flag FORWARDABLE a une interprétation similaire à PROXIABLE, sauf que les TGT peuvent aussi être produits avec des adresses réseau différentes. Ce flag est ré-initialisé par défaut, mais les utilisateurs peuvent demander qu'il soit établi en mettant l'option FORWARDABLE dans la demande d'AS lorsqu'ils demandent le TGT initial.

   Le flag FORWARDED est mis par le TGS lorsqu'un client présente un ticket avec le flag FORWARDABLE mis et demande un ticket transmis en spécifiant l'option KDC FORWARDED et en fournissant un ensemble d'adresses pour le nouveau ticket. Il est aussi établi dans tous les tickets produits sur la base de tickets ayant le flag FORWARDED mis. Les serveurs d'application peuvent choisir de traiter les tickets FORWARDED différemment.

   Si les tickets sans adresse sont transmis d'un système à un autre, les clients devraient continuer d'utiliser cette option pour obtenir un nouveau TGT afin d'avoir des clés de session différentes sur les différents systèmes.

Vérification des stratégies traversées

   Dans Kerberos, le serveur d'application est responsable en dernier ressort de l'acceptation ou du rejet de l'authentification, et il devrait vérifier que seuls des KDC de confiance sont impliqués dans l'authentification d'un principal. Les champs de transit dans le ticket identifient quels domaines ( et donc quels KDC ) ont été impliqués dans le processus d'authentification, et un serveur d'application devrait normalement vérifier ce champ. Si l'un d'eux n'est pas de confiance pour authentifier le principal de client indiqué (probablement déterminé par une politique fondée sur le domaine), la tentative d'authentification doit être rejetée. La présence de ?DC de confiance dans cette liste ne donne aucune garantie; un KDC compromis peut avoir fabriqué la liste.

   Bien que le serveur d'extrémité décide en dernier ressort si l'authentification est valide, le KDC pour le domaine du serveur l'extrémité peut appliquer une politique spécifique du domaine pour la validation du champ de transit et l'acceptation des accréditifs pour l'authentification de traversée de domaine. Lorsque le KDC applique de telles vérifications et accepte une telle authentification de traversée de domaine, il va établir le flag TRANSITED-POLICY-CHECKED dans les tickets de service qu'il produit sur la base du TGT de traversée de domaine. Un client peut demander que les KDC ne vérifient pars le champ en mettant le flag DISABLE-TRANSITED-CHECK. Les KDC devraient respecter ce flag.

   Les serveurs d'application doivent soit faire eux-mêmes les vérifications de domaine traversé soit rejeter les tickets de traversée de domaine sans que TRANSITED-POLICY-CHECKED sois mis.

OK-as-Delegate

Pour certaines applications, un client peut avoir besoin de déléguer son autorité à un serveur pour agir en son nom en contactant d'autres services. Cela exige que le client transmette les accréditifs à un serveur intermédiaire. La capacité pour un client à obtenir un ticket de service pour un serveur n'apporte pas d'information au client sur la question de savoir si le serveur devrait être considéré comme de confiance pour accepter des accréditifs délégués. Le flag OK-AS-DELEGATE donne à un KDC un moyen pour communiquer une politique de domaine local à un client sur le sujet de savoir si un serveur intermédiaire est de confiance pour accepter de tels accréditifs.

La copie des flags de ticket dans la partie chiffrée de la réponse du KDC peut avoir le flag OK-AS-DELEGATE établi pour indiquer au client que le serveur spécifié dans le ticket a été déterminé par la politique du domaine comme étant un récepteur convenable de délégation. Un client peut utiliser la présence de ce flag pour l'aider à décider de déléguer des accréditifs (en accordant soit un mandat soit un TGT retransmis) à ce serveur. Il est acceptable d'ignorer la valeur de ce flag. Lorsqu'il établit ce flag, un administrateur devrait considérer la sécurité et le placement du serveur sur lequel va fonctionner le service, ainsi que si le service exige l'utilisation d'accréditifs délégués.

Autres options de KDC

Il y a 3 options supplémentaires qui peuvent être établies dans une demandes de KDC du client

Renewable-OK

L'option REMEWABLE-OK indisque que le client acceptera un ticket renouvelable si un ticket avec la durée de vie demandée ne peut pas être autrement fourni. Si un ticket avec la durée de vie demandée ne peut pas être fourni, le KDC peut alors produire un ticket renouvelable avec un renew-till égal à la fin de durée de vie demandée. La valeur du champ renew-till peut encore être ajustée par des limites déterminées par le site ou des limites imposées par le principal ou serveur individuel.

ENC-TKT-IN-SKEY

Dans sa forme de base, le protocole Kerberos prend en charge l'authentification dans un montage client-serveur et ne convient pas bien pour l'authentification dans un environnement d'homologue à homologue parce que la clé à long terme de l'usager ne reste pas sur la station de travail après la connexion initiale. L'authentification de tels homologues peut être prise en charge par Kerberos dans sa variante d'usager à usager. L'option ENC-TKT-IN-SKEY prend en charge l'authentification d'usager à usager en permettant que le KDC produise un ticket de service chiffré en utilisant la clé de session provenant d'un autre TGT produite pour un autre usager. L'option ENC-TKT-IN-SKEY n'est honorée que par le TGT. Elle indique que le ticket à produire pour le serveur est à chiffrer dans la clé de session à partir du second TGT supplémentaire fourni avec la demande.

Authentification hardware sans mot de passe

L'option OPT-HARDWARE-AUTH indique que le client souhaite utiliser une forme d'authentification de matériel à la place de ou en plus du mot de passe du client ou autre clé de chiffrement à longue durée de vie. OPT-HARDWARE-AUTH n'est honoré que par l'AS. S'il est pris en charge et admis par la politique, le KDC va retourner un code d'erreur de KDC_ERR_PREAUTH_REQUIRED et inclure les METHOD-DATA exigées pour effectuer une telle authentification.

Échange de messages

Les paragraphes qui suivent décrivent les interactions entre les clients et serveurs réseau et les messages impliqués dans ces échanges.

Échange service d'authentification

   L'échange de service d'authentification ( AS ) entre le client et le serveur d'authentification Kerberos est initialisé par un client qui souhaite obtenir des accréditifs d'authentification pour un serveur donné mais ne détient pas actuellement d'accréditifs. Dans la forme de base, la clé secrète du client est utilisée pour le chiffrement et le déchiffrement. Cet échange est normalement utilisé à l'initialisation d'une session de connexion pour obtenir des accréditifs pour un serveur d'allocation de tickets ( TGS ). qui seront utilisés ultérieurement pour obtenir des accréditifs pour d'autres serveurs sans avoir besoin d'utiliser la clé secrète du client. Cet échange est aussi utilisé pour demander des accréditifs pour des services qui ne doivent pas passer par le TGS ( le service de changement de mot de passe refuse les demandes si le demanteur ne peut pas démontrer qu'il a connaissance du vieux mot de passe ).

   Cet échange ne fournit par lui-même aucune assurance de l'identité de l'usager. Pour authentifier un usager qui s'inscrit sur un système local, les accréditifs obtenus dans l'échange d'AS peuvent d'abord être utilisés dans un échange TGS pour obtenir des accréditifs pour un serveur local; ces accréditifs doivent ensuite être vérifiés par un serveur local à travers l'achèvement réussi de l'échange client/serveur.

   L'échange AS consiste en 2 messages: KRB_AS_REQ et KRB_AS_REP ou KRB_ERROR.

   Dans la demande, le client envoie (en clair) sa propre identité et l'identité du serveur pour lequel il demande les accréditifs, d'autres informations sur les accréditifs qu'il demande, et un nom temporaire généré de façon aléatoire qui peut être utilisé pour détecter des répétitions et pour associer les réponses aux demandes correspondantes. Ce nom temporaire doit être généré de façon aléatoire par le client et mémorisé pour vérification par rapport au nom aléatoire dans la réponse attendue. La réponse, KRB_AS_REP, contient un ticket que le client présentera au serveur, et une clé de session qui sera partagée par le client et le serveur. La clé de session et les informations supplémentaire sont chiffrées avec la clé secrète du client. La partie ciffrée du message KRB_AS_REP contient aussi le nom temporaire qui doit correspondre au nom temporaire provenant du message KRB_AS_REQ.

   Sans pré-authentification, l'AS ne sait pas si le client est réellement le principal nommé dans la demande. Il envoie simplement une réponse sans savoir s'il sont les mêmes et sans s'en soucier. Ceci est acceptable puisque personne sauf le principal dont l'identité a été donnée dans la demande se sera capable d'utiliser la réponse. Ses information critiques sont chiffrées avec la clé du principal. Cependant, un attaquant peut envoyer un message KRB_AS_REQ pour obtenir du texte en clair connu afin d'attaquer la clé du principal. Et particulièrement si la clé se fonde sur un mot de passe, cela peut créer un danger pour la sécurité. Ainsi, la demande initiale prend en charge un champ facultatif qui peut être utilisé pour passer des informations supplémentaires nécessaire pour l'échange initial. Ce champ devrait être utilisé pour la pré-authentification.

   Diverses erreurs peuvent survenir; elles sont indiquées par une réponse d'erreur KRB_ERROR à la place de la réponse KRB_AS_REP. Le message d'erreur n'est pas chiffré. Ce message contient des informations qui peuvent être utilisées pour l'associer au message auquel il répond. Le contenu du message KRB_ERROR n'est pas protégé en intégrité, donc le client ne peut pas détecter les répétitions, contrefaçons, ou modifications. Une solution à ce problème sera donnée dans une prochaine version du protocole.

Génération du message KRB_AS_REQ

Le client peut spécifier un certain nombre d'options dans la demande initiale. Parmi ces options figure la question de savoir si la pré-authentification est à effectuer; si le ticket demandé est renouvelable, mandatable, ou transmissible; s'il devrait être postdaté ou permettre de postdatage de tickets déduits; et si un ticket renouvelable sera accepté à la place d'un ticket non renouvelable si la date d'expiration du ticket demandé ne peut pas être satisfaite par un ticket non renouvelable.

Réception du message KRB_AS_REQ

Si tout va bien, le traitement du message KRB_AS_REP résultera en la création d'un ticket que le client présentera au serveur.

Parce que Kerberos peut fonctionner sur des transports non fiables comme UDP, le KDC doit être prêt à retransmettre des réponses dans le cas où elles sont perdues. Si un KDC reçoit une demande identique à l'une de celles qu'il a récemment traitées avec succès, le KDC doit répondre par un message KRB_AS_REP plutôt qu'une erreur de répétition. Afin de réduire la quantité de texte chiffré à disposition d'un attaquant potentiel, les KDC peuvent envoyer la même réponse que générée lors du premier traitement de la demande. Les KDC doivent obéir à ce comportement de répétition même si le transport réel utilisé est fiable.

Génération du message KRB_AS_REP

   Le serveur d'authentification cherche dans sa base de données les principaux de client et de serveur nommés dans le message KRB_AS_REQ, et en extrait les clés respectives. Si le principal client demandé nommé dans la demande est inconnu parce qu'il n'existe pas dans la base de données de principaux du KDC, un message d'erreur est retourné avec un KDC_ERR_C_PRINCIPAL_UNKNOWN.

   S'il lui est demandé de faire ainsi, le serveur pré-authentifie la demande, et si la vérification de pré-authentification échoue, un message d'erreur avec le code KDC_ERR_PREAUTH_FAILES. Si la pré-authentification est exigée, mais n'était pas présente dans la demande, un message d'erreur avec le code KDC_ERR_PREAUTH_REQUIRED est retourné, et un objet METHOD-DATA sera mémorisé dans le champ e-data du message KRB-ERROR pour spécifier quels mécanismes de pré-authentification sont acceptables. Cela inclure habituellement les éléments PA-ETYPE-INFO et/ou PA-ETYPE-INFO2. Si le serveur ne peut pas s'accommoder d'un des types de chiffrement demandé par le client, un message d'erreur avec le code KDC_ERR_ETYPE_NOSUPP est retourné.

   Autrement, le KDC génère une clé de session "aléatoire", ce qui signifie, entre autres choses, qu'il devrait être impossible de deviner la prochaine clé de session sur la base de la connaissance des clés de session passées. Bien que cela puisse être réalisé avec un générateur de nombres pseudo-aléatoires s'il se fonde sur les principes cryptographiques, il est plus souhaitable d'utiliser un générateur de nombres vraiment aléatoires, comme un de ceux fondés sur la mesure de phénomènes physiques aléatoires.

   En réponse à une demande d'AS, s'il y a plusieurs clés de chiffrement inscrites pour un client dans la base de données Kerberos, le champ etype de la demande d'AS est utilisé par le KDC pour choisir la méthode de chiffrement à utiliser pour protéger la partie chiffrée du message KRB_AS_REP qui est envoyé au client. S'il y a plus d'un type de chiffrement fort dans la liste etype, le KDC devrait utiliser le premier etype fort valide pour lequel une clé de chiffrement est disponible.

   Lorsque la clé de l'utilisateur est générée à partir d'un mot de passe ou d'une passphrase, la fonction string-to-key pour le type de clé de chiffrement particulier est utilisé, comme spécifié dans la rfc 3961. La valeur de salt et les paramètres supplémentaires pour la fonction string-to-key ont des valeurs par défaut qui peuvent être remplacés par les données de pré-authentification (n (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-ETYPE-INFO2, etc.). Comme le KDC est supposé mémoriser une copie seulement de la clé résultant, ces valeurs ne devraient pas être changées pour des clés fondées dus des mots de passe excepté lorsqu'on change la clé du principal.

   Lorsque le serveur d'AS va inclure les données de pré-authentification dans un KDC-ERROR ou dans un AS-REP, il doit utiliser PA-ETYPE-INFO2 et non PA-ETYPE-INFO, si le champ etype de la AS-REQ du client comporte au moins un type de chiffrement "plus récent". Autrement (lorsque le champ etype de l'AS-REQ ne comporte aucun type de chiffrement plus récent), il doit envoyer les deux PA-ETYPE-INFO2 et PA-ETYPE-INFO (tous 2 avec une entrée pour chaque enctype). Un enctype "plus récent" est tout enctype spécifié officiellement en premier concurrement ou ultérieurement à la publication de la présent rfc. Les enctypes DES, 3DES, ou RC4 et tous ceux définis dans la RFC1510 ne sont pas des enctypes "plus récents"

   Il n'est pas possible de générer une clé utilisateur de façon fiable selon une passphrase donnée sans contacter le KDC, car on ne pourra pas savoir si des valeurs de salt ou de paramètres de remplacement sont nécessaires.

   Le kDC va essayer d'allouer le type de la clé de session aléatoire d'après la liste des méthodes dans le champ etype. Le KDC va sélectionner le type approprié en utilisant la liste des méthodes fournie et les informations tirées de la base de données Kerberos qui indique les méthodes de chiffrement acceptables pour le serveur d'application. Le KDC ne produira pas de tickets avec un type faible de chiffrement de clé de session.

   Si l'heure de début demandée est absente, indique une heure passée, ou est dans une fenêtre acceptable pour le KDC et si l'option POSTDATE n'a pas été spécifié, l'heure de début du ticket est réglée à l'heure en cours du serveur d'authentification. S'il indique une heure future au delà de la fenêtre acceptable, mais si l'option POSTDATED n'a pas été spécifiée, l'erreur KDC_ERR_CANNOT_PORTDATE est retournée. Autrement, l'heure de début demandée est vérifiée par rapport à la politique du domaine local, et si l'heure de début du ticket est acceptable, il est réglé comme demandé, et le flag INVALID est mis dans le nouveau ticket.

   L'heure d'expiration du ticket sera réglée au plus tôt de l'heure de fin demandée et de l'heure déterminée par la politique locale, éventuellement en utilisant des facteurs spécifiques du domaine ou du principal. Par exemple, l'heure d'expiration peut être réglée au plus tôt de ce qui suit:

- L'heure d'expiration demandée dans le message KRB_AS_REQs
- L'heure de début du ticket plus la durée de vie maximum admissible associée au principal d'après la base de données du serveur d'authentification.
- L'heure de début du ticket plus la durée de vie maximum admissible associée au principal
- L'heure de début du ticket plus la durée de vie maximum réglée par la stratégie du domaine local

   Si l'heure d'expiration demandée moins l'heure de début est inférieur à la durée de vie minimum déterminée par un site, un message d'erreur avec le code KDC_ERR_NEVER_VALID est retourné. Si l'heure d'expiration demandée pour le ticket excède ce qui a été déterminé ci-dessus, et si l'option RENEWABLE-OK était demandé, le flag RENEWABLE est alors mis dans le nouveau ticket, et le champ renew-till peut être réglé au plus tôt de:

- Sa valeur demandée
- L'heure de début du ticket plus le minimum des deux durées de vie maximum associées aux entrées de base de données des principaux
- L'heure de début plus la durée de vie renouvelable maximum réglée par la politique du domaine local

   Le champ des flags du nouveau ticket aura les options suivantes établies s'ils ont été demandés et si la politique du domaine local le permet: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.. Si le nouveau ticket est postdaté, son flag INVALID est également mis.

   Si tout ce qui précède réussit, le serveur va chiffrer la partie de ciphertext du ticket en utilisant la clé de chiffrement extraite de l'enregistrement du principal du serveur dans la base de données Kerberos en utilisant le type de chiffrement associé à la clé du principal du serveur (ce choix n'est pas affecté par le etype dans la requête). Il forge alors un message KDC_AS_REP, en copiant les adresses de la demande dans le caddr de la réponse, en plaçant toutes les données de pré-authentification demandées dans le padata de la réponse, et en chiffrant la partie ciphertext dans la clé du client en utilisant une méthode de chiffrement acceptable demandée dans le champ etype de la demande, ou dans une clé spécifiée par le mécanisme de pré-authentification utilisé.

Génération du message KDC_ERROR

Plusieurs erreurs peuvent survenir, et le serveur d'authentification répond en envoyant un message d'erreur, KDC_ERROR, au client, avec les champs code d'erreur et e-text réglés aux valeurs appropriées.

Réception du message KRB_AS_REP

   Si le type du message de réponse est KDC_AS_REP, le client vérifie alors que les champs cname et crealm de la portion de texte en clair de la réponse correspondent à ce qui était demandé. Si un champ padata est présent, il peut être utilisé pour déduire la clé secrète appropriée pour déchiffrer le message. Le client déchiffre la partie chiffrée de la réponse en utilisant sa clé secrète et vérifie que le nom temporaire dans la partie chiffrée correspond au nom occasionnel qu'il a fourni dans sa demande (pour détecter des répétitions). Il vérifie aussi que sname et srealm de la réponse correspondent à ceux de la demande (ou des valeurs attendues), et que le champ d'adresse d'hôte est correcte. Il mémorise alors le ticket, la clé de sessions, les heures de début et d'expiration, et les autres informations pour un usage ultérieur. Le champ last-req (et le champ déconseillé key-expiration) tirés de la partie chiffrée de la réponse peuvent être vérifiés pour notifier à l'utilisateur une expiration de clé imminente. Ceci permet au programme client de suggérer un remède, comme un changement de mot de passe.

   À la validation du message KRB_AS_REP (en comparant le nom temporaire avec celui envoyé), le client sait que l'heure courante du KDC est celle lue dans le champ authtime de la partie chiffrée de la réponse. Le client peut optionnellement utiliser cette valeur pour synchroniser l'horloge dans les messages suivant en enregistrant avec le ticket la différence entre la valeur de authtime et l'horloge locale. Cet offset peut ainsi être utilisé par le même utilisateur pour ajuster le temps lu de l'horloge système lors de la génération des messages.

   Cette technique doit être utilisée en ajustant le biais d'horloge au lieu de changer directement l'horloge système, parce que la réponse du KDC n'est authentifiée qu'auprès de l'utilisateur dans la clé secrète a été utilisée, mais pas auprès du système ou de la workstation.

   Le déchiffrement correcte du message KRB_AS_REP n'est pas suffisant à l'hôte peut vérifier l'identité de l'utilisateur qui se connecte sur la workstation. L'utilisateur et un attaquant pourraient coopérer pour générer un message de format KRB_AS_REP qui se déchiffre correctement mais ne serait pas du KDC approprié. Si l'hôte souhaite vérifier l'identité de l'utilisateur, il doit exiger que l'utilisateur présente des accréditifs d'application qui puissent être vérifiés en utilisant une clé secrète que l'hôte aura mémorisé en toute sécurité. Si ces accréditifs peuvent être vérifiés, l'identité de l'usager peut alors être assurée.

Réception du message KRB_ERROR

Si le type de message de réponse est KRB_ERROR, le client l'interprète alors comme une erreur et effectue toute tâche spécifique de l'application qui est nécessaire pour récupérer.

Échange d'authentification client/serveur

L'échange d'authentification client/serveur (CS) est utilisé par les applications réseau pour authentifier le client auprès du serveur et vice versa. Le client doit déjà avoir acquis des accréditifs pour le serveur en utilisant l'échange AS ou TGS.

Message KRB_AP_REQ

KRB_AP_REQ contient des informations d'authentification qui devraient faire partie du premier message dans une transaction authentifiée. Il contient un ticket, un authentifiant, et quelques informations de comptabilité supplémentaire. Le ticket est insuffisant par lui-même pour authentifier un client, car les tickets passent à travers le réseau. L'authentifiant est utilisé pour empêcher la répétition invalide de tickets en prouvant au serveur que le client connaît la clé de session du ticket et est donc fondé à utiliser le ticket. Le message KRB_AP_REQ est par ailleurs appelé un "en-tête d'authentification".

Génération d'un message KRB_AP_REQ

Lorsqu'un client souhaite initier l'authentification auprès d'un serveur, il obtient (soit avec un cache d'arréditifs, l'échange d'AS, ou l'échange TGS) un ticket et une clé de session pour le service désiré. Le client peut réutiliser tous les tickets qu'il détient jusqu'à leur expiration. Pour utiliser un ticket, le client construit un nouvel authentifiant à partir de l'heure du système et de son nom, et facultativement à partir d'une somme de contrôle spécifique de l'application, un numéro de séquence initial à utiliser dans les messages KRB_SAFE ou KRB_PRIV, et/ou une sous-clé de session à utiliser dans les négociations pour une clé de session unique pour cette session particulière. Les authentifiants ne doivent pas être réutilisés et devraient être rejetés s'ils sont répétés sur un serveur. Noter que cela peut rendre les applications fondées sur des transports non fiables difficiles à coder correctement. Si le transport peut délivrer des messages dupliqués, un nouvel authentifiant doit être généré pour chaque essai, ou le serveur d'application doit faire correspondre demandes et réponses et répéter la première répétition en réponse à un duplicata détecté.

Si un numéro de séquence doit être inclus, il devrait être choisi de façon aléatoire de sorte que même après l'échange de nombreux messages il n'y ait aucune probabilité de collision avec un autre numéro de séquence utilisé. Le client peut indiquer une exigence d'authentification mutuelle ou l'utilisation d'un ticket fondé sur une clé de session en mettant le ou les flags appropriés dans le champ ap-options du message. L'authentifiant est chiffré dans la clé de session et combiné avec le ticket pour former le message KRB_AP_REQ, qui est alors envoyé au serveur d'extrémité avec toutes information supplémentaires spécifiques de l'application.

Réception du message KRB_AP_REQ

   L'authentification se fonde sur l'heure courante du serveur, sur l'authentifiant, et sur le ticket. Plusieurs erreurs sont possibles. Si une erreur survient, on attend du serveur qu'il réponde un message KRB_ERROR au client. Ce message peut être encapsulé dans le protocole d'application si sa forme brute n'est pas acceptable pour le protocole.

   L'algorithme de vérification des informations d'authentification est le suivant. Si le type de message n'est pas KRB_AP_REQ, le serveur retourne l'erreur KRB_AP_ERR_MSG_TYPE. Si la version de clé est indiquée par le ticket dans KRB_AP_REQ n'est pas une de celles que le serveur peut utiliser (par exemple, elle indique une vieille clé, et le serveur ne possède plus de copie de la vieille clé), l'erreur KRB_AP_ERR_BADKEYVER est retournée. Si le flag USE-SESSION-KEY est mis dans le champ ap-options, il indique au serveur l'utilisation de l'authentification d'utilisateur à utilisateur. et le chiffrement du ticket avec la clé de session provenant du TGT du serveur plutôt qu'avec la clé secrète du serveur.

   Le champ srealm dans la portion non chiffrée du ticket dans KRB_AP_REQ est utilisé pour spécifier quelle clé secrète devrait utiliser le serveur pour déchiffrer le ticket, parce qu'il est possible au serveur d'être enregistré dans plusieurs domaines, avec des clés différentes dans chacun. Le code d'erreur KRB_AP_ERR_NOKEY est retourné si le serveur n'a pas la clé appropriée pour déchiffrer le ticket.

   Le ticket est déchiffré en utilisant la version de la clé du serveur spécifiée par le ticket. Si la routine de déchiffrement détecte une modification du ticket (chaque système de chiffrement doit fournir des sauvegardes pour détecter le texte chiffré modifié), l'erreur KRB_AP_ERR_BAD_INTEGRITY est retournée (il y a de bonnes chances que différentes clés aient été utilisées pour chiffrer et pour déchiffrer).

   L'authentifiant est déchiffré en utilisant la clé de session extraite du ticket déchiffré. Si le déchiffrement montre qu'il a été modifié, l'erreur KRB_AP_ERR_BAD_INTEGRITY est retournée. Le nom et le domaine du client tirés du ticket sont comparés aux champs correspondants dans l'authentifiant. S'ils ne correspondent pas, l'erreur KRB_AP_ERR_BADMATCH est retournée; ceci est normalement causé par une erreur client ou une tentative d'attaque. Les adresses dans le ticket sont alors examinées à la recherche d'une adresse correspondant à l'adresse mentionnée par le système d'exploitation du client. Si aucune correspondance n'est trouvée, ou si le serveur insiste sur les adresses du ticket mais qu'aucune n'est présente dans le ticket, l'erreur KRB_AP_ERR_BADADDR est retournée. Si l'heure locale du serveur et l'heure du client dans l'authentifiant diffèrent au delà de l'admissible, l'erreur KRB_AP_ERR_SKEW est retournée.

   À moins que le serveur d'application ne fournisse ses propres moyens pour se protéger contre la répétition (par exemple, une séquence challenge-réponse initiée par le serveur après l'authentification, ou l'utilisation d'une sous-clé de chiffrement générée par le serveur), le serveur doit utiliser un cache pour mémoriser tout authentifiant présenté dans la plage de temps admissible. Une analyse soigneuse du protocole et de la mise en œuvre de l'application est recommandée avant d'éliminer ce cache. Le cache mémorise au moins les champ de nom du serveur, de nom du client, et d'heures tirés des authentifiants vus le plus récemment, et si une correspondance est trouvée, l'erreur KRB_AP_ERR_REPEAT est retournée. Noter qu'ici, le rejet est restreint aux authentifiants provenant du même principal vers le même serveur. Les autres principaux de clients qui communiquent avec le même principal du serveur ne devraient pas voir leurs authentifiants rejetés si les champ heure et microseconde se trouvent correspondre à d'autres authentifiants du client.

   Si un serveur perd la trace des authentifiants présentés pendant l'horaire admissible, il doit rejeter toutes les demandes jusqu'à la fin de la plage de temps, lui donnant l'assurance que tout authentifiant perdu ou répété se retrouvera hors plage.

   Note de mise en œuvre: Si un client génère plusieurs demandes au KDC avec le même horodatage, y compris le champ timestamp, toutes les demandes reçues sauf la première seront rejetées comme répétitions. Cela peut arriver, par exemple, si la résolution de l'horloge du client est trop grossière. Les mises en œuvre client devraient s'assurer que les horodatages ne sont pas réutilisés, éventuellement en incrémentant le champ timestamp dans l'horodatage lorsque l'horloge retourne la même heure pour plusieurs demandes.

   Si plusieurs serveur ( par exemple, différents services sur une machine, ou un seul service mis en œuvre sur plusieurs machines ) partagent un principal de service ( pratique non recommandée en général ), ils doivent partager ce cache, ou bien le protocole d'application doit être conçu de façon à en éliminer le besoin. Noter que ceci s'applique à tous les services. Si un protocole d'application n'a pas de protection contre la répétition, un authentifiant utilisé avec un tel service pourrait être répété ultérieurement dans un service différent avec le même principal de service mais sans protection contre la répétition.

   Si un numéro de séquence est fourni dans l'authentifiant, le serveur le sauvegarde pour utilisation ultérieure en traitant les messages KRB_SAFE et/ou KRB_PRIV. Si une sous-clé est présente, le serveur la sauvegarde pour plus tard ou l'utilise pour aider à générer son propre choix d'une sous-clé à retourner dans un message KRB_AP_REP.

   Le serveur calcule l'âge du ticket: heure locale du serveur moins l'heure de début dans le ticket. Si l'heure de début est plus tardive que l'heure en cours de plus que la plage horaire admissible, ou si le flag INVALID est mis, l'erreur KRB_AP_ERR_TKT_NYV est retournée. Autrement, si l'heure en cours est plus tardive que l'heure de fin de plus que la plage admissible, l'erreur KRB_AP_ERR_TKT_EXPIRED est retournée.

   Si toutes ces vérification ont réussi sans erreur, le serveur est assuré que le client possède les accréditifs du principal nommé dans le ticket, et donc, que le client a été authentifié auprès du serveur.

   Réussir ces vérifications ne fournit que l'authentification du principal désigné; cela n'implique pas l'autorisation d'utiliser le service désigné. Les applications doivent gérer l'autorisation sur la base du nom authentifié de l'utilisateur. de l'opération demandée, des informations de commande d'accès locales telles que celles contenues dans un fichier .k5login ou .k5users, et éventuellement d'un service d'autorisation distribué distinct.

Génération d'un message KRB_AP_REP

Normalement, la demande l'un client va inclure à la fois les informations d'authentification et sa demande initiale dans le même message, et le serveur n'a pas besoin de répondre explicitement au KRB_AP_REQ. Cependant, si l'authentification mutuelle (authentifiant non seulement le client auprès du serveur, mais aussi le serveur auprès du client) est effectuée, le message KRB_AP_REQ aura MUTUAL-REQUIRED établi dans son champ ap-options, et un message KRB_AP_REP est exigé en réponse. Comme avec le message d'erreur, ce message peut être encapsulé dans le protocole d'application si sa forme "brute" n'est pas acceptable pour le protocole d'application. Les champs horodatage et microseconde utilisés dans la réponse doivent être les champs horodatage et microseconde du client (tels que fournis par l'authentifiant). Si un numéro de séquence doit être inclus, il devrait être choisi de façon aléatoire comme décrit ci-dessus pour l'authentifiant. Une sous-clé peut être incluse si le serveur désire négocier une sous-clé différente. Le message KRB_AP_REP est chiffré dans la clé de session extraite du ticket.

Réception du message KRB_AP_REP

Si un message KRB_AP_REP est retourné, le client utilise la clé de session provenant des accréditifs obtenus pour que le serveur déchiffre le message et vérifie que les champs horodatage et microseconde correspondent à ceux de l'authentifiant qu'il a envoyé au serveur. S'ils correspondent, le client est alors assuré que le serveur est authentique. Le numéro de séquence est la sous-clé ( si présente ) sont conservés pour utilisation ultérieure ( noter que pour chiffrer le message KRB_AP_REP, la sous-clé de session n'est pas utilisée, même si elle est présent dans l'authentification ).

Utilisation de la clé de chiffrement

   Après que l'échange KRB_AP_REQ/KRB_AP_REP est terminé, le client et le serveur partagent une clé de chiffrement qui peut être utilisée par l'application. Dans certains cas, l'utilisation de cette clé de session sera implicite dans le protocole; dans d'autres, la méthode d'utilisation doit être choisie entre plusieurs possibilités. L'application peut choisir la clé de chiffrement réelle à utiliser pour KRB_PRIV, KRB_SAFE, ou d'autres utilisation spécifiques de l'application fondées sur la clé de session à partir du ticket et des sous-clés dans le message KRB_AP_REP et l'authentifiant. Les mises en œuvre du protocole peuvent fournir des routines pour choisir les sous-clés sur la base des clés de session et de nombres aléatoires et générer une clé négociée à retourner dans le message KRB_AP_REP.

   Pour atténuer l'effet des défaillances de la génération de nombres aléatoire chez le client, il est vivement recommandé que toute clé déduite par une application pour utilisation ultérieure incluent la pleine entropie de clé déduite de la clé de session générée par le KDC portée dans le ticket. On laisse les négociations de protocole sur la façon d'utiliser la clé (par exemple, pour choisir un type de chiffrement ou de somme de contrôle) au programmeur de l'application. Le protocole Kerberos n'impose pas de contrainte sur les options de mise en œuvre, mais un exemple de la façon dont cela peut être fait figure ci-après.

   Une façon qu'une application peut choisir pour négocier une clé à utiliser pour la protection ultérieure d'intégrité et de confidentialité est que le client propose une clé dans le champ sous-clé à l'authentifiant. Le serveur peut alors choisir une clé en utilisant la clé proposée par le client en entrée, retournant la nouvelle sous-clé dans le champ sous-clé de la réponse de l'application. Cette clé eut alors être utilisée pour la suite de la communication.

   Avec les échanges d'authentification aussi bien unilatérale que mutuelle, les homologues devraient veiller à ne pas s'envoyer l'un l'autre d'informations sensibles sans garanties appropriées. En particulier, les applications qui exigent la confidentialité ou l'intégrité devraient utiliser la réponse KRB_AP_REP du serveur au client pour que le client et le serveur s'assurent tous deux de l'identité de leur homologue. Si un protocole d'application exige la confidentialité de ses messages, il peut utiliser le message KRB_PRIV. Le message KRB_SAFE peut être utilisé pour s'assurer de l'intégrité.

Échange TGS

L'échange TGS entre un client et le TGS est initié par un client lorsqu'il cherche à obtenir des accréditifs d'authentification pour un serveur donné (qui peut être enregistré dans un domaine distant), lorsqu'il cherche à renouveler ou valider un ticket existant, ou lorsqu'il cherche à obtenir un ticket mandataire. Dans le premier cas, le client doit déjà avoir acquis un ticket pour le TGS auprès de l'AS ( Le TGT est généralement obtenu quand un client quand un client s'authentifie sur le système ). Le format pour l'échange TGS est presque identique à l'échange AS. La différence principale est que le chiffrement et le déchiffrement dans l'échange TGS n'est pas effectuée dans le clé du client. À la place, le clé de session du TGT ou du ticket renouvelable, ou de la clé de sous-session d'un authentifiant est utilisé. Comme c'est le cas pour tous les serveur d'application, les tickets expirés ne sont pas acceptés par le TGS, donc une fois une TGT ou un renouvelable expiré, le client doit utiliser un échange séparé pour obtenir des tickets valides.

L'échange TGS consiste de 2 messages: une requête ( KRB_TGS_REQ ), et une réponse ( KRB_TGS_REP ou KRB_ERROR ). Le message KRB_TGS_REQ inclus les informations authentifiant le client plus une requête pour des accréditifs. Les information d'authentification consistent de l'en-tête d'authentification ( KRB_AP REQ ), qui inclus le ticket TGT, renouvelable ou invalide du client précédemment obtenus. Dans les cas de TGT et de proxy, la requête peut inclure un ou plusieurs éléments: une liste d'adresses réseaux, une collection de données d'autorisation typées, ou des tickets supplémentaires. La réponse TGS ( KRB_TGS_REP ) contient es accréditifs demandés, chiffrés dans la clé de session provenant du TGT ou le ticket renouvelable, ou, si elle est présente, dans la sous-clé de session provenant de l'authentifiant. Le message KRB_ERROR n'est pas chiffré. Le message KRB_TGS_REP contient des informations qui peuvent être utilisées pour détecter les répétitions, et pour l'associer au message auquel il répond.

Génération du message KRB_TGS_REQ

   Avant d'envoyer une demande au TGS, le client doit déterminer dans quel domaine il pense qu'est enregistré le serveur d'application. Cela peut se faire de diverses façons. Il peut être connu à l'avance, peut être mémorisé dans un serveur de noms, ou peut être obtenu d'un fichier de configuration. Si le client connaît le nom et le domaine du principal du service et s'il ne possède pas encore un TGT pour le domaine approprié, il doit alors en obtenir un. Il essaye d'abord en demandant un TGT pour le domaine de destination à un serveur Kerberos pour lequel le client possède un TGT ( en utilisant de façon récurrent le message KRB_TGS_REQ ). Le serveur Kerberos peut retourner un TGT pour le domaine désiré, auquel cas le traitement peut se poursuivre. Autrement, le serveur Kerberos peut retourner un TGT pour un domaine qui est plus proche du domaine désiré. Noter que dans ces cas, la mauvaise configuration du serveur Kerberos peut causer les boucles dans le chemin d'authentification résultant. ce que le client devrait veiller à détecter et éviter.

   Si le serveur Kerberos retourne un TGT pour un domaine plus proche que le domaine désiré, le client peut utiliser la configuration de la politique locale pour vérifier que le chemin d'authentification utilisé est acceptable. Autrement, un client peut choisir son propre chemin d'authentification, plutôt que de s'appuyer sur le serveur Kerberos pour en choisir un. Dans les 2 cas, toute information de politique ou de configuration utilisée pour choisir ou valider des chemins d'authentification, par le serveur Kerberos ou par le client, doit être obtenue d'une source de confiance.

   Lorsqu'un client obtient un TGT qui est plus proche du domaine de destination, il peut mettre en cache ce ticket et le réutiliser dans des échange KRB_TGS futures avec les services dans le domaine plus proche. Cependant, si le client devait obtenir un TGT pour le domaine plus proche en commençant au KDC initial plutôt qu'au titre de l'obtention d'un autre ticket, un chemin plus court vers le domaine plus proche pourrait être utilisé. Ce chemin plus court peut être désirable parce que moins de KDC intermédiaires connaîtraient la clé de session du ticket impliqué. Pour cette raison, les clients devraient évaluer s'ils ont confiance dans les domaines de transit pour obtenir le ticket plus proche lorsqu'ils prennent la décision d'utiliser le ticket à l'avenir.

   Une fois que le client a obtenu un TGT pour le domaine approprié, il détermine quels serveur Kerberos servent ce domaine et contacte l'un d'entre eux. Leur liste peut être obtenue par un fichier de configuration ou un service réseau, ou elle peut être générée à partir du nom du domaine. Tant que les clés secrètes échangées par domaine sont gardées secrètes, seul de DOS résulte de l'utilisation d'un faux serveur Kerberos.

   Comme dans l'échange d'AS, le client peut spécifier un certain nombre d'options dans le message KRB_TGS_REQ. Une de ces options est l'options ENC-TKT-IN-SKEY utilisée pour l'authentification d'utilisateur à utilisateur. Lors de la génération du message KRB_TGS_REQ, cette option indique que le client inclut un TGT obtenu du serveur d'application dans le champ de tickets supplémentaires de la demande et que le KDC devrait chiffrer le ticket pour le serveur d'application en utilisant la clé de session provenant de ce ticket supplémentaire, au lieu d'une clé de serveur provenant de la base de données du principal.

   Le client prépare le message KRB_TGS_REQ, qui fournit un en-tête d'authentification comme élément du champ padata, et incluant les même champs qu'utilisés dans le message KRB_AS_REQ avec plusieurs champs facultatifs: le champ enc-authorization-data pour l'usage du serveur d'application et les tickets supplémentaires requis par certaines options.

   Pour préparer l'en-tête d'authentification, le client peut choisir une sous-clé de session avec laquelle sera chiffrée la réponse du serveur Kerberos. Si le client choisit une sous-clé de session, il faut veiller à s'assurer du caractère aléatoire de la sous-clé de session choisie.

   Si la sous-clé de session n'est pas spécifiée, la clé de session provenant du TGT sera utilisée. Si enc-authorization-data est présent, il doit être chiffré dans la sous-clé de session, si elle est présente, à partir de la portion d'authentifiant de l'en-tête d'authentification, ou, si elle n'est pas présente, en utilisant la clé de session provenant du TGT.

   Une fois préparé, le message est envoyé au serveur Kerberos pour le domaine de destination.

Réception du message KRB_TGS_REQ

   Le message KRB_TGS_REQ est traité de manière similaire au message KRB_AS_REQ mais il y a de nombreuses vérification supplémentaires à effectuer. D'abord, le serveur Kerberos doit déterminer pour quel serveur est le ticket d'accompagnement, et il doit choisir la clé appropriée pour le déchiffrer. Pour un message KRB_TGS_REQ normal, ce sera pour le TGS, et la clé du TGS sera utilisée. Si le TGT a été produit par un autre domaine, les clés inter-domaines appropriées doivent être utilisées. Si (a) le ticket d'accompagnement n'est pas un TGT pour le domaine courant, mais est pour un serveur d'application dans le domaine courant, (b) les options RENEW, VALIDATE ou PROXY sont spécifiées dans la demande, et (c) le serveur pour lequel un ticket est demandé est le serveur désigné dans le ticket d'accompagnement, pus le KDC va déchiffrer le ticket dans l'en-tête d'authentification en utilisant la clé du serveur pour lequel elle a été produite. Si aucun ticket ne peut être trouvé dans le champ padata, l'erreur KDC_ERR_PADATA_TYPE_NOSUPP est retournée.

   Une fois que le ticket d'accompagnement a été déchiffré, la somme de contrôle fournie par l'utilisateur dans l'authentifiant doit être vérifiée par rapport au contenu de la demande, et le message doit être rejeté si les sommes de contrôle ne correspondent pas ( avec un code d'erreur KRB_AP_ERR_MODIFIED ) ou si la somme de contrôle n'est pas à l'épreuve des collisions ( avec un code d'erreur KRB_AP_ERR_INAPP_CKSUM ). Si le type de somme de contrôle n'est pas accepté, l'erreur KDC_ERR_SUMTYPE_NOSUPP est retournées.

   Si un des déchiffrements indique un échec de vérification d'intégrité, l'erreur KRB_AP_ERR_BAD_INTEGRITY est retournée. Le KDC doit envoyer un message KRB_TGS_REP valide s'il reçoit un message KRB_TGS_REQ identique à celui qu'il a traité récemment. Cependant, si l'authentifiant est une répétition, mais que le reste de la demande n'est pas identique, de KDC devrait alors retourner KRB_AP_ERR_REPEAT.

Génération du message KRB_TGS_REP

   Le message KRB_TGS_REP partage son format avec KRP_AS_REP, mais avec son champ de typee réglé à KRB_TGS_REP.

   La réponse va comporter un ticket pour le serveur demandé ou pour un serveur d'allocation de ticket d'un KDC intermédiaire à contacter pour obtenir le ticket demandé. La base de données Kerberos est interrogée pour restituer l'enregistrement pour le serveur approprié ( y compris la clé avec laquelle le ticket sera chiffré ). Si la demande est pour un TGT d'un domaine distant, et s'il n'y a pas de partage de clé avec le domaine demandé, le serveur Kerberos va alors choisir le domaine le plus proche du domaine demandé avec lequel il partage une clé et utiliser ce domaine à la place. C'est le seul cas où la réponse pour le KDC sera pour un serveur différent de celui demandé par le client.

   Par défaut, le champ d'adresse, le nom et le domaine du client, la liste des domaines de transit, l'heure de l'authentification initiale, l'heure d'expiration, et les données d'autorisation du ticket nouvellement produit seront copiées du TGT ou du ticket renouvelable. Si les champs de transit ont besoins d'être mis à jour, mais que le type de transit n'est par accepté, l'erreur KDC_ERR_TRTYPE_NOSUPP est retournée.

   Si la demande spécifie une heure de fin, l'heure de fin du nouveau ticket est réglée au minimum de (a) cette demande, (b) de l'heure de fin provenant du TGT, et (c) de l'heure de début du TGT plus le minimum de la durée de vie maximum pour le serveur 'application et la durée de vie maximum pour le domaine local ( la durée de vie maximum pour le principal demandeur a déjà été appliquée lors de la production du ticket ). Si le nouveau ticket doit être un renouvellement, l'heure de fin ci-dessus est alors remplacée par le minimum de (a) la valeur du champ renew_till du ticket et (b) l'heure de début pour le nouveau ticket plus la durée de vie (heure de fin - heure de début ) du vieux ticket.

   Si l'option FORWARDED a été demandée, le ticket résultant contiendra alors les adresses spécifiées par le client. Cette option ne sera honorée que si le flag FORWARDABLE est mis dans le TGT. L'option PROXY est similaire; le ticket résultant contiendra les adresses spécifiées par le client. Elle ne sera honorée que si le flag PROXIABLE est établi dans le TGT. L'option PROXY ne sera pas honorée sur les demandes de TGT supplémentaires.

   Si l'heure de début demandée est absente, indique une heure passée, ou est dans la plage horaire admissible pour le KDC et si l'option POSTDATE n'est pas spécifiée, l'heure de début du ticket est réglée à l'heure en cours de l'AS. Si elle indique une heure dans le futur au delà de la plage horaire admissible, mais l'option POSTDATE n'est pas spécifiée ou si le flag MAY-POSTDATE n'est pas mis dans le TGT, l'erreur KDC_ERR_CANNOT_POSTDATE est alors retournée. Sinon, si le TGT a le flag MAY-POSTDATE mis, le ticket résultant sera postdaté, et l'heure de début demandée sera vérifiée par rapport à la politique du domaine local. Si elle est acceptable, l'heure de début du ticket sera réglée comme demandé, et le flag INVALID sera mis. Le ticket postdaté doit être validé avant utilisation en le présentant au KDC après l'heure de début a été atteinte. Cependant, en aucun cas l'heure de début, de fin, ou de fin de renew-till d'un ticket postdaté nouvellement produit ne peut être étendue au delà de l'heure de renew-till du TGT.

   Si l'option ENC-TGT-IN-SKEY a été spécifiée et si un ticket supplémentaire a été inclus dans la demande, il indique que le client utilise l'authentification d'utilisateur à utilisateur pour prouver son identité à un serveur qui n'a pas d'accès à une clé persistante. Lors de la génération du message KRB_TGS_REP, cette option dans le message KRB_TGS_REQ dit au KDC de déchiffrer le ticket supplémentaire en utilisant la clé pour le serveur auquel le ticket supplémentaire a été produit et de vérifier qu'il est un TGT. Si le nom du serveur demandé manque dans la demande, le nom du client dans le ticket supplémentaire sera utilisé. Autrement, le nom du serveur demandé sera comparé au nom du client dans le ticket supplémentaire. Si c'est différent, la demande sera rejetée. Si la demande réussit, la clé de session provenant du ticket supplémentaire sera utilisée pour chiffrer le nouveau ticket produit au lieu d'utiliser la clé du serveur pour lequel le nouveau ticket sera utilisé.

   si (a) le nom du serveur dans le ticket qui est présenté au KDC au titre de l'en-tête d'authentification n'est pas celui du TGS lui-même, (b) le serveur est enregistré dans le domaine de ce KDC, et (c) l'option RENEW est demandé, donc le KDC va vérifier que le flag RENEWABLE est mis dans le ticket, que le flag INVALID n'est pas mis, et que le temp renew-till est dans le future. Si l'option VALIDATE est requis, le KDC va vérifier que le starttime a passé et que le flag INVALID est mis. Si l'option PROXY est demandé, le KDC va vérifier que le flag PROXIABLE est mis dans le ticket. Si le test réussis et que le ticket passe toutes les vérifications décris dans la prochaine section, le KDC va fournir le nouveau ticket approprié.

   La parie ciphertext de la réponse dans le message KRB_TGS_REP est chiffrée dans la clé de sous-session de l'authentifiant, si présent, ou dans la clé de session du TGT. Elle n'est pas chiffré en utilisant la clé secrète du client. De plus, les champs de date d'expiration de la clé du client et de numéro de version de clé sont laissés de côté car ces valeurs sont stockées avec les enregistrements de la base de données du client, et il n'y a pas besoin de cet enregistrement pour satisfaire une demande sur la base d'un TGT.

Recherche de tickets révoqués

Chaque fois qu'une demande est faite au TGS, le ou les tickets présentés sont confrontés à une liste rouge de tickets annulés. Celle liste peut être mise en œuvre en mémorisant une gamme d'horodatages de production de tickets suspects; si un ticket présenté a un authtime dans cette gamme, il sera rejeté. De cette façon, un TGT volé ou un ticket renouvelable ne peut pas être utilisé pour obtenir des tickets supplémentaires une fois que le vol a été rapporté au KDC pour le domaine dans lequel réside le serveur. Tout ticket normal obtenu avant qu'il ait été rapporté volé sera toujours valide ( parce que les tickets n'exigent pas l'interaction avec le KDC ), mais seulement jusqu'à son heure d'expiration normale. Si les TGT ont été produites pour une authentification inter-domaine, l'utilisation du TGT inter-domaine se sera pas affectée sauf si la liste rouge est transmise aux KDC pour les domaines pour lesquels de tels tickets inter-domaine avaient été produits.

Codage du champ de transit

   Si l'identité du serveur dans le TGT qui est présenté au KDC au titre de l'en-tête d'authentification est celle du service d'allocation de tickets, mais si le TGT a été produit à partir d'un autre domaine, le KDC va chercher la clé inter-domaines partagée avec ce domaine et utiliser cette clé pour déchiffrer le ticket. Se le ticket est valide, le KDC va alors honorer la demande, sous réserve des contraintes soulignées ci-dessus au paragraphe qui décrit l'échange d'AS. La partie domaine de l'identité du client sera tirée du TGT. Le nom de domaine qu'a produit le TGT, si ce n'est par le domaine du principal client, sera ajouté au champ de transit du ticket à produire. Ceci est accomplis en lisant le champ de transit d'après de TGT ( qui est traité comme un ensemble non ordonné de noms de domaines ), en ajoutant le nouveau domaine à l'ensemble, et en construisant et écrivant sa forme ( abrégée ) codée (ce qui peut impliquer un réarrangement du codage existant ).

   Noter que le service d'allocation de tickets n'ajoute pas le nom de son propre domaine. Au lieu de cela, sa responsabilité est d'ajouter le nom du domaine précédent. Cela empêche un serveur Kerberos malveillant d'inscrire intentionnellement son propre nom ( il pourrais cependant omettre les noms d'autres domaines ).

   Ni les noms du domaine local ni ceux du domaine du principal ne sont à inclure dans le champ de transit. Ils apparaissent ailleurs dans le ticket et tous deux sont connus pour prendre part à l'authentification du principal. Parce que les points d'extrémité ne sont pas inclus, aussi bien l'authentification inter-domaine local que celle à un seul bond résulte en un champ de transit qui est vide.

   Comme à ce champ est ajouté le nom de chaque domaine de transit, il peut éventuellement être très long. Pour diminuer la longueur de ce champ, son contenu est codé. Les codages initialement acceptés sont optimisés sur le cas normal de communication inter-domaine: un arrangement hiérarchique de domaines utilisant les noms de domaine de style domaine ou X.500. Ce codage ( appelé DOMAIN-X500-COMPRESS ) est décris ci-dessous.

   Les noms de domaine dans le champ de transit sont séparés par une ",", les caractères ",", "\", les "." de fin, et les espaces d'en-tête sont des caractères spéciaux, et s'ils font partie d'un nom de domaine, ils doivent être entre guillemets dans le champ de transit en les faisant précéder d'un "\"

   Un nom de domaine se terminant par un "." est interprété comme étant ajouté au domaine précédent. Par exemple, ou peut coder la traversée de EDU, MIT.EDU, ATHENA.MIT.EDU, , WASHINGTON.EDU, et CS.WASHINGTON.EDU par:

  "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS."

  Noter que si ATHENA.MIT.EDU, ou CS.WASHINGTON.EDU étaient des points d'extrémité, ils ne seraient pas inclus dans ce champ, et on aurait:

  "EDU,MIT.,WASHINGTON.EDU"

   Un nom de domaine commençant par un "/" est interprété comme ayant été ajouté au domaine précédent. Pour les besoins de l'ajout, le domaine précédant le premier domaine de la liste est considéré comme le domaine nul (""). Si un nom de domaine commençant par un "/" doit être autonome, il devrait alors être précédé d'un espace (" "). Par exemple, on pour coder la traversée de /COM/HP/APOLLO,/COM/HP,/COM, et /COM/DEC par:

  "/COM,/HP,/APOLLO, /COM/DEC"

  Comme dans l'exemple ci-dessus, si /COM/HP/APOLLO et /COM/DEC étaient des points d'extrémité, ils ne seraient pas inclus dans ce champ:

  "/COM,/HP"

   Un sous-champ nul précédant ou suivant une "," indique que tous les domaines entre le domaine précédent et le prochain domaine ont été traversés. Pour les besoins de l'interprétation des sous-champs nuls, le domaine du client est considéré comme précédant ceux du champ de transit, et le domaine du serveur est considéré les suivre. Et donc, "," signifie que tous les domaines le long du chemin entre le client et le serveur ont été traversées. ",EDU, /COM," signifie que tous les domaines depuis le domaine du client jusqu'à EDU ( dans une hiérarchie de type domaine ) ont été traversés, et que tous depuis /COM jusqu'au domaine du serveur dans un style X.500 ont aussi été traversés. Cela pourrait survenir si le domaine EDU dans une hiérarchie partage une clé inter-domaine directement avec le domaine /COM dans une autre hiérarchie.

Réception du message KRB_TGS_REP

Lorsque le message KRB_TGS_REP est reçu par le client, il est traité de la même manière que le traitement KRB_AS_REP décrit ci-dessus. La principale différence est que la partie chiffrée de la réponse doit être déchiffrée en utilisant la sous-clé de session provenant de l'authentifiant, s'il a été spécifié dans la demande, ou la clé de session provenant du TGT, plutôt que la clé secrète du client. Le nom du serveur retourné dans la réponse est le vrai nom du principal du service.

L'échange KRB_SAFE

Le message KRB_SAFE peut être utilisé par des clients qui exigent la capacité à détecter les modifications des messages qu'ils échangent. Ceci est réalisé en incluant une somme de contrôle à l'épreuve des collisions des données utilisateur et de quelques informations de contrôle. La somme de contrôle est assortie avec une clé de chiffrement ( normalement la dernière clé négociée via des sous-clés, ou la clé de session si aucune négociation n'est survenue.

Génération d'un message KRB_SAFE

   Lorsqu'une application souhaite envoyer un message KRB_SAFE, elle collecte ses données et les informations de contrôle appropriées et calcule une somme de contrôle sur l'ensemble. L'algorithme de somme de contrôle devrait être la somme de contrôle assortie mandatée pour être mise en œuvre ainsi que le système de chiffrement utilisé pour la clé de session ou de sous-session. La somme de contrôle est générée en utilisant la sous-clé de session, si elle est présente, ou la clé de session. Certaines mise en œuvre utilisent un algorithme de somme de contrôle différent pour les messages KRB_SAFE mais il n'est pas toujours possible de faire ainsi de façon interopérable.

   Les informations de contrôle pour le missage KDB_SAFE comportent à la fois un horodatage et un numéro de séquence. Le concepteur d'une application utilisant le message KRB_SAFE doit choisir au moins un des 2 mécanismes. Ce choix devrait se fonder sur les besoins du protocole d'application.

   Les numéros de séquence sont utiles lorsque tous les messages envoyés sont reçus par l'homologue. L'état de connexion est actuellement exigé pour l'entretien de la clé de session, aussi la maintenance du prochain numéro de séquence ne devrait pas présenter de problème supplémentaire.

   Si le protocole d'application est prévu pour tolérer des pertes de messages sans qu'ils soient renvoyés, l'utilisation de l'horodatage est le mécanisme de détection de répétition approprié. L'utilisation des horodatages est aussi le mécanisme approprié pour les protocoles de diffusion groupée dans lesquels tous les homologues partagent une sous-clé de session commune, mais certains messages seront envoyés à un sous-ensemble d'un homologue.

   Après le calcul de la somme de contrôle, le client transmet les informations et la somme de contrôle au receveur.

Réception du message KRB_SAFE

   Lorsqu'une application reçoit un message KRB_SAFE, elle le vérifie comme suit. Si une erreur survient, un code d'erreur est retourné.

   On vérifie d'abord que les champs version et type du protocole du message correspondent respectivement à la version en cours et à KRB_SAFE. Une discordance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application vérifie que la somme de contrôle utilisée est une somme de contrôle à l'épreuve des collisions qui utilise des clés compatibles avec la clé de session ou clé de sous-session selon le cas approprié ( ou la clé d'application déduite des clés de session ou de sous-session ). Si ce n'est pas le cas, une erreur KRB_AP_ERR_INAPP_CKSUM est générée. D'adresse de l'expéditeur doit être incluse dans les informations de contrôle; le receveur vérifie que le rapport du système d'exploitation de l'adresse de l'expéditeur correspond à l'adresse de l'expéditeur dans le message, et ( si une adresse de réception est spécifiée ou si le receveur exige une adresse ) qu'une des adresses du receveur apparaît comme adresse de réception dans le message. Pour travailler avec la traduction d'adresse réseau, les expéditeurs peuvent utiliser le type d'adresse directionnel pour l'adresse d'expéditeur et ne pas inclure d'adresse de receveur. Un échec de correspondance pour l'un de ces cas génère une erreur KRB_AP_ERR_BADADDR. Puis les champs timestamp et usec et/ou de numéro de séquence sont vérifiés. Si timestamp et usec sont attendus et absents, ou s'ils sont présents mais ne sont pas ceux en cours, l'erreur KRB_AP_ERR_SKEW est générée. Il n'est pas exigé que les timestamp soient strictement ordonnées; il est seulement exigé qu'ils soient dans la plage permise. Si les champs nom du serveur, ainsi que nom du client, heure, et microsecondes de l'authentifiant correspondent à de tels tuples récemment vus (envoyés ou reçus), l'erreur KRB_AP_ERR_REPEAT est générée. Si un numéro de séquence incorrect est inclus, ou si un numéro de séquence est attendu mais n'est pas présent, l'erreur KRB_AP_ERR_BADORDER est générée. Si ni un timestamp ni usec ni un numéro de séquence ne sont présents, une erreur KRB_AP_ERR_MODIFIED est générée. Finalement, la somme de contrôle est calculée sur les informations de données te de contrôle, et si elle ne correspond pas à la somme d contrôle reçue, une erreur KRB_AP_ERR_MODIFIED est générée.

   Si toutes les vérification réussissent, l'application est sûr que le message a été généré par son homologue et n'a pas été modifié dans le transit.

   Les mises en œuvre devraient accepter tout algorithme de checksum qui a à la fois la sécurité adéquate et des clés compatibles avec la clé de session ou de sous-session. Les chechsums non keyed ou qui ne sont pas à l'épreuve des collisions ne conviennent pas pour cette utilisation.

L'échange KRB_PRIV

Le message KRB_PRIV peut être utilisé par les clients qui exigent la confidentialité et la capacité à détecter les modifications des messages échangés. Il réalise cela en chiffrant les messages et en ajoutant des informations de contrôle.

Génération du message KRB_PRIV

Lorsqu'une application souhaite envoyer un message KRB_PRIV, elle collecte ses données et les informations de contrôle appropriées et les chiffre avec une clé de chiffrement ( habituellement la dernière clé négociée via des sous-clés, ou la clé de session si aucune négociation n'est survenue ). Au titre des informations de contrôle, le client doit choisir d'utiliser soit un timestamp soit un numéro de séquence (ou les 2). Après le chiffrement des données d'utilisateur et des informations de contrôle, le client transmet le texte chiffré et certaines des informations "d'enveloppe" au receveur.

Réception du message KRB_PRIV

   Lorsqu'une application reçoit un messagse KRB_PRIV, elle le vérifie comme suit. Si une erreur survient, un code d'erreur est rapporté.

   Il est d'abord vérifié que les champs de version et type du protocole du message correspondent respectivement à la version en cours et au KRB_PRIV. Une discordance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application déchiffre ensuite le texte chiffré et traite le texte clair qui en résulte. Si le déchiffrement montre que les données ont été modifiées, une erreur KRB_AP_ERR_BAD_INTEGRITY est générée.

   L'adresse de l'éxpéditeur doit être incluse dans les informations de contrôle; le receveur vérifie que le rapport du système d'exploitation de l'adresse de l'expéditeur correspond à l'adresse de l'expéditeur dans le message. Si une adresse de receveur est spécifiée ou si le receveur exige une adresse, une des adresse du receveur doit également apparaître comme adresse de receveur dans le message. Lorsqu'une adresse d'expéditeur ou de receveur peut ne par correspondre à l'adresse du message à cause d'une traduction d'adresse réseau, une application peut être écrite pour utiliser les adresses du type d'adresse directionnel à la place de l'adresse réseau réelle.

   Après cela intervient la vérification des champs timestamp et usec et/ou de numéro de séquence. Si le timestamp et usec sont attendus et ne sont pas présents, ou s'ils sont présents mais ne sont pas ceux en cours, l'erreur KRB_AP_ERR_SKEW est générée. Si les champs de nom du serveurs, ainsi que le nom du client, l'heure, et microseconde provenant de l'authentifiant correspondent à tout tuple de ces valeurs vu récemment, l'erreur KRB_AP_ERR_REPEAT est générée. Si un numéro de séquence incorrect est inclus, ou si un numéro de séquence est attendu mais n'est pas présent, l'erreur KRB_AP_ERR_BADORDER est générée. Si ni un timestamp, ni usec ni un numéro de séquence n'est présent, une erreur KRB_AP_ERR_MODIFIED est générée.

   Si toutes les vérifications réussissent, l'application peut supposer que le message a été généré par son homologue et a été transmis en toute sécurité.

L'échange KRB_CRED

Le message KRB_CRED peut être utilisé par les clients qui exigent la capacité à envoyer des accréditifs Kerberos d'un hôte à l'autre. Ceci est réalisé par l'envoi des tickets avec les données chiffrées qui contiennent les clés de session et les autres informations associées à ces tickets.

Génération d'un message KRB_CRED

   Lorsqu'une application souhaite envoyer un message KRB_CRED, elle obtient d'abord ( en utilisant l'échange KRB_TGS ) des accréditifs à envoyer à l'hôte distant. Elle construit ensuite un message KRB_CRED en utilisant le ou les tickets ainsi obtenus, plaçant la clé de session qu'il est nécessaire d'utiliser pour chaque ticket dans le champ clé de la séquence KrbCredInfo correspondante dans la partie chiffrée du message KRB_CRED.

   Les autres information associées à chaque ticket et obtenues durant l'échange KRB_TGS sont aussi placées dans la séquence KrbCredInfo correspondante dans la partie chiffrée du message KRB_CRÉD. L'heure courante et, s'ils sont spécifiquement exigés par l'application, les champs nonce, s-address, et r-address sont placés dans la partie chiffrée du message KRB_CRED, qui est alors chiffré avec la clé de chiffrement précédemment échangée dans le KRB_AP ( habituellement la dernière clé négociée via des sous-clés, ou la clé de session si aucune négociation n'est intervenue ).

   Note de mise en œuvre: lors de la construction d'un message KRB_CRED pour l'inclure dans un jeton de contexte initial GSS-API, la mise en œuvre MIT de Kerberos ne chiffrera pas le message KRB_CRED si la clé de session est DES ou triple DES. Pour l'intéropérabilité avec MIT, la mise en œuvre Microsoft ne chiffrera pas le KRB_CRED dans un jeton GSS-API si elle utilise une clé de session DES. MIT Kerberos peut recevoir et décoder des jetons KRB_CRED chiffrés ou non dans l'échange GSS-API. La mise en œuvre Heimdal de Kerberos peut aussi accepter des messages KRB_CRED chiffrés ou non. Comme le message KRB_CRED dans un jeton GSS-API est chiffré dans l'authentifiant, le comportement du MIT ne présente pas de problème de sécurité, bien qu'il soit en violation de la spécification Kerberos.

Réception d'un message KRB_CRED

   Lorsqu'une application reçoit un message KRB_CRED, elle le vérifie. Si une erreur survient, un code d'erreur est rapporté pour être utilisé par l'application Le message est vérifié en s'assurant que les champs de version et type de protocole correspondent respectivement à la version en cours et à KRB_CRED. Une discordance génère une erreur KRB_AP_ERR_BADVERSION ou KRB_AP_ERR_MSG_TYPE. L'application déchiffre alors le texte chiffré et traite le texte clair résultant. Si le déchiffrement montre que les données ont été modifiées, une erreur KRB_AP_ERR_BAD_INTEGRITY est générée.

   Si elle est présente ou exigé, le receveur peut vérifier que le rapport du système d'exploitation sur l'adresse de l'expéditeur correspond à l'adresse de l'expéditeur dans le message, et qu'une des adresse de réception apparaît comme adresse de réception dans le message. La vérification d'adresse ne fournit aucune sécurité supplémentaire, car l'adresse, si elle est présente, a déjà été vérifiée dans le message KRB_AP_REQ et il n'y a aucun intérêt pour un agresseur à retourner un message KRB_CRED à celui qui l'a généré. Et donc, le receveur peut ignorer l'adresse même si elle est présente afin de mieux travailler dans des environnement de traducteur d'adresses réseau (NAT). L'échec de correspondance pour l'un de ces cas génère une erreur KRB_AP_ERR_BADADDR. Les receveurs peuvent sauter la vérification d'adresse, car le message KRB_CRED ne peut généralement pas être reflété à celui qui l'a généré. Les champs timestamp et usec ( et nonce, s'il est exigé) sont vérifiés ensuite. Si timestamp et usec ne sont pas présents, ou s'ils sont présents mais ne sont pas celui en cours, l'erreur KRB_AP_ERR_SKEW est générée.

   Si toutes les vérifications ont réussi, l'application mémorise chacun des nouveaux tickets dans sa mémoire cache d'accréditifs avec la clé de session et les autres informations dans la séquence KrbCredInfo correspondante de la partie chiffrée du message KRB_CRED.

Échanges d'authentification user to user

   L'authentification d'utilisateur à utilisateur fournit une méthode pour effectuer l'authentification lorsque le vérificateur n'a pas accès à un service de clé à long terme. Ce peut être le cas lorsqu'on utilise un serveur (par ex: un serveur Windows) comme utilisateur sur une workstation. Dans un tel cas, le serveur peut avoir accès au TGT obtenu lorsque l'utilisateur se connecte sur la workstation, mais comme le serveur fonctionne comme un utilisateur non privilégié, il peut ne pas avoir accès aux clés du système. Des situations similaires peuvent survenir en faisant fonctionnes des applications paire-à-paire.

   Pour traiter ce problème, le protocole Kerberos permet au client de demander que le ticket produit par le KDC soit chiffré en utilisant une clé de session provenant d'un TGT produit par la partie qui va vérifier l'authentification. Ce TGT doit être obtenu du vérificateur au moyen d'un échange extérieur au protocole Kerberos, habituellement au titre du protocole d'application. Noter que parce que le TGT est chiffré avec la clé secrète du KDC, il ne peut pas être utilisé pour l'authentification sans la possession de la clé secrète correspondante. De plus, parce que le vérificateur ne révèle pas la clé secrète correspondante, fournir le TGT du vérificateur ne permet pas de se faire passe pour le vérificateur.

   Le premier message est une négociation spécifique de l'application entre le client et le serveur, à la fin de laquelle tous deux ont déterminé qu'ils vont utiliser l'authentification d'utilisateur à utilisateur, et le client a obtenu le TGT du serveur.

   Ensuite, le client inclut le TGT du serveur comme ticket supplémentaire dans sa demande KRB_TGS_REQ au KDC et spécifie l'option ENC-TKT-IN-SKEY dans sa demande.

   S'il est validé, le ticket d'application retourné au client va être chiffré en utilisant la cé de session provenant du ticket supplémentaire et le client va le noter lorsqu'il utilise ou mémorise le ticket d'application.

   Lorsqu'il contacte le serveur en utilisant un ticket obtenu pour l'authentification l'utilisateur à utilisateur, le client doit spécifier le flag USE-SESSION-KEY dans le champ ap-options. Cela dit au serveur d'application d'utiliser la clé de session associée à son TGT pour déchiffrer le ticket de serveur fourni dans la demande d'application.

Spécifications de chiffrement et de checksum

   Les protocoles Kerberos décrits dans le présent document sont conçus pour le chiffrement de messages de tailles arbitraires, en utilisant le chiffrement de flux ou de blocs. Le chiffrement est utilisé pour prouver les identités des entités du réseau qui participent à l'échange de messages. Le KDC pour chaque domaine est de confiance pour tous les principaux enregistrés dans ce domaine pour mémoriser une clé secrète. La preuve de la connaissance de cette clé secrète est utilisée pour vérifier l'authenticité d'un principal.

   Le KDC utilise la clé secrète du principal ( dans l'échange d'AS ) ou une clé de session partagée ( dans l'échange de TGS ) pour chiffrer les réponses aux demandes de ticket; la capacité à obtenir la clé secrète ou la clé de session implique la connaissance des clés appropriées et l'identité du KDC. La capacité d'un principal à déchiffrer la réponse du KDC et à présenter un ticket et un authentifiant correctement formé ( généré avec la clé de session provenant de la réponse du KDC ) à un service vérifie l'identité du principal; de même, la capacité du service à extraire la clé de session du ticket et à prouver ainsi sa connaissance du secret dans une réponse vérifie d'identité du service.

   L'opération string-to-key fournie par la rfc3961 est utilisée pour produire une clé à long terme pour un principal ( généralement pour un utilisateur ). La chaîne salt par défaut, si fournis via les données de pré-authentification, est l'enchaînement des composants de domaine et de nom du principal, dans l'ordre, et sans séparateur. Sauf indication contraire, on utilise l'ensemble des paramètres opaque de string-to-key par défaut comme définis dans la rfc3961.

   Les données chiffrées, et les checksums sont transmis en utilisant les objets de données EncryptedData, EncryptionKey, et Checksum. Les opérations de chiffrement, déchiffrement, et de checksums décrites dans le présent document utilisent les opérations correspondantes de chiffrement, déchiffrement, et get_mic décrites dans la rfc3961, avec la génération implicite de clé spécifique utilisant les valeurs de KeyUsage spécifiées dans la description de chaque objet EncryptedDate ou Checksum pour faire varier la clé pour chaque opération. Noter que dans certains cas, la valeur à utiliser dépend de la méthode de choix de la clé ou du contexte du message.

   Les utilisations de clé sont des entiers non signés 32-bits, le 0 n'est pas permis. Les valeurs d'utilisation de clé de 512 à 1023 sont réservés pour des utilisation internes à une mise en œuvre de Kerberos. ( par exemple, alimenter un générateur de nombre pseudo-aléatoire avec une valeur produite en chiffrant quelque chose avec une clé de session et une valeur d'utilisation de clé non utilisée pour un autre objet. ) Les valeurs d'utilisation de clé de 1024 à 2047 sont réservés à l'usage des applications; les applications devraient utiliser des valeurs paires pour le chiffrement et des valeurs impaires pour les checksums dans cette gamme.

   Il peut exister d'autres documents qui définissent les protocoles dans les termes des types de chiffrement ou de checksums de la rfc1510. Ces documents ne connaissent rien sur les utilisations de clé. Afin que ces spécifications continuent d'avoir un sens en attendant leur mise à jour, si aucune valeur d'utilisation de clé n'est spécifié, les utilisation de clé 1024 et 1025 doivent être utilisés pour déduire les clés pour le chiffrement et les checksums, respectivement. ( ceci ne s'applique pas aux protocoles qui ont leur propre chiffrement indépendemment du présent cadre, en utilisant directement la clé qui résulte de l'échange d'authentification de Kerberos. ) De nouveaux protocoles définis en termes de types de chiffrement et de checksum Kerberos devraient utiliser leurs propres valeurs d'utilisation de clé.

   Sauf indication contraire, aucun chaînage d'état de chiffrement n'est fait d'une opération de chiffrement à un autre.

   Note de mise en œuvre: Bien que ce ne soit pas recommandé, certains protocoles d'application vont continuer d'utiliser directement les données de clé, même si c'est seulement dans les spécifications de protocole qui existent actuellement. Une mise en œuvre destinée à prendre en charge les applications Kerberos générales peuvent donc avoir besoin de rendre disponibles les données de clé, ainsi que les attributs et opérations décrits dans la rfc3961. Une des raisons les plus courantes pour effectuer directement le chiffrement est le contrôle direct sur la négociation et le choix d'un algorithme de chiffrement suffisamment fort ( dans le contexte d'une application de données ). Bien que Kerberos ne fournisse pas directement de facilité de négociation des types de chiffrement entre le client et le serveur d'application, il y a des approches qui utilisent Kerberos pour faciliter cette négociation. Par exemple, un client peut ne demander que des types de clé de session suffisamment fort au KDC et espérer que tout type retourné par le KDC sera compris et pris en charge par le serveur d'application.

Spécifications de message

   Le protocole Kerberos est défini ici en termes de notation ASN.1, qui fournit une syntaxe de spécification à la fois de la disposition abstraite des messages du protocole et de leurs codages. Les mises en œuvre qui n'utilisent pas un compilateur ASN.1 existant ou une bibliothèque de soutien devraient avoir une bonne compréhension de la spécification ASN.1 réelle afin de s'assurer d'un comportement correcte de la mise en œuvre.

   Noter qu'en plusieurs endroits, ds changements des types abstraits ont été faits par rapport à la rfc1510. Ceci en partie pour répondre à des hypothèses largement répandues faites par diverses mises en œuvre, qui résultent dans certains cas de violations non intentionnelles de la norme ASN.1. Elles sont clairement mentionnées lorsqu'elles surviennent. Les différences entre les types abstraits de la rfc1510 et les types abstraits dans le présent document peuvent causer l'émission de codages incompatibles quand on utilise certaines règles de codage, par exemple, les règles de codage compact ( PER, Packed Encoding Rules ). Cette incompatibilité théorique ne devrait pas être pertinente pour Kerberos, car Kerberos spécifie explicitement l'utilisation des règles de codage en méta-langage distinctif (DER, Distinguished Encoding Rules). Ce peu être un problème pour les protocoles qui cherchent à utiliser les types de Kerberos avec d'autres règles de codage. ( Cette pratique n'est pas recommandée ) À très peu d'exceptions près ( en particulier d'utilisation du BIT STRING ), les codages résultant de l'utilisation de DER restent identiques entre les types définis dans la rfc1510 et les types définis dans le présent document.

Les définitions de type de la présente section supposent une définition de module ASN.1 de la forme suivante:
KerberosV5Spec2 {
    iso(1) identified-organisation(3) dod(6) internet(1)
    security(5) kerberosV5(2) modules(4) krb5spec2(2)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
    -- reste de la définition ici
END

   Ceci spécifie que le contexte d'étiquetage du module devra être explicite et non automatique. Noter que dans certaines autres publications ( comme la rfc1510 et la rfc1964 ), la portion "dod" de d'identifiant d'objet est spécifiée par erreur comme ayant la valeur de "5". Dans le cas de la rfc1964, l'utilisation de la valeur d'OID correcte résulterait en un changement du protocole du câble; elle reste donc inchangée pour l'instant.

   Noter qu'ailleurs dans le document, la nomenclature de divers types de message est incohérente, mais elle suit largement les conventions du langage C, y compris l'utilisation du caractère souligné (_) et de l'écriture en majuscules de noms destinés à être des constantes numériques. Aussi, à certains endroits, les identifiants ( particulièrement ceux qui se réfèrent à des constantes ) sont écrits en majuscules afin de les distinguer du texte explicatif environnant.

   La notation ASN.1 ne permet pas de souligner dans les identifiants, aussi dans les définitions ASN.1 réelles, les soulignés sont remplacés par le traits d'union (-). De plus, les noms de membre de la structure et les valeur définies en ASN.1 doivent commencer par une lettre minuscule, alors que les noms du types doivent commencer par une majuscule.

Notes de compatibilité ASN.1

Pour les besoins de la compatibilité, les mises en œuvre devraient tenir compte des notes spécifiques suivantes concernant l'utilisation de l'ASN.1 dans Kerberos. Ces notes ne décrivent pas les variantes standard de l'ASN.1. L'objet de ces notes est plutôt de décrire quelques bizarreries historiques et non la conformité de diverses mises en œuvre, ainsi que des ambiguïtés historiques, qui, bien qu'elles soient de l'ASN.1 valide, peuvent amener une certaine confusion dans la mise en œuvre.

Règles de codage distinct ASN.1

Les codage des messages du protocole Kerberos doit obéir aux règles de codage en DER de l'ASN.1 telles que décrites dans X690. Certaines mises en œuvre ( qui sont principalement celles dérivées de DCE 1.1 et antérieures ) sont connues pour utiliser les règles de codage de base ( BER ) les plus générales; en particulier, cet mises en œuvre envoient des codages de longueur indéfinie. Les mises en œuvre peuvent accepter de tels codages dans l'intérêt de la rétro compatibles, bien qu'on doive prévenir les mises en œuvre que le décodage du BER le plus général est plein de périls.

Champs d'entier facultatifs

Certaines mises en œuvre de distinguent par en interne entre une valeur d'entier facultative omise et une valeur transmise de zéro. Les endroits du protocole où ceci est pertinent sont divers champs de micro-secondes, de noms occasionnels, et de numéro de séquence. Les mises en œuvre devraient traiter les valeurs d'entier facultatives omises comme ayant été transmises avec une valeur de zéro, si c'est ce qu'attend l'application.

Types SEQUENCE OF vides

Il y a des endroits du protocole où un message contient un type de SEQUENCE OF qui est un membre facultatif. Il peut en résulter un codage contenant une SEQUENCE OF vide. Le protocole Kerberos ne fait pas de distinction sémantique entre un type de SEQUENCE OF facultatif absent et un type de SEQUENCE OF facultatif présent mais vide. Les mises en œuvre ne devraient pas envoyer de codages de SEQUENCE OF vides marqués OPTIONAL, mais devraient les accepter comme équivalents à un type OPTIONAL vide. Dans la syntaxe ASN.1 qui décrit les messages Kerberos, les instances de ces types de SEQUENCE OF facultatifs problématiques sont indiquées avec un commentaire.

Tag Numbers non reconnus

De futures révisions du présent protocole pourraient comporter de nouveaux types de message avec des numéros d'étiquette de classe APPLICATION différents. De telles révisions devraient protéger les mises en œuvre plus anciennes en envoyant seulement les types de messages que les parties comprennent; par exemple, au moyen d'un flag mis par le receveur dans une demande précédente. Dans l'intérêt de la robustesse du traitement d'erreurs, les mises en œuvre devraient accepter de traiter de toutes façons un message reçu avec une étiquette non reconnue, et retourner le cas échéant un message d'erreur.

En particulier, les KDC devraient retourner KRB_AP_ERR_MSG_TYPE si le tag incorrecte est envoyé sur TCP. Les KDC ne devraient pas répondre aux messages reçus avec un tag inconnus sur UDP afin d'éviter les attaques DOS. Pour les applications non KDC, la mise en œuvre de Kerberos indique normalement une erreur à l'application qui prend les mesures appropriées sur la base du protocole d'application.

Tag Number supérieurs à 30

Une mise en œuvre simple de décodeur ASN.1 DER peut rencontrer des problèmes avec les numéros d'étiquette ASN.1 supérieures à 30, du fait que de tels numéros sont codés en utilisant plus d'un octet. Les révisions futures du présent protocole pourraient utiliser les numéros supérieurs à 30, et les mises en œuvre devraient être préparées à retourner une erreur, le cas échéant, lorsqu'elles ne reconnaissent pas l'étiquette.

Types Kerberos de base

Ce paragraphe définit un certain nombre de types de base qui sont éventuellement utilisés dans plusieurs messages du protocole Kerberos

KerberosString

   La spécification d'origine du protocole Kerberos dans la rfc1510 utilise GeneralString à de nombreux endroits pour les données de chaîne human-readable. Les mise en œuvre historiques de Kerberos ne peuvent pas utiliser toute la puissance de GeneralString. Ce type ASN.1 exige l'utilisation de séquences d'échappement de désignation et d'invocation comme spécifié dans la norme ISO-2022/ECMA-35 pour commuter les ensembles de caractères, et l'ensemble de caractères par défaut qui est conçus désigné sous le nom de G0 est la version de référence internationale ( IRV ) - US ASCII de ISO-646/ECMA-6.

   La nomes ISO-2022/ECMA-35 définit 4 éléments de code d'ensemble de caractèrse (G0 à G3) et 2 éléments de code de fonction de contrôle (C0 à C1). DER interdit la désignation des ensembles de caractères autres que les ensembles G0 et C0. Malheureusement, cela semble avoir l'effet collatéral d'interdire l'utilisation de l'ensemble de caractères ISO Latin (ISO-8859) ou de tout autre ensemble de caractères qui utilise un jeu de 96 caractères, comme ISO-2022/ECMA-35 interdit de les désigner comme l'élément de code G0.

   En pratique, de nombreuses mises en œuvre traitent GeneralStrings comme chaînes 8 bits par défaut quel que soit le jeu de caractères, sans considération de l'utilisation correcte des séquences d'échappement. Le jeu de caractères par défaut est souvent déterminé par la localisation du systèmes d'exploitation de l'utilisateur habituel. Au moins une mise en œuvre majeure place des caractères Unicode codés en UTF-8 dans GeneralString. Cette incapacité à s'en tenir aux spécifications de GeneralString a pour conséquence des problèmes d'interopérabilité lorsque des codages de caractères incompatibles sont utilisés par des client, services et KDC Kerberos.

   Cette situation malheureuse est le résultat d'une documentation défectueuse des restrictions du type ASN.1 de GeneralString dans les spécifications Kerberos précédentes. Le nouveau (post-RFC 1510) type KerberosString, défini ci-dessous est une GeneralString qui a pour contrainte de ne contenir que des caractères en IA5String.

  KerberosString := GeneralString (IA5String)

   En général, les caractères de contrôle US-ASCII ne devraient pas être utilisés dans KerberosString. Les caractères de contrôle ne devraient pas être utilisés dans des noms de principal ou des noms de domaine

   Pour la compatibilité, les implémentations peuvent choisir d'accepter les valeurs de GeneralString qui contiennent des caractères autres que ceux permis par IA5String, mais elles devraient être conscientes que les codes de désignation de jeu de caractères seront vraisemblablement absents, et que le codage devrait probablement presque de toutes façons être traité comme spécifique de la localisation. Les implémentations peuvent aussi choisir d'émettre des valeurs de GeneralString qui sont au-delà ce celles permises par IA5String, mais elles devraient être conscientes que faire cela est extraordinairement risqué du point de vue de l'interopérabilité.

   Certaines mises en œuvre existantes utilisent GeneralString pour coder des caractères spécifiques de la localisation sans échappement. C'est une violation de la norme ASN.1. La plupart de ces mises en œuvre codent l'US-ASCII dans la moitié gauche, aussi tant que la mise en œuvre ne transmet que de l'US-ASCII, la norme ASN.1 n'est pas violée à cet égard. Lorsque ces mises en œuvre codent les caractères sans échappement spécifiques de la localisation avec le bit de plus fort poids établi, cela viole la norme ASN.1

   D'autres mises en œuvre sont connues pour utiliser GeneralString avec un codage UTF-8. Cela aussi est une violation de la norme ASN.1, car UTF-8 est un codage différent, et pas un jeu "G" à 94 ou 96 caractères tel que défini par la norme ISO 2022. On pense que ces mises en œuvre n'utilisent même pas la séquence d'échappement de ISO 2022 pour changer le codage des caractères. Même si les mises en œuvre devaient annoncer le changement de codage en utilisant la séquence d'échappement, la norme ASN.1 interdit l'utilisation de toute séquence d'échappement autre que celles utilisées pour désigner/invoquer les ensembles "G" ou "C" permis par GeneralString.

   De futures révisions de ce protocole permettront presque certainement une représentation plus interopérable des noms de principaux, probablement en y incluant UTF8String. Noter qu'appliquer une nouvelle contrainte à un type qui n'en avait pas auparavant constitue la création d'un nouveau type ASN.1. Dans ce cas particulier, le changement n'aboutit pas à un changement de codage en DER.

Domaine et PrincipalName

Realm ::= KerberosString
PrincipalName ::= SEQUENCE {
    name-type [0] Int32,
    name-string [1] SEQUENCE OF KerberosString
}

   Les noms de domaine Kerberos sont codés comme KerberosStrings. Les domaines se doivent pas contenir de caractère avec le code 0 (US-ASCII NULL). La plupart des domaines vont normalement comporter plusieurs composants séparés par des points, dans le style des noms de domaine Internet, ou séparés par des "/", dans le style des noms X.500. Un PrincipalName est une séquences typée de composants comportant les sous champs suivants:

name-type Ce champ spécifie le type de nom qui suit. Ce champ devrait être traité comme conseil.
name-string Ce champ code une séquence de composants qui forment un nom, chaque composant étant codé comme un KerberosString. Pris ensemble, un PrincipalName et un domaine forment un identifiant de principal.

KerberosTime

KerberosTime ::= GeneralizedTime – sans fraction de seconde

Les horodatages utilisés dans Kerberos sont codés comme GeneralizedTime. Une valeur KerberosTime ne doit pas inclure de portions fractionnée de seconde. Comme exigé par les DER, elle ne doit pas non plus inclure de séparateur, et elle doit spécifier la zone de temps UTC (Z). Exemple: le seul format valide pour l'heure UTC 6 minutes, 27 secondes aprés 21h le 6 novembre 1985 est 19851106210627Z.

Contraintes sur les types entiers

   Certains membres de type entier devraient être contraints à des valeur représentables en 32-bits, pour la compatibilité avec des limites raisonnables d'implémentation.

Int32 ::= INTEGER (-2147483648..2147483647)
    -- valeurs signées représentables en 32 bits
UInt32 ::= INTEGER (0..4294967295)
    -- valeurs de 32 bits non signées
Microseconds ::= INTEGER (0..999999)
    -- microsecondes

   Bien qu'il en résulte des changements des types abstraits de la version de la rfc1510, le codage DER ne devrait pas être altéré. Les anciennes implémentations étaient normalement limitées à des valeurs d'entier 32-bits, et les numéros alloués devraient entrer dans l'espace des valeurs entières représentables en 32-bits afin de promouvoir l'intéropérabilité. Plusieurs champs d'entiers dans les messages sont contraints à des valeurs fixes.

pvno comme TGT-VNO ou AUTHENTICATOR-VNO, ce champ récurant vaut toujours 5.
msg-type Ce champ est habituellement identique au tagNumber d'application du type de message qui le contient

HostAddress et HostAddresses

HostAddress ::= SEQUENCE {
    addr-type [0] Int32,
    address [1] OCTET STRING
}

   Note:HostAddress est toujours utilisé comme champ OPTIONAL et ne devrait pas être vide. Le codage d'adresse d'hôte comporte 2 champs:

addr-type Ce champ spécifie le type d'adresse suivant.
address Code une seule adresse du type addr-type.

AuthorizationData

AuthorizationData est toujours utilisé comme champ OPTIONAL et ne devrait pas être vide.
AuthorizationData
::= SEQUENCE OF SEQUENCE {
    ad-type [0] Int32,
    ad-data [1] OCTET STRING
}

ad-data Contient des données d'authorisation à interpréter conformément à la valeur du chanp ad-type correspondant
ad-type Spécifie le format du sous-champ ad-data.

   Chaque séquence de type et données est perçue comme un élément d'autorisation. Les éléments peuvent être spécifiques à l'application; cependant, il y a un jeu commun d'éléments récursifs qui devraient être compris par toutes les implémentations. Ces éléments contiennent d'autres éléments embarqués, et l'interprétation de l'élément encapsulé détermine lequel des éléments embarqués doit être interprétés, et ceux qui peuvent être ignorés.

   Ces éléments de données d'autorisation communs sont définis récursivement, signifiant que ad-data pour ces types va lui-même contenir une donnée de séquence d'autorisation. dont l'interprétation est affectée par l'élément encapsulant. En fonction de la signification de l'élément encapsulant, les éléments encapsulés peuvent être ignorés, pourraient être interprétés produit directement par le KDC, ou pourraient être stockés dans une partie plaintext séparé du ticket. Les types d'éléments encapsulant sont spécifiés comme partie de la spécification Kerberos parce que comportement fondé sur ces valeurs devrait être compris te toutes les implémentations, alors que d'autre éléments n'ont besoin d'être compris que par les applications qu'ils affectent.

   Les éléments de données d'autorisation sont considérés comme critiques s'ils sont présents dans un ticket ou un authentifiant. Si un type d'élément de données d'autorisation inconnu est reçu par un serveur dans un AP-REQ ou dans un ticket contenu dans un AP-REP, alors, sauf s'il est encapsulé dans un élément de données d'autorisation commun qui amende la criticité des éléments qu'il contient, l'authentification doit échouer. Les données d'autorisation sont destinées à restreindre l'utilisation d'un ticket. Si le service ne peut pas déterminer si la restriction s'applique à ce service, il peut en résulter une faiblesse de la sécurité de l'utilisation de ce ticket pour ce service. Les éléments d'autorisation qui sont facultatifs peuvent être inclus dans un élément AD-IF-RELEVANT.

Contenu des ad-data__________________ad-type
Codage DER de AD-IF-RELEVANT_________1
Codage DER de AD-KDCIssued___________4
Codage DER de AD-AND-OR______________5
Codage DER de AD-MANDATORY-FOR-KDC___8

IF-RELEVANT

   AD-IF-RELEVANT ::= AuthorizationData

  Les éléments encapsulés au sein de l'élément if-relevant sont destinés seulement à être interprétés par les serveurs d'application qui comprennent le ad-type particulier de l'élément incorporé. Les serveurs d'application qui ne comprennent pas le type d'un élément incorporé au sein de l'élément if-relevant peuvent ignorer l'élément non interprétable. Cet élément aide à l'interopérabilité des implémentations qui peuvent avoir des extensions locales pour l'autorisation.

  Le ad-type pour AD-IF-RELEVANT est (1)

KDCIssued

AD-KDCIssued ::= SEQUENCE {
    ad-checksum [0] Checksum,
    i-realm [1] Realm OPTIONAL,
    i-sname [2] PrincipalName OPTIONAL,
    elements [3] AuthorizationData
}

ad-checksum ckecksum cryptographique calculés sur le codage DER de AuthorizationData dans le champ "elements", keyed avec la clé de session. Son checksumtype est le type de checksum obligatoire pour le type de chiffrement de la clé de sessio, et sa valeur d'utilisation de clé est 19.
i-realm, i-sname Le nom du principal qui émet, s'il est différent de celui du KDC. Ce champ devrait être utilisé lorsque le KDC peut vérifier l'authenticité des éléments signés par le principal qui émet, et permet au KDC de notifier au serveur d'application la validité de ces éléments.
elements Séquence d'éléments de données d'autorisation produite par le KDC.

   Le champ ad-data produit par le KDC est destiné à fournir un moyen pour que les accréditifs de principal Kerberos incorporent en leur sein les attributs de privilège et autres mécanismes d'autorisation positive, amplifiant les privilèges du principal au-delà de ce qui peut être fait en utilisant des accréditifs sans un tel élément a-data.

   Les moyens ci-dessus ne peuvent être fournis sans cet élément à cause de la définition du champ authorization-data qui permet d'ajouter des éléments à volonté par le porteur d'un TGT au moment où il demande les tickets de service, et des éléments peuvent aussi être ajoutés à un ticket délégué par inclusion dans l'authentifiant.

   Pour les éléments produits par le KDC, ceci est empêché parce que les éléments sont signés par le KDC en incluant un checksum chiffrée en utilisant la clé du serveur (la même que celle utilisée pour chiffrer le ticket ou une clé dérivée de cette clé). Les éléments encapsulés avec l'élément produit par le KDC doivent être ignorés par le serveur d'application si cette signature n'est pas présente. De plus, les éléments encapsulés au sein de cet élément à partir d'un TGT peuvent être interprétés par le KDC, et utilisés comme base, conformément à la politique, pour inclure des éléments nouvellement signés au sein de tickets dérivés, mais ils ne seront par copiés directement sur un ticket dérivé. S'ils sont copiés directement sur un ticket dérivé par un KDC qui n'est pas au courant de cet élément, la signature ne sera pas correcte pour les éléments de ticket d'application, et le champ sera ignoré par le serveur d'application.

   Cet élément et les éléments qu'il encapsule peuvent être ignorés en toute sécurité par les applications, serveur d'application, et KDC qui n'implémentent pas cet élément.

AND-OR

AD-AND-OR ::= SEQUENCE {
    condition-count [0] Int32,
    elements [1] AuthorizationData
}

   Lorsque des éléments AD restrictifs sont encapsulés au sein de l'élément and-or, l'élément and-or est considéré comme satisfait si et seulement si au foins le nombre d'éléments encapsulés spécifié dans condition-count est satisfait. Donc, cet élément peut être utilisé pour mettre en œuvre une opération "ou" en réglant le champ condition-count à 1, et il peut spécifier une opération "et" en réglant le compte de condition au nombre d'éléments incorporés. Les serveurs d'application qui ne mettent pas en œuvre cet élément doivent rejeter les tickets qui contiennent des éléments de données d'autorisation de ce type. Le ad-type pour AD-AND-OR est (5)

MANDATORY-FOR-KDC

AD-MANDATORY-FOR-KDC ::= AuthorizationData

Les éléments AD encapsulés au sein de l'élément mandatory-for-kdc sont à interpréter par le KDC. Les KDC qui ne comprennent pas le type d'un élément incorporé au sein de l'élément mandatory-for-kdc doivent rejeter la demande. Le ad-type pour AD-MANDATORY-FOR-KDC est (8)

PA-DATA

   Historiquement, les PA-DATA étaient connues comme des données de pré-authentification, ce qui signifie qu'elles étaient utilisée pour augmenter l'authentification initiale auprès du KDC. Depuis cette époque, elles ont aussi été utilisées comme trou typé avec lequel on étend les échanges de protocoles avec le KDC.

PA-DATA ::= SEQUENCE {
    -- NOTE : la première étiquette est [1], et non [0]
    padata-type [1] Int32,
    padata-value [2] OCTET STRING -- peut être codée AP-REQ
}

padata-type Indique la façon d'interpréter l'élément padata-value. Les valeurs négatives de padata-type sont réservées pour des utilisations non-enregistrées; les valeurs non négatives sont utilisée pour une interprétation répertoriée du type d'élément.
padata-value Contient habituellement le codage DER d'un autre type; le champ padata-type identifie quel type est codé ici.

type de padata__Nom_______________Contenu de la valeur padata
1_______________pa-tgs-req________Codage en DER de AP-REQ
2_______________pa-enc-horodatage_Codage en DER de PA-ENC-TIMESTAMP
3_______________pa-pw-salt________sel (non codé en ASN.1)
11______________pa-etype-info_____Codage en DER de ETYPE-INFO
19______________pa-etype-info2____Codage en DER de ETYPE-INFO2

   Ce champ peut aussi contenir des informations nécessaires à certaines extensions au protocole Kerberos. Par exemple, il peut être utilisé pour vérifier l'identité d'un client avant qu'aucune réponse ne soit retournée.

   Le champ padata peut aussi contenir les informations nécessaires pour aider le KDC ou le client à choisir la clé nécessaire pour générer ou déchiffrer la réponse. Cette forme de padata est utile pour la prise en charge de l'utilisation de certaines cartes avec Kerberos.

PA-TGS-REQ

Dans le cas de demandes de tickets supplémentaire KRB_TGS_REQ, padata-value contient une AP-REQ coddée. La somme de contrôle dans l'authentifiant ( qui doit être à l'épreuve des collisions ) est à calculer sur le codage de KDC-REQ-BODY.

Pré-authentification à timestamp chiffré

   Il y a des types de pré-authentification qui peuvent être utilisés pour pré-authentifier un client au moyen d'un timestamp chiffré.

PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC

PA-ENC-TS-ENC ::= SEQUENCE {
    patimestamp [0] KerberosTime -- client's time --,
    pausec [1] Microseconds OPTIONAL
}

   patimestamp contient l'heure du client, et pausec contient les microsecondes, qui peuvent être omises si un client ne va pas générer plus d'une demande par seconde. Le texte chiffré ( padata-value ) comporte le codage de PA-ENC-TS-ENC, chiffré en utilisant la clé secrète du client et une valeur d'utilisation de clé de 1.

PA-PW-SALT

padata-value pour ce type de pré-authentification contient de salt pour le string-to-key à utiliser par le client pour obtenir la clé pour déchiffrer la partie chiffrée d'un message AS-REP. Malheureusement, pour des raisons historiques, l'ensemble de caractères à utiliser n'est pas spécifié et probablement spécifique à la localisation.

Dans l'exemple trivial, une chaîne de salt de longueur 0 est très courant pour les domaines qui ont converti leur bases de données de principal depuis une version 4. Un KDC ne devrait par envoyer PA-PW-SALT lorsqu'il produit un message KRB-ERROR qui demande une pré-authentification supplémentaire. Note d'implémentation: Certaines implémentations de KDC produisent un PA-PW-SALT erroné lorsqu'elle envoient un message KRB-ERROR qui demande une pré-authentification supplémentaire. Donc, les clients devraient ignorer un PA-PW-SALT accompagnant un KDC-ERROR qui demande une pré-authentification supplémentaire. Un KDC ne doit pas envoyer PA-PW-SALT lorsque le AS-REQ du client comporte au moins un etype "newer".

PA-ETYPE-INFO

   Le type de pré-authentification ETYPE-INFO est envoyé par le KDC dans un KRB-ERROR indiquant l'exigence d'une pré-authentification supplémentaire. Il est habituellement utilisé pour notifier à un client quelle clé utiliser pour le chiffrement d'un timestamp chiffré pour les besoins de l'envoi d'une valeur PA-ENC-TIMESTAMP de pré-authentification. Il peut aussi être envoyé dans un AS-REP pour fournir des informations au client sur le salt de clé à utiliser pour le string-to-key que le client doit utiliser pour obtenir la clé de déchiffrement de la partie chiffrée du AS-REP.

ETYPE-INFO-ENTRY ::= SEQUENCE {
    etype [0] Int32,
    salt [1] OCTET STRING OPTIONAL
}
ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY

   Le salt, comme celui de PA-PW-SALT, est aussi complètement non spécifié par rapport au jeu de caractères et est probablement spécifique à la localisation. Si ETYPE-INFO est envoyé dans un AS-REP, il doit être exactement un ETYPE-INFO-ENTRY, et son etype doit correspondre à celui du enc-part dans AS-REP. Un KDC ne doit pas envoyer PA-ETYPE-INFO lorsque le AS-REQ du client comporte un moins un etype "newer".

PA-ETYPE-INFO2

   Le type de pré-authentification ETYPE-INFO2 est envoyé par le KDC dans un KRB-ERROR indiquant l'exigence d'une pré-authentification supplémentaire. Il est habituellement utilisé pour notifier à un client quelle clé utiliser pour le chiffrement d'un timestamp chiffré pour les besoins de l'envoi d'une valeur PA-ENC-TIMESTAMP de pré-authentification. Il peut aussi être envoyé dans un AS-REP pour fournir des informations au client sur le salt de clé à utiliser pour le string-to-key que le client doit utiliser pour obtenir la clé de déchiffrement de la partie chiffrée du AS-REP

ETYPE-INFO2-ENTRY ::= SEQUENCE {
    etype [0] Int32,
    salt [1] KerberosString OPTIONAL,
    s2kparams [2] OCTET STRING OPTIONAL
}
ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY

   Le type de salt est un KerberosString, mais les installations existantes peuvent avoir des caractères spécifiques de la localisation mémorisés dans le chaînes de salt, et les développeurs peuvent choisir de les traiter. L'interprétation de s2kparams est spécifiée dans la description du cryptosystem associé au etype. Chaque cryptosystem a une interprétation par défaut de s2kparams qui restera si cet élément est omis dans le codage de ETYPE-INFO2-ENTRY.

   Si ETYPE-INFO2 est envoyé dans un AS-REP, il doit être exactement un ETYPE-INFO2-ENTRY, et son etype doit correspondre à celui du enc-part dans le AS-REP. L'ordre préféré des données de pré-authentification conseillé qui affecte le choix de clé du client est: ETYPE-INFO2, suivi par ETYPE-INFO, suivi par PW-SALT. Un KDC ne doit pas envoyer de ETYPE-INFO ou PW-SALT lorsque AS-REQ comporte au moins un etype "newer".

KerberosFlags

KerberosFlags ::= BIT STRING (SIZE (32..MAX))
    -- nombre minimum de bits qui doivent être envoyés, mais pas moins de 32

   Note de compatibilité: les paragraphes suivants décrivent un changement par rapport à la description de la rfc1510 des chaînes binaires qui résulteraient en une incompatibilité dans le cas d'une mise en œuvre strictement conforme au DER de l'ASN.1 et à la RFC1510.

   Les chaînes binaires ASN.1 ont plusieurs utilisations. L'utilisation la plus simple d'une chaîne est de contenir un vecteur de bits, sans signification particulière attachée aux bits individuels. Ce vecteur de bits n'est pas nécessairement un multiple de 8 bits de longueur. L'utilisation par Kerberos d'une chaîne binaire comme vecteur booléen compact dans lequel chaque élément a une signification distincte pose quelques problèmes. La notation naturelle pour un vecteur booléen compact est la notation ASN.1 "NamedBit", et les DER exigent que les codages d'une chaîne binaire qui utilise la notation "NamedBit" excluent tous bits à zéro en queue. Il est facile de négliger cette troncature, tout particulièrement dans les implémentations de langage C qui choisissent naturellement de mémoriser les vecteur booléens comme des entiers de 32bits.

   Par exemple, si la notation de KDCOptions devait inclure la notation "NamedBit", comme dans la rfc1510, et si la valeur KDCOptions à coder avait seulement le bit "transmissible" (bit numéro 1) mis, le codage DER doit n'inclure que 2 bits: le premier est à 0 et est réservé, et le bit de valeur 1 pour transmissible.

   La plupart des implémentations de Kerberos envoient inconditionnellement 32 bits sur le réseau lors du codage de chaînes binaires utilisée comme vecteurs booléens. Ce comportement viole la syntaxe ASN.1 utilisée pour les valeurs de flag dans la rfc1510, mais cela survient si fréquemment que la description du protocole en est modifiée pour s'en accommoder.

   Par conséquent, le présent document retire la notation "NamedBit" pour les bits individuels, les relèguant en commentaires. La contrainte de taille sur le type KerberosFlags exige qu'au moins 32 bits soient codés à tout moment, bien qu'une implémentation laxiste puisse choisir d'accepter moins de 32bits et de traiter les bits manquants comme mis à 0.

   Actuellement, aucune utilisation de KerberosFlags ne spécifie plus de 32bits de flags, bien que de futures révisions du présent document puissent le faire. Lorsque plus de 32 bits sont à transmettre dans une valeur de KerberosFlags, les futures révisions du présent document spécifieront spécifieront vraisemblablement que le plus petit nombre de bits nécessaires pour coder le bit de valeur un de plus haut rang devrait être envoyé. Ceci est assez similaire au codage en DER d'une chaîne binaire qui est déclarée avec la notation "NamedBit".

Type liés au cryptosystem

   De nombreux messages de protocole Kerberos contiennent un EncryptedData comme conteneur pour des données chiffrées de façon arbitraire, qui sont souvent le codage chiffré d'un autre type de données. Les champs au sein de EncryptedData assistent le receveur dans le choix d'une clé pour le déchiffrer

EncryptedData ::= SEQUENCE {
    etype [0] Int32 -- EncryptionType --,
    kvno [1] UInt32 OPTIONAL,
    cipher [2] OCTET STRING – texte chiffré
}

etype Ce champ spécifie l'algorithme de chiffrement utilisé pour chiffrer le texte
kvno Ce champ contient le numéro de version de clé utilisée pour chiffrer les données. n'est présent que dans les messages chiffrés avec des clés à longue durée.
cipher Contient le texte chiffré.

   Le type EncryptionKey est le moyen par lequel les clés cryptographiques utilisée pour le chiffrement sont transférées.

EncryptionKey ::= SEQUENCE {
    keytype [0] Int32 -- actually encryption type --,
    keyvalue [1] OCTET STRING
}

keytype Spécifie le type de chiffrement de la clé de chiffrement qui suit dans le champ keyvalue.
keyvalue Contient la clé elle-même, codée comme une chaîne d'octet.

   Les messages qui contiennent des données de texte en clair à authentifier le feront habituellement en utilisant un membre du type Checksum. La plupart des instances de Checksums utilisent un hachage chiffré, bien que des exceptions existent.

Checksum ::= SEQUENCE {
    cksumtype [0] Int32,
    checksum [1] OCTET STRING
}

cksumtype Indique l'algorithme utilisé pour générer la somme de contrôle qui l'accompagne
checksum Contient la somme de contrôle elle-même.

Tickets

   Ce paragraphe décrit les paramètres de format et de chiffrement pour les tickets et les authentifiants. Lorsqu'un ticket ou un authentifiant est inclus dans un message de protocole, il est traité comme un objet opaque. Un ticket est un enregistrement qui aide un client à s'authentifier auprès d'un service. Un ticket contient les informations suivantes:

Ticket ::= [APPLICATION 1] SEQUENCE {
    tkt-vno [0] INTEGER (5),
    realm____[1] Realm,
    sname____[2] PrincipalName,
    enc-part_[3] EncryptedData -- EncTicketPart
}
-- Partie chiffrée du ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
    flags______________[0] TicketFlags,
    key________________[1] EncryptionKey,
    crealm_____________[2] Realm,
    cname______________[3] PrincipalName,
    transited__________[4] TransitedEncoding,
    authtime___________[5] KerberosTime,
    starttime__________[6] KerberosTime OPTIONAL,
    endtime____________[7] KerberosTime,
    renew-till_________[8] KerberosTime OPTIONAL,
    caddr______________[9] HostAddresses OPTIONAL,
    authorization-data_[10] AuthorizationData OPTIONAL
}
-- champs traversés codés
TransitedEncoding ::= SEQUENCE {
tr-type__[0] Int32 -- doit être enregistré --,
contents_[1] OCTET STRING
}
TicketFlags ::= KerberosFlags
    -- reserved(0),
    -- forwardable(1),
    -- forwarded(2),
    -- proxiable(3),
    -- proxy(4),
    -- may-postdate(5),
    -- postdated(6),
    -- invalid(7),
    -- renewable(8),
    -- initial(9),
    -- pre-authent(10),
    -- hw-authent(11),
-- les flags suivants sont nouveaux depuis la RFC 1510
    -- transited-policy-checked(12),
    -- ok-as-delegate(13)

tkt-vno Spécifie le numéro de version pour le format de ticket. Ce document décrit la version 5
realm Spécifie le domaine qui a produit un ticket. Sert à identifier la partie de domaine de l'identifiant de principal du serveur. Comme un serveur Kerberos ne peut produire de tickets que pour des serveurs au sein de son domaine, les deux seront toujours identiques.
sname Spécifie tous les composants de la partie nom de l'identité du serveur, incluant les parties qui identifient une instance spécifique d'un service.
enc-part Contient le codage chiffré de la séquence EncTicketPart. Il est chiffré avec la clé partagée par Kerberos et le serveur d'extrémité (la clé secrète du serveur), en utilisant une clé de valeur d'utilisation de 2.
flags Indique lesquelles des diverses options ont été utilisées ou demandées lorsque le ticket a été produit. La signification des flags est la suivante:

0 (Réserved)
1 (forwardable) Le flag FORWARDABLE n'est normalement interprété que par le TGS, et peut être ignoré par les serveurs d'extrémité. Lorsqu'il est mis, ce flag dit au TGS qu'il est ok pour produire un nouveau TGT avec une adresse réseau différente fondée sur le ticket présenté.
2 (forwarded) Lorsque mis, ce flag indique que le ticket a été transmis ou a été produit sur la base d'une authentification impliquant un TGT transmis.
3 (proxiable) Normalement interprété que par le TGS et est identique que FORWARDABLE, excepté qu'il dit au TGS que seuls des non-TGT peuvent être produits avec des adresses réseau différentes.
4 (proxy) Indique que ce ticket a été mandaté
5 (may-postdate) Normalement interprété que par le TGS et indique qu'un ticket post-daté peut être produit sur la base de ce TGT.
6 (postdated) Indique que ce ticket est post-daté
7 (invalid) Indique que ce ticket est invalide, et qu'il doit être validé par le KDC avant utilisation.
8 (renewable) Normalement interprété que par le TGS et peut être utilisé pour obtenir un ticket de remplacement qui expire à une date ultérieur.
9 (initial) Indique que ce ticket a été produit en utilisant le protocole d'AS, et non pas produit sur la base d'un TGT.
10 (pre-authent) Indique que durant l'authentification initiale, le client a été authentifié par le KDC avant la production d'un ticket.
11 (hw-authent) Indique que le protocole utilisé pour l'authentification initiale exige l'utilisation d'un matériel.
12 (transited-policy-checked) Indique que le KDC pour le domaine a vérifié le champ de transit par rapport à une politique définie par le domaine en matière de certificateurs de confiance. Si ce flag est à 0, le serveur d'application doit alors vérifier le champ de transit lui-même, et s'il est incapable de le faire, il doit rejeter l'authentification. Si le flag est à 1, le serveur d'application peut alors s'affranchir de la vérification.
13 (ok-as-delegate) Indique que le serveur ( et non le client ) spécifié dans le ticket a été déterminé par la politique du domaine comme étant un receveur de délégation convenable. Un client peut utiliser la présence de ce flag pour l'aider à décider de déléguer des accréditifs à ce serveur.
14-31 (reserved) Réservé

key Ce champ existe dans le ticket et la réponse du KDC et il est utilisé pour passer la clé de session Kerberos au serveur d'application et au client.
crealm Ce champ contient le nom du domaine dans lequel le client est enregistré et dans lequel l'authentification initiale a eu lieu.
cname Ce champ contient la partie nom de l'identifiant de principal du client.
transited Ce champ donne la liste des noms des domaines Kerberos qui ont pris part à l'authentification de l'utilisateur à qui ce ticket a été produit. Il ne spécifie par l'ordre dans lequel les domaines ont été traversés. Quand les noms des CA sont à incorporer dans le champ de transit ( comme spécifié pour certaines extensions au protocole ), les noms X.500 des CA devraient être transposé en éléments dans ce champ en utilisant la transposition définis dans la rfc2253.
authtime Ce champ indique l'heure de l'authentification initiale du principal désigné. C'est l'heure de production du ticket original sur lequel est fondé ce ticket.
starttime Ce champ dans le ticket spécifie l'heure après laquelle le ticket sera valide. Avec le champ endtime, ce champ spécifié la durée de vie du ticket. S'il est absent, le champ authtime devrait alors être utilisé à la place pour déterminer la durée de vie du ticket.
endtime Ce champ contient l'heure après laquelle le ticket ne sera plus honoré.
renew-till Ce champ n'est présent que dans les ticket qui on le flag RENEWABLE mis. Indique l'heure de fin maximum qui peut être incluse dans un renouvellement. Il peut aussi être vu comme l'heure d'expiration absolue pour le ticket, y compris pour les renouvellements.
caddr Ce champ dans un ticket contient zéro (s'il est omis) ou plusieurs adresses d'hôte. Ce sont les adresses à partir desquelles le ticket peut être utilisé. S'il n'y a pas d'adresse, le ticket peut être utilisé à partir de toute localisation. La décision du KDC de produire, ou par le serveur d'extrémité d'accepter des tickets sans adresse est une décision de politique qui est laissée à Kerberos et aux administrateurs de service d'extrémité; ils peuvent refuser de produire ou d'accepter de tels tickets. À cause du large développement de la traduction des adresses réseau, il est recommandé que les politiques permettent la production et l'acceptation de tels tickets.

   Les adresse réseau sont incluses dans le ticket pour rendre plus difficile à un agresseur d'utiliser des accréditifs volés. Comme la clé de session n'est pas envoyée sur le réseau en clair, les accréditifs ne peuvent pas être volés simplement en écoutant le réseau; un agresseur doit gagner l'accès à une clé de session ( peut-être à travers des failles de la sécurité du système d'exploitation ou une session non surveillée d'un utilisateur négligeant) pour utiliser des tickets volés.

   Noter que l'adresse réseau à partir de laquelle une connexion est reçue ne peut pas être déterminée de façon fiable. Même si elle pouvant l'être, un agresseur qui a compromis la workstation du client pourrait utiliser les accréditifs à partir de là Inclure les adresses réseau ne fait que rendre plus difficile, mais pas impossible, à un agresseur de sortir avec des accréditifs volés et de les utiliser ensuite à partir d'un localisation sûre.

authorization-data Ce champ est utilisé pour passer les données d'autorisation du principal au nom duquel un ticket a été produit au service d'application. Si aucune données d'autorisation n'est incluse, ce champ sera laissé de côté. L'expérience nous montre que le nom de ce champ prête à confusion, et un meilleur nom serait "restrictions".

   Ce champ contient des restrictions à toute autorité obtenue sur la base d'une authentification utilisant le ticket. Il est possible à tout principal en possession d'accréditifs d'ajouter des entrées au champ de données d'autorisation car ces entrées prolongent les restrictions qui peuvent être faites avec le ticket. De telles additions peuvent être faites en spécifiant les entrées supplémentaires lorsqu'un nouveau ticket est obtenu durant l'échange TGS, ou elle peuvent être ajoutées durant une délégation chaînée utilisant le champ de données d'autorisation de l'authentifiant.

   Les données dans ce champ peuvent être spécifiques du service d'extrémité; le champ contiendra les noms des objets spécifiques du service, et les droits de ces objets. Bien que Kerberos ne soit pas concerné par le format du contenu des sous-champs, il en porte les information de type (ad-type).

   En utilisant le champ authorization-data, un principal est capable de produire un mandat valide pour un objet spécifique. Par exemple, un client souhaitant imprimer un fichier peut obtenir qu'un mandat de serveur de fichiers soit passé au serveur d'impression. En spécifiant le nom du fichier dans le champ authorization-data, le serveur de fichiers sait que le serveur d'impression peut seulement utiliser les droits du client lorsqu.il accède au fichier particulier à imprimer.

   On peut construire un service séparé qui fournit l'autorisation ou la certification d'appartenance à un groupe en utilisant le champ authorization-data. Dans ce cas, l'entité qui accorde l'autorisation (et non l'entité autorisée) peut obtenir un ticket en son nom propre (par exemple, le ticket est produit au nom d'un serveur privilégié), et cette entité ajoute des restrictions à sa propre autorité et délègue au client l'autorité restreinte à travers un mandataire. Le client présenterait alors cet accréditif d'autorisation au serveur d'application séparément de l'échange d'authentification. Autrement, de tels accréditifs d'autorisation peuvent être incorporés dans le ticket qui authentifie l'entité autorisée, lorsque l'autorisation est authentifiée séparément en utilisant l'élément de données d'autorisation produit par le KDC.

   De même, si on spécifie le champ authorization-data d'un mandataire et qu'on laisse en blanc les adresses d'hôte, le ticket et la clé de session qui résultent peuvent être traités comme une capacité. Le champ authorization-data est facultatif et n'a pas à être inclus dans un ticket.

Spécification pour les échanges AS et TGS

Ce paragraphe spécifie le format des messages utilisés dans l'échange entre le client et le serveur Kerberos.

Définition de KRB_KDC REQ

   Le message KRB_KDC_REQ n'a pas de numéro d'étiquette d'application par lui-même. Il est incorporé dans KRB_AS_REQ ou KRB_TGS_REQ, qui ont chacune une étiquette d'application, selon que la demande est celle d'un ticket initial ou d'un ticket supplémentaire. Dans les 2 cas, le message est envoyé du client au KDC pour demander des accréditifs pour un service.

Les champs de message sont les suivants:
AS-REQ ::= [APPLICATION 10] KDC-REQ
TGS-REQ := [APPLICATION 12] KDC-REQ

KDC-REQ ::= SEQUENCE { -- NOTE: la première étiquette est [1], pas [0]
    pvno    [1] INTEGER (5) ,
    msg-type    [2] INTEGER (10 -- AS -- | 12 -- TGS --),
    padata    [3] SEQUENCE OF PA-DATA OPTIONAL -- NOTE : non vide --,
    req-body    [4] KDC-REQ-BODY
}

KDC-REQ-BODY ::= SEQUENCE {
    kdc-options    [0] KDCOptions,
    cname    [1] PrincipalName OPTIONAL -- Ne sert que dans AS-REQ --,
    realm    [2] Realm -- Domaine du serveur et aussi du client dans AS-REQ --,
    sname    [3] PrincipalName OPTIONAL, from [4] KerberosTime OPTIONAL,
    till    [5] KerberosTime,
    rtime    [6] KerberosTime OPTIONAL,
    nonce    [7] UInt32,
    etype    [8] SEQUENCE OF Int32 -- Type de chiffrement dans l'ordre de préférence --,
    addresses    [9] HostAddresses OPTIONAL,
    enc-authorization-data    [10] EncryptedData OPTIONAL -- AuthorizationData --,
    additional-tickets    [11] SEQUENCE OF Ticket OPTIONAL -- NOTE : non vide
}

KDCOptions ::= KerberosFlags
        -- reserved(0),
        -- forwardable(1),
        -- forwarded(2),
        -- proxiable(3),
        -- proxy(4),
        -- allow-postdate(5),
        -- postdated(6),
        -- unused7(7),
        -- renewable(8),
        -- unused9(9),
        -- unused10(10),
        -- opt-hardware-auth(11),
        -- unused12(12),
        -- unused13(13),
        -- 15 est réservé pour la canonisation
        -- unused15(15),
        -- 26 n'était pas utilisé dans la rfc 1510
        -- disable-transited-check(26),--
        -- renewable-ok(27),
        -- enc-tkt-in-skey(28),
        -- renew(30),
        -- validate(31)

pvno Inclus dans chaque message de protocole, et spécifie le numéro du protocole. Doit être à 5
msg-type Indique le type d'un message. Il sera presque toujours le même que l'identifiant d'application associé à un message. Il est inclus pour rendre l'identifiant plus facilement accessible à l'application. Pour le message KDC-REQ, ce type sera KRB_AS_REQ ou KRB_TGS_REQ.
padata Contient les données de pré-authentification. Les demandes de tickets supplémentaires ( KRB_TGS_REQ ) doivent contenir un padata de PA-TGS-REQ. Ce champ contient une séquence d'informations d'authentification qui peuvent être nécessaire avant que les accréditifs puissent être produits ou déchiffrés.
req-body Paramètre fictif qui délimite l'extension des champs restants. Si une somme de contrôle est à calculer dur la demande, elle est calculée sur un codage de la séquence KDC-REQ-BODY qui est dans le champ req-body.
kdc-options Ce champ apparaît dans les demandes KRB_AS_REQ et KRB_TGS_REQ et indique les flags que le client veut mettre sur les tickets ainsi que les autres informations qui vont modifier le comportement du KDC. Lorsque c'est approprié, le nom d'une option peut être le même que celui du flag qui est mis par cette option. Bien que dans la plupart des cas le bit dans le champ options soit le même que celui du champ flags, cela n'est pas garanti, aussi il n'est pas acceptable de simplement copier le champ options dans le champ flags. Diverses vérifications doivent être faites avant qu'une option ne soit honorée.

   Le cahmp kdc_options est un champ binaire, où les options choisies sont indiquées par le bit mis, et les option non choisies et les champs réservés ne sont pas mis. La signification des options est la suivante:

0 (Réserved)
1 (FORWARDABLE) Indique que le tickest est fournis avec le flag forwardable mis. Ne peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également forwardable.
2 (FORWARDED) Seulement spécifié dans une demande au TGS et sera honoré si le TGT dans la demande a le bit FORWARDABLE mis.
3 (PROXIABLE) Indique que le tickest est fournis avec le flag proxiable mis. Ne peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également proxiable.
4 (PROXY) Indique que c'est une demande pour un proxy et sera honoré si le TGT dans la demande a le bit PROXIABLE mis.
5 (ALLOW-POSTDATE) Indique que le ticket à fournir doit avoir MAY-POSTDATE mis. Ne peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également MAY-POSTDATE.
6 (POSTDATED) Indique que c'est une demande pour un ticket post-daté. Sera honoré si le TGT sur lequel il est basé a son MAY-POSTDATE mis. Le ticket résultant aura également le flag INVALID mis.
7 (RESERVED)
8 (RENEWABLE) Indique que le ticket à fournir doit avoir son flag RENEWABLE mis. Peut seulement être mis dans la demande initiale, ou dans une sous-demande si le TGT sur lequel il est basé est également renewable
9 (RESERVED)
10 (RESERVED)
11 (RESERVED)
12-25 (RESERVED)
26 (DISABLE-TRANSITED-CHECK) Indique au KDC de ne pas vérifier le champ transited
27 (RENEWABLE-OK) Indique qu'un ticket renouvelable sera acceptable si un ticket avec la durée de vie requise ne peut autrement être fourni, auquel cas un ticket renouvelable peut être produit avec un renew-till égal à l'heure de fin demandée.
28 (ENC-TKT-IN-SKEY) N'est utilisée que par le TGS. indique que le ticket pour le serveur d'extrémité est à chiffrer avec la clé de session provenant du TGT supplémentaire fourni.
29 (RESERVED)
30 (RENEW) N'est utilisé que par le TGS. Indique que la demande est pour un renouvellement. Le ticket fournis est chiffré dans la clé secrète pour le serveur sur lequel il est valide. Ne sera honoré que si le ticket à renouveler a son flag RENEWABLE mis et si renew-till n'est pas passé.
31 (VALIDATE) N'est utilisé que par le TGS. Indique que la demande est pour un ticket post-daté à valider.

cname et sname Ces champs sont les mêmes que ceux décrits pour le ticket plus haut. Le sname ne peut être absent que lorsque l'option ENC-TGT-IN-SKEY est spécifié. Si le sname est absent, le nom du serveur est tiré du nom du client dans le ticket passé comme ticket supplémentaire.
enc-authorization-data Si présent (et ne peut l'être que sous la forme de TGS_REQ), est un codage des authorizations désirées chiffré avec la sous-clé de session si elle est présent dans l'authentifiant, ou avec la clé de session dans le TGT (l'authentifiant et le TGT viennent tous deux du champ padata dans le KRB_TGS_REQ). La valeur d'utilisation de clé utilisée pour le chiffrement est 5 si une sous-clé de session est utilisée, ou 4 si la clé de session est utilisée.
realm Spécifie la partie domaine de l'identifiant de principal du serveur. Dans l'échange AS, c'est aussi la partie domaine de l'identifiant de principal du client.
from Ce champ est inclus dans les demandes de ticket KRB_AS_REQ et KRB_TGS_REQ lorsque le ticket demandé est à post-dater. Il spécifie l'heure de début de validité pour le ticket demandé. Si omis, le KDC devrait uiliser l'heure en cours.
till Contient la date d'expiration demandée par le client dans une demande de ticket. Il n'est pas facultatif, mais si l'heure de fin demandée est "19700101000000Z", le ticket aura l'heure maximum permise par le KDC.
rtime Ce champ est l'heure de renew-till envoyée au KDC dans une demande de ticket. facultatif.
nonce Fait partie de la demande et de la réponse du KDC. Il est destiné à contenir un nombre aléatoire généré par le client. Si le même nombre est inclus dans la réponse chiffrée provenant du KDC, cela montre à l'évidence que la réponse est fraîche et n'a pas été répétée par un attaquant. Les noms occasionnels ne doivent jamais être réutilisés.
etype Ce champ spécfie l'algorithme de chiffrement désiré à utiliser dans la réponse.
addresses Ce champ est inclus dans la demande de ticket, et il est facultativement inclus dans les demandes de tickets supplémentaire provenant du serveur d'allocation de tickets. Il spécifie les adresse à partir desquelles le ticket demandé doit être valide. Normalement, il inclut les adresse de l'hôte du client. Si un proxy est demandé, ce champ contiendra d'autres adresse. Ce champ est généralement copié par le KDC dans le champ cappr du ticket résultant.
additional-tickets Des tickets supplémentaire peuvent être facultativement inclus dans une demande au TGS. Si l'option ENC-TGT-IN-SKEY a été spécifiée, la clé de session provenant du ticket supplémentaire sera alors utilisée à la place de la clé du serveur pour chiffrer le nouveau ticket. Lorsque l'option ENC-TKT-IN SKEY est utilisée pour l'authentification d'utilisateur à utilisateur, ce ticket supplémentaire peut être un TGT produit par le domaine local ou un TGT inter-domaine produit pour le domaine du KDC en cours par un KDC distant. Si plus d'une option exigeant des tickets supplémentaire a été spécifiée, les tickets supplémentaire sont alors utilisés dans l'ordre spécifié par l'ordre des bits des options bits.

Définition de KRB_KDC_REP

   Le format de message KRB KDC_REP est utilisé pour la réponse du KDC à une demande initiale ( AS ) ou à une demande ultérieure ( TGS ). Il n'y a pas de type de message pour KRB_KDC_REP. Le type sera KRB_AS_REP ou KRB_TGS_REP. La clé utilisée pour chiffrer la partie de texte chifrée de la réponse dépend du type de message. Pour KRB_AS_REP, le texte est chiffré avec la clé secrète du client, et le numéro de version de clé du client est inclus dans le numéro de version de clé pour les données chiffrées. Pour KRB_TGS_REP, et texte est chiffré avec la clé de session provenant du TGT utilisé dans la demande. Dans ce cas, aucun numéro de version ne sera présent dans la séquence EncryptedData.

Les champs de message sont les suivants:
AS-REP ::= [APPLICATION 11] KDC-REP
TGS-REP ::= [APPLICATION 13] KDC-REP
KDC-REP ::= SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (11 -- AS -- | 13 -- TGS --),
    padata    [2] SEQUENCE OF PA-DATA OPTIONAL -- NOTE : non vide --,
    crealm    [3] Realm,
    cname    [4] PrincipalName,
    ticket    [5] Ticket,
    enc-part    [6] EncryptedData -- EncASRepPart ou EncTGSRepPart, selon le cas
}
EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
EncTGSRepPar ::= [APPLICATION 26] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
    key    [0] EncryptionKey,
    last-req    [1] LastReq,
    nonce    [2] UInt32,
    key-expiration    [3] KerberosTime OPTIONAL,
    flags    [4] TicketFlags,
    authtime    [5] KerberosTime,
    starttime    [6] KerberosTime OPTIONAL,
    endtime    [7] KerberosTime,
    renew-till    [8] KerberosTime OPTIONAL,
    srealm    [9] Realm,
    sname    [10] PrincipalName,
    caddr    [11] HostAddresses OPTIONAL
}
LastReq ::= SEQUENCE OF SEQUENCE {
    lr-type    [0] Int32,
    lr-value    [1] KerberosTime
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_AS_REP ou KRB_TGS_REP
padata Décrits dans KRB_KDC_REQ. Une utilisation possible est de coder une chaîne salt à utiliser avec un algorithme de string-to-key. C'est utile pour faciliter les transitions si un nom de domaine doit changer; dans un tel cas, toutes les entrées déduites de mot de passe existantes dans la base de données Kerberos auraient un flag marquant qu'elles ont besoin d'une chaîne salt spécial jusqu'au prochain changement de mot de passe.
crealm, cname, srealm, et sname Décrits dans KRB_KDC_REQ.
ticket C'est le ticket nouvellement produit
enc-part Ce champ est un fourre-tout pour le texte chiffré et les informations qui s'y rapportent, qui forme la partie chiffrée d'un message. La description de la partie chiffrée du message suit chaque apparition de ce champ.

   La valeur d'utilisation de clé pour le chiffrement de ce champ est 3 dans un message AS-REP, en utilisant la clé à long-terme du client ou une autre clé choisie via des mécanismes de pré-authentification. Dans un message TGS-REP, la valeur d'utilisation de clé est 8 si la clé de session TGS est utilisée, ou 9 si une sous-clé d'authentifiant TGS est utilisée.

key Ce champ est le même que celui décrit au paragraphe ticket
last-req Ce champ est retourné par le KDC et spécifie l'heure de la dernière demande d'un principal. Selon les informations disponibles, ce peut être la dernière fois qu'une demande de TGT a été faite, ou la dernière fois qu'une demande fondée sur un TGT a réussi. I peut aussi couvrir tous les serveurs d'un domaine, ou juste un serveur particulier. Certaines implémentations peuvent afficher ces informations à l'utilisateur pour aider à découvrir des utilisations non autorisées d'une identité. C'est d'un esprit similaire à l'affichage de la dernière connexion affichée à la connexion dans les systèmes en tamps partagé.
lr-typeCe champ indique comment interpréter le champ lr-value suivant. Les valeurs négatives indiquent que ces informations n'appartiennent qu'au serveur qui répond. Les valeurs non négatives appartiennent à tous les serveurs pour le domaine. Les valeurs possibles sont:

0 Aucune information n'est portée par le sous-champ lr-value.
1 le sous-champ lr-value est l'heure de la dernière demande initiale pour un TGT.
2 Le sous-champ lr-value est l'heure de la dernière demande initiale.
3 Le sous-champ lr-value est l'heure de la production du plus récent TGT utilisé
4 Le sous-champ lr-value est l'heure de la demande du dernier renouvellement
5 Le sous champ lr-value est l'heure de la dernière demande (de tout type).
6 Le sous-champ lr-value est l'heure de l'arrivée à expiration du mot de passe.
7 Le sous-champ lr-value est l'heure de l'arrivée à expiration du compte.

lr-value Ce champ contient l'heure de la dernière demande. L'heure doit être interprété conformément au contenu du sous-champ lr-type qui l'accompagne.
nonce Décrits dans KRB_KDC_REQ.
key-expiration Ce champ fait partie de la réponse du KDC et spécifie l'heure à laquelle la clé secrète du client va arriver à expiration. L'expiration peut être le résultat du vieillissement d'un mot de passe ou de l'expiration d'un compte. S'il est présent, il devrait être réglé au plus tôt de l'expiration de la clé de l'utilisateur et de l'expiration du compte. L'utilisation de ce champ est déconseillé, et le champ last-req devrait être utilisé à la place pour porter ces informations. Ce champ sera normalement laissé en dehors de la réponse TGS car la réponse à une demande de TGS est chiffrée avec une clé de session et aucune information client n'a à être restituée de la base de données du KDC. Il appartient au client d'application ( généralement le programme de connexion) de prendre les mesures appropriées si l'heure d'expiration est imminente.
flags, authtime, starttime, endtime, renew-till et caddr Ces champs sont des duplications de ceux qui figurent dans la portion chiffré du ticket joint, et ils sont fournis pour que le client puisse vérifier qu'ils correspondent à la demande prévue et afin d'aider à une mise en mémoire cache appropriée du ticket. Si le message est du type KRB_TGS_REP, le champ caddr ne sera rempli que si la demande était pour un proxy ou un ticket transmis, ou si l'utilisateur substitue un sous-ensemble des adresses venant du TGT. Si les adresses demandées par le client ne sont pas présentes ou pas utilisées, les adresses contenues dans le ticket devront alors être les mêmes que celles incluses dans le TGT.

Spécifications de message client-serveur

Ce paragraphe spécifie le format des messages utilisée pour l'authentification du client auprès du serveur d'application.

Définition de KRB_AP_REQ

   Le message KRB_AP_REQ contient le numéro de version du protocole Kerberos, le type de message KRB_AP_REQ, un champ d'options pour indiquer toutes les options utilisée, et le ticket et l'authentifiant eux-mêmes. Le message KRB_AP_REQ est souvent désigné comme un en-tête d'authentification.

AP-REQ ::= [APPLICATION 14] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (14),
    ap-options    [2] APOptions,
    ticket    [3] Ticket,
    authenticator    [4] EncryptedData -- Authentifiant
}
APOptions ::= KerberosFlags
    -- reserved(0),
    -- use-session-key(1),
    -- mutual-required(2)

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type estKRB_AP_REQ
ap-options Ce champ apparaît dans la demande d'application KRB_AP_REQ et affecte la façon dont la demande est traitée. C'est un champ binaire, où les options choisies sont indiquées par le bis mis, et les options non choisies à 0. La signification des options est la suivante:

(reserved) 1
(use-session-key) Indique que le ticket que présente le client à un serveur est chiffré avec la clé de session venant du TGT du serveur. Quand cette option n'est pas spécifiée, le ticket est chiffré avec la clé secrète du serveur. 2
(mutual-required) Dit au serveur que le serveur exige l'authentification mutuele, et qu'il doit répondre par un message KRB_AP_REP. 3-31
(reserved)

ticket Ce champ est un ticket authentifiant le client auprès du serveur
authenticator Contient l'authentifiant chiffré, qui inclut le choix d'une sous-clé par le client.

   L'authentifiant chiffré est inclus dans le AP-REQ; il certifie à un serveur que l'envoyeur a une connaissance récente de la clé de chiffrement du ticket d'accompagnement, pour aider le serveur à détecter les répétitions. Il aide aussi au choix d'une vraie clé de session à utiliser dans cette session. Le codage DER de ce qui suit est chiffré avec la clé de session du ticket, avec une valeur d'utilisation de clé de 11 dans les échanges d'application normaux, ou 7 lorsque utilisée comme champ PA-TGS-REQ PA-DATA d'un échange TGS-REQ.

-- Authentifiant non chiffré
Authenticator ::= [APPLICATION 2] SEQUENCE {
    authenticator-vno    [0] INTEGER (5),
    crealm    [1] Realm,
    cname    [2] PrincipalName,
    cksum    [3] Checksum OPTIONAL,
    cusec    [4] Microseconds,
    ctime    [5] KerberosTime,
    subkey    [6] EncryptionKey OPTIONAL,
    seq-number    [7] UInt32 OPTIONAL,
    authorization-data    [8] AuthorizationData OPTIONAL
}

authenticator-vno Spécifie le numéro de version du format de l'authentifiant. Vaut 5
crealm et cname Décrit dans le paragraphe ticket
cksum Contient un checksum des données d'application qui accompagnent le KRB_AP_REQ. calculée en utilisant une valeur d'utilisation de clé de 10 dans les échanges d'application normaux, ou 6 lorsqu'utilisé dans le champ TGS-REQ PA-TGS-REQ AP-DATA
cusec Ce champ contient la partie microsecondes du timestamp du client. sa valeur va de 0 à 999999.
ctime Ce champ contient l'heure en cours sur l'hôte du client
subkey Ce champ contient le choix du client d'une clé de chiffrement à utiliser pour protéger cette session d'application spécifique. Sauf si une application spécifie autre chose, si ce champ est laissé de côté, la clé de session venant du ticket sera utilisée.
seq-number Ce champ optionnel comporte le numéro de séquence initial à utiliser par KRB_PRIV ou KRB_SAFE lorsque les numéros de séquence sont utilisés pour détecter les répétitions.

   Il peut aussi être utilisé par des messages spécifiques de l'application. Lorsqu'il est inclus dans l'authentifiant, ce champ spécifie le numéro de séquence initiale pour les messages du client au serveur. Lorsqu'il est inclus dans le message KRB_PRIV ou KRB_SAFE, il est incrémenté de un après l'envoi de chaque message. Les numéros de séquence sont dans la gamme de 0 à 2^32 -1 puis reviennent à 0.

   Pour que les numéros de séquence prennent adéquatement en charge la détection des répétitions, ils devraient être non-répétitifs, même à travers les frontières de connexion. Le numéro de séquence initiale devrait être aléatoire et uniformément distribué à travers l'espace complet des numéros de séquence possibles, de sorte qu'il ne puisse pas être deviné par un agresseur et de sorte que lui et les numéros de séquence successifs ne répètent pas d'autres séquences. Au cas où plus de 2^32 messages devraient être générés dans une série de message KRB_PRIV ou KRB_SAFE, un changement de clé devrait être effectué avant que les numéros de séquence soient réutilisés avec la même clé de chiffrement.

authorization-data Ce champ est décrit au paragraphe ticket. il est optionnel et n'apparaît que lorsque des restrictions supplémentaires sont à mettre à l'utilisation d'un ticket, au-delà de celles portées par le ticket lui-même.

Définition de KRB_AP_REP

   Le message KRB_AP_REP contient le numéro de version du protocole Kerberos, le type de message, en un timestamp chiffré. Le message est envoyé en réponse à une demande d'application ( KRB_AP_REQ ) pour laquelle l'option d'authentification mutuelle a été choisie dans le champ ap-options.

AP-REP ::= [APPLICATION 15] SEQUENCE {
    vno     [0] INTEGER (5),
    sg-type    [1] INTEGER (15),
    nc-part    [2] EncryptedData -- EncAPRepPart
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
    time    [0] KerberosTime,
    usec    [1] Microseconds,
    ubkey    [2] EncryptionKey OPTIONAL,
    eq-number    [3] UInt32 OPTIONAL
}

nc-part La partie codée EncAPRepPart est chiffrée avec la clé de session partagée du ticket. Le champ de sous-clé facultatif peut être utilisé dans une négociation arrangée par l'application pour choisir une clé de session par association.
pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type estKRB_AP_REP
enc-part Décrits dans KRB_KDC_REQ. Est calculé avec une valeur d'utilisation de clé de 12
ctime Heure courant sur l'hôte du client
cusec partie micro-seconde du timestamp
subkey Contient une clé de chiffrement à utiliser pour protéger cette session d'application spécifique.
seq-number Décrit au paragraphe ticket

Spécification du message KRB_SAFE

   Ce paragraphe spécifie le format d'un message qui peut être utilisé par l'un ou l'autre côté ( client ou serveur ) d'une application pour envoyer un message inaltérable à son homologue. Il suppose qu'une clé de session ait été échangée précédemment. Le message KRB_SAFE contient des données d'utilisateur avec une somme de contrôle à l'épreuve des collisions chiffrée avec la dernière clé de chiffrement négociée via des sous-clés, ou avec la clé de session si aucune négociation n'est intervenue.

Les champs de message sont les suivants:
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (20),
    safe-body    [2] KRB-SAFE-BODY,
    cksum    [3] Checksum
}
KRB-SAFE-BODY ::= SEQUENCE {
    user-data    [0] OCTET STRING,
    timestamp    [1] KerberosTime OPTIONAL,
    usec    [2] Microseconds OPTIONAL,
    seq-number    [3] UInt32 OPTIONAL,
    s-address    [4] HostAddress,
    r-address    [5] HostAddress OPTIONAL
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_SAFE
safe-body Ce champ est un fourre tout pour le corps du message KRB_SAFE
cksum Ce champ contient le checksum des données d'application, calculée avec une valeur d'utilisation de clé de 15. La somme de contrôle est calculée sur le codage de la séquence KRB-SAFE. D'abord, le cksum est mis à un type zéro, valeur de longueur zéro, et la somme de contrôle est calculée sur le codage de la séquence KRB-SAFE. Puis la somme de contrôle est réglée au résultat de ce calcul. Finalement, la séquence KRB-SAFE est codée à nouveau.
user-data Ce champ fait partie des messages KRB_SAFE et KRB_PRIV, et contient les données spécifiques de l'application qui sont passées de l'envoyeur au receveur.
timestamp Ce champ fait partie des messages KRB_SAFE et KRB_PRIV. Heure courante le l'émetteur.
usec partie micro-seconde du timestamp
seq-number Ce champ est décrit au paragraphe ticket
s-address Spécifie l'adresse utilisée par l'eméteur du message
r-address Spécifie l'adresse utilisée par le receveur du message. Il peut être omis pour certaines utilisations ( comme les protocoles de diffusion ), mais le receveur peut arbitrairement rejeter de tels messages. Ce champ, avec s-address, peut être utilisé pour aider à détecter des messages qui on été incorrectement ou malicieusement délivrés à un mauvais receveur.

Spécification du message KRB_PRIV

   Ce paragraphe spécifie le format d'un message qui peut être utilisé par un client et un serveur d'application pour envoyer en toute sécurité et confidentialité un message à son homologue. Il suppose qu'une clé de session ait précédemment été échangée (par exemple, en utilisant les message KRB_AP_REQ/KRB_AP_REP. Le message KRB_PRIV contient des données d'utilisateur chiffrées avec la clé de session.

Les champs de messages sont les suivant:
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type [1] INTEGER (21), -- NOTE : Il n'y a pas d'étiquette [2]
    enc-part    [3] EncryptedData -- EncKrbPrivPart
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
    user-data    [0] OCTET STRING,
    horodatage    [1] KerberosTime OPTIONAL,
    usec    [2] Microseconds OPTIONAL,
    seq-number    [3] UInt32 OPTIONAL,
    s-address    [4] HostAddress -- adresse de l'envoyeur
    r-address    [5] HostAddress OPTIONAL -- adresse du receveur
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_PRIV
enc-part Ce champ détient un codage de la séquence EncKrbPrivPart chiffrée avec le clé de session, avec une valeur d'utilisation de clé de 13. Ce codage chiffré est utilisé pour le champ enc-part du message KRB-PRIV
user-data, horodatage, usec, s-address, et r-address Décrits dans KRB_SAFE
seq-number Décrits dans la section ticket

Spécification du message KRB_CRED

   Ce paragraphe spécifie le format d'un message qui peut être utilisé pour envoyer des accréditifs Kerberos d'un principal à un autre. Il est présenté ici pour encourager l'utilisation d'un mécanisme commun par les applications lors de la transmission des tickets ou la fourniture de mandataires aux serveurs subordonnées. Il suppose qu'une clé de session a déjà été échangée, peut-être en utilisant les message KRB_AP_REQ/KRB_AP_REP. Le message KRB_CRED contient une séquence de tickets à envoyer et les informations nécessaires pour utiliser les tickets, comportant la clé de session de chacun. Les informations nécessaires pour utiliser les tickets sont chiffrées avec une clé de chiffrement échangée précédemment ou transférée à l'aide du message KRB_CRED.

Les champs de message sont les suivants:
KRB-CRED ::= [APPLICATION 22] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (22),
    tickets    [2] SEQUENCE OF Ticket,
    enc-part    [3] EncryptedData -- EncKrbCredPart
}
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
    ticket-info    [0] SEQUENCE OF KrbCredInfo,
    nonce    [1] UInt32 OPTIONAL,
    timestamp    [2] KerberosTime OPTIONAL,
    usec    [3] Microseconds OPTIONAL,
    s-address    [4] HostAddress OPTIONAL,
    r-address    [5] HostAddress OPTIONAL
}
KrbCredInfo ::= SEQUENCE {
    key    [0] EncryptionKey,
    prealm    [1] Realm OPTIONAL,
    pname    [2] PrincipalName OPTIONAL,
    flags    [3] TicketFlags OPTIONAL,
    authtime    [4] KerberosTime OPTIONAL,
    starttime    [5] KerberosTime OPTIONAL,
    endtime    [6] KerberosTime OPTIONAL,
    renew-till    [7] KerberosTime OPTIONAL,
    srealm    [8] Realm OPTIONAL,
    sname    [9] PrincipalName OPTIONAL,
    caddr    [10] HostAddresses OPTIONAL
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_PRIV
tickets Ce sont les tickets obtenus du KDC pour utilisation spécifique par le receveur. Les tickets successifs sont appariés avec la séquence KrbCredInfo correspondante de enc-part du message KRB-CRED
enc-part Ce champ étient un codage de la séquence EncKrbCredPart chiffrée avec la clé de session partagée par l'envoyeur et le receveur prévu, avec une valeur d'utilisation de 14. Ce codage chiffré est utilisé pour le champ enc-part du message KRB-CRED.
nonce Si elle en a la capacité, une application peut exiger l'inclusion d'un nom occasionnel généré par le receveur du message.Si la même valeur est incluse comme nom occasionnel danse le message, cela donne la preuve que le message est frais et n'a pas été répété par un agresseur.
timestamp et usec Ces champs spécifient l'heure à laquelle le message KRB-CRED a été généré. L'heure est utilisée pour fournir l'assurance que le message est frais.
s-address et r-address Décrit dans KRB_SAFE
key Ce champ existe dans le ticket correspondant passé par le message KRB-CRED et est utilisé pour passer la clé de session de l'envoyeur au destinataire prévu.
prealm et pname facultatifs. Nom et domaine de l'entité de principal délégué.
lags, authtime, starttime, endtime, renew-till, srealm, sname, et caddr facultatifs. Ces champs contiennent les valeurs des champs correspondants dans le ticket trouvé dans le champ ticket. Les descriptions des champs sont identiques aux descriptions dans le messages KDC-REP.

Spécification du message KRB_ERROR

   Ce paragraphes spécifie le format du message KRB_ERROR. Les champs inclus dans le message sont destinés à retourner autant d'informations que possible sur l'erreur. On ne s'attend pas à ce que toutes les informations exigées par les champs soient disponibles pour tous.les types d'erreur. Si les informations appropriées ne sont pas disponibles lors de la composition du message, le champ correspondant sera laissé de côté pour ce message. Noter que comme le message KRB_ERROR n'est pas protégé en intégrité, il est assez possible à un attaquant de le synthétiser ou le modifier. En particulier, cela signifie que le client ne devrait pas utiliser ces champs dans ce message pour des besoins critiques pour la sécurité, comme le réglage d'une horloge système ou la génération d'un authentifiant frais. Le message peut cependant être utile pour informer un utilisateur des raisons d'un échec.

Les champs de message sont les suivants:
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
    pvno    [0] INTEGER (5),
    msg-type    [1] INTEGER (30),
    ctime    [2] KerberosTime OPTIONAL,
    cusec    [3] Microseconds OPTIONAL,
    stime    [4] KerberosTime,
    susec    [5] Microseconds,
    error-code    [6] Int32,
    crealm    [7] Realm OPTIONAL,
    cname    [8] PrincipalName OPTIONAL,
    realm    [9] Realm -- domaine du service --,
    sname    [10] PrincipalName -- domaine du service --,
    e-text    [11] KerberosString OPTIONAL,
    e-data    [12] OCTET STRING OPTIONAL
}

pvno et msg-type Décrits dans KRB_KDC_REQ. msg-type est KRB_ERROR
ctime et cusec Ces champs sont décris dans KRB_AP REP.Si les valeurs de ces champs sont connues de l'entité qui génère l'erreur, ils devraient être remplis dans la KRB-ERROR. Se les valeurs ne sont pas disponibles, ces champs peuvent être omis.
stime Ce champ contient l'heure en cours au serveur. Il est du type KerberosTime.
susec Ce champ contient la partie microseconde du timestamp.
error-code Ce champ contient le code d'erreur retourné par Kerberos ou le serveur.
crealm et cname Ces champs sont décrit au paragraphe ticket. Lorsque l'entité qui génère l'erreur connaît ces valeur, elle devraient être remplies dans le KRB-ERROR. Si les valeurs ne sont pas connues, les champs crealm et cname devraient être omis.
realm et sname Ces champs sont décrits dans le paragraphe ticket
e-text Ce champ contient du texte supplémentaire pour aider à expliquer le code d'erreur associé à l'échec de demande.
e-data Ce champ contient des données supplémentaires sur l'erreur à utiliser par l'application. Si le codes d'erreur est KDC_ERR_PREAUTH_REQUIRED, le champ e-data contiendra alors un odage de la séquence des champs padata, chacun correspondant à une méthode acceptable de pré-authentification et contenant facultativement des données pour la méthode: METHOD-DATA ::= SEQUENCE OF PA-DATA

   Pour les codes d'erreur définis dans le présent document autres que KDC_ERR_PREAUTH_REQUIRED, le format et le contenu du champ e-data sont définis par l'implémentation. De même, pour les codes d'erreur futurs, le format et le contenu du champ e-data sera défini par l'implémentation sauf spécification contraire. Qu'ils soient définis par l'implémentation ou dans un document futur, le champ e-data peut prendre la forme de TYPED-DATA:

TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
    data-type    [0] Int32,
    data-value    [1] OCTET STRING OPTIONAL
}

Noms de domaine

   Bien que les noms de domaine soient codés comme des GeneralStrings et que techniquement un domaine puisse choisir le nom qu'il veut, l'intéropérabilité à travers les frontières de domaine exige un accord sur la façon dont les noms de domaine sont alloués et les informations qu'ils comportent.

   Pour mettre en application ces conventions, chaque domaine doit se conformer aux conventions elles-mêmes, et il doit exiger que tout domaine avec lequel il partage des clés inter-domaine se conforme aussi aux conventions et qu'il exige la même chose de ses voisins.

   Les noms de domaine Kerberos sont sensibles à la casse. Les noms de domaine qui ne diffèrent que par la casse des caractères ne sont pas équivalents. Il y a actuellement 3 styles de noms de domaine: domaine, X500, et autre:

domain: ATHENA.MIT.EDU
X500: C=US/O=OSF
autre: NAMETYPE:rest/of.name=without-restrictions

   Les noms de style domaine doivent ressembler à des noms de domaine: Ils comportent des composants séparés par des points et ils ne contiennent ni ":" ni "/". Bien que les noms de domaine eux-mêmes ne soient pas sensibles à la casse, afin que les domaines correspondent, la casse doit aussi correspondre. Lors de l'établissement d'un nouveau nom de domaine fondé sur un nom de domaine internet, il est recommandé par convention que les caractères soient convertis en majuscules.

   Les noms X.500 contiennent le signe égal et ne peuvent pas contenir ":" avant le signe égal. Les noms de domaine pour les noms X.500 doivent être des représentations de chaîne des noms avec des composants séparés par des barres obliques. Les barres obliques en tête et en queue ne seront pas incluses. Noter que la barre oblique de séparation est cohérente avec les implémentations de Kerberos fondées sur la rfc1510, mais elle est différente du séparateur recommandé dans la rfc2253.

   Les noms qui entrent dans la catégorie autre doivent commencer par un préfixe ne contenant pas de signe égal ou point, et le préfixe doit être suivi par ":" et le reste du nom. Tous les préfixes attendent ceux qui commencent à être utilisés. Actuellement, aucun n'est alloué.

   La catégorie réservée comporte des chaînes qui n'entrent pas dans les 3 premières catégories. Tous les noms de cette catégorie sont réservés. Il est peut vraisemblable que des noms soient alloués dans cette catégorie sauf s'il y a de très forts arguments pour ne pas utiliser la catégorie autre.

   Ces règles garantissent qu'il n'y aura pas de conflit entre les divers styles de nom. Les contraintes supplémentaires suivantes s'appliquent à l'allocation de noms de domaine dans les catégories domaine et X.500: le nom d'un domaine pour les formats domaine ou X.500 doit être utilisé par l'organisation propriétaire d'un nom de domaine Internet ou d'un nom X.500, ou, dans le cas où un tel nom n'est pas enregistré, l'autorité pour utiliser un nom de domaine peut être dérivé de l'autorité du domaine parent. Par exemple, s'il n'y a pas de nom de domaine pour E40.MIT.EDU, l'administrateur du domaine MIT.EDU peut alors autoriser la création d'un domaine de ce nom.

   Ceci est acceptable parce que l'organisation à laquelle le parent est alloué est vraisemblablement aussi l'organisation autorisée à allouer des noms à ses enfants dans les systèmes de nom X.500 et domaine. Si le parent alloue un nom de domaine sans l'enregistrer aussi dans la hiérarchie de nom de domaine ou X.500, il est de la responsabilité du parent de s'assurer qu'à l'avenir il n'existe pas un nom identique au nom de domaine de l'enfant sauf s'il est alloué à la même entité comme nom de domaine.

Noms de principal

   Comme c'est le cas pour les noms de domaine, des conventions sont nécessaires pour s'assurer que tous sont d'accord sur les information impliquées par un nom de principal. Le champ name-type qui fait partie du nom de principal indique le type d'informations impliquées par le nom. Le name-type devrait être traité que comme un conseil pour interpréter la signification d'un nom. Il n'y a pas de sens à lui rechercher une équivalence. Les noms de principal qui ne diffèrent que par le name-type identifient le même principal. Le type de nom ne crée pas une partition de l'espace de nom. En ignorant le type de nom, 2 noms ne peuvent être les mêmes. Les types de nom suivants sont définis:

NT-UNKNOWN (0) Type de nom inconnu
NT-PRINCIPAL (1) Seulement le nom du principal comme dans DCE, ou pour les utilisateurs
NT-SRV-INST (2) Service et autre instance unique (krbtgt)
NT-SRV-HST (3) Service avec nom d'hôte comme instance (telnet, rcommands)
NT-SRV-XHST (4) Service avec hôte comme composants restants
NT-UID (5) ID unique
NT-X500-PRINCIPAL (6) Nom distinctif codé en X.509 [RFC2253]
NT-SMTP-NAME (7) Nom en forme de nom de messagerie électronique SMTP (par exemple,user@example.com)
NT-ENTERPRISE (10) Nom d'entreprise - peut être transposé en nom de principal

   Lorsqu'un nom n'implique pas d'informations autres que son unicité à un moment particulier, le type de nom PRINCIPAL devrait être utilisé pour les utilisateurs, et il peut aussi être utilisé pour un serveur unique. Si le nom est un ID unique généré par la machine qu'il est garanti n'être jamais ré-alloué, le type de nom d'UID devrait alors être utilisé.

   Si le premier composant d'un nom identifie un service et si des composants restants identifient une instance du service d'un manière spécifiée par le serveur, le type de nom de SRV-INST devrait alors être utilisé. Un exemple de ce type de nom est le TGS dont le nom a un premier composant de krbtgt et un second composant identifiant le domaine pour lequel le ticket est valide.

   Si le premier composant d'un nom identifie un service et qu'il y a un seul composant suivant le nom de service qui identifie l'instance comme l'hôte sur lequel fonctionne le serveur, le type de nom SRV-HST devrait être utilisé. Ce type est normalement utilisé pour les services Internet tels que telnet et les commandes R de Berkeley. Si les composants séparés du nom de l'hôte apparaissent comme des composants successifs qui suivent le nom du service, le type de nom SRV-XHST devrait être utilisé. Ce type peut être utilisé pour identifier les serveurs sur des hôtes qui ont des noms X.500, et où "/" pourrait être ambiguë.

   Un type de nom NT-X500-PRINCIPAL devrait être utilisé lorsqu'un nom provenant d'un certificat X.509 est traduit en un nom Kerberos. Le codage du nom X.509 comme un principal de Kerberos doit être conforme aux règles de codage spécifiées dans la rfc2253.

   Un type de nom de SMTP permet à un nom d'être d'un forme qui ressemble à un nom de messagerie électronique SMTP. Ce nom, comportant un @ et un nom de domaine, est utilisé comme premier composant du nom de principal.

   Un type de nom de UNKNOWN devrait être utilisé lorsque la forme du nom n'est pas connue. Lors d'une comparaison des nom, un type de nom UNKNOWN correspondra aux principaux authentifiés avec des noms de tout type. Un principal authentifié avec un type de nom de UNKNOWN ne correspondra cependant qu'à d'autres noms de type UNKNOWN.

   Les noms de tout type avec un composant initial de krbtgt sont réservés pour le TGS.

Nom des principaux de serveur

L'identifiant de principal pour un serveur sur un hôte sera généralement composé de 2 parties: Le domaine du KDC avec lequel le serveur est enregistré, et un nom à 2 composants NT-SRV-HST, si le nom d'hôte est un nom de domaine Internet, ou un nom multi-composants de type NT-SRV-XHST, si le nom de l'hôte est d'une forme qui permet "/" comme séparateurs. Le premier composant du nom à deux ou plusieurs composants va identifier le service, et les derniers composants vont identifier l'hôte. Lorsque le nom de l'hôte n'est pas sensible à la casse, le nom de l'hôte doit être en minuscule. Si c'est spécifié par le protocole d'application pour des services tels que telnet et les commandes R de Berkeley qui fonctionnent avec des privilèges de système, le premier composant peut être la chaîne host au lieu d'un identifiant spécifique du service.

Types d'adresse d'hôte

   Toutes les valeurs négatives pour le type d'adresse d'hôte sont réservées à une utilisation locale. Toutes les valeurs non négatives sont réservées aux champs et interprétations de type officiellement alloués.

Adresses Internet (IPv4) Les adresses Internet sont des quantités de 32bits codées dans l'ordre MSB. Une adresse IPv4 de bouclage ne devrait pas apparaître dans un PDU Kerberos. Le type des adresses IPv4 est (2)
Adresses Internet (IPv6) Les adresses IPv6 sont des guantités de 128bits codées danfs l'ordre MSB. Le type des adresses IPv6 est (24). Les adresses suivantes ne doivent pas apparaître dans un PDU Kerberos: l'adresse non spécifiée, la loopback, les adresses de lien locaux.

   Ces restrictions s'appliquent à l'inclusion dans les champs d'adresse des PDU, mais pas aux champs d'adresse des paquets qui pourraient porter ces PDU. La restriction est nécessaire parce que l'utilisation d'une adresse d'une portée non mondial pourrait permettre l'acceptation d'un message envoyé à partir d'un nœud qui pourrait avoir la même adresse, mais qui ne serait par l'hôte prévu. Si le type d'adresse local doit être utilisé pour une communication, la restriction d'adresse dans les tickets ne doit pas être utilisée. Les adresses IPv6 transposées en IPv4 doivent être représentées comme adresses de type 2.

Adresses DECnet de Phase IV Les adresses DECnet de Phase IV sont des adresses de 16 bits, codées dans l'ordre LSB. Le type des adresses DECnet de Phase IV est (12).
Adresses Netbios Les adresses Netbios sont des adresses de 16 octets normalement composées de caractères alphanumériques de 1 à 15 et complétées avec le caractère US-ASCII SPC (code 32). Le 16ème octet DOIT être le caractère US-ASCII NUL (code 0). Le type des adresses Netbios est (20)

Adresses directionnelles Inclure l'adresse de l'émetteur dans les messages KRB_SAFE et KRB_PRIV n'est pas souhaitable dans de nombreux environnements parce que les adresses peuvent être changées dans le transport par des traducteurs d'adresse réseau. Cependant, si ces adresses sont retirées les messages peuvent être soumis à une attaque par réflexion dans laquelle un message est répliqué en retour à son origine. Le type d'adresse directionnelle donne le moyen d'éviter les attaques des adresses dans le transport et en réflexion. Les adresses directionnelles sont codées comme des entiers non signés de 4 octets dans l'ordre des octets du réseau. Si le message est généré par la pratie qui envoie le message KRB_AP_REQ original, une adresse de 0 devrait être utilisé. Les applications qui impliquent plusieurs parties peuvent spécifier l'utilisation des autres adresses.

   Les adresses directionnelles doivent être utilisées uniquement pour le champ d'adresse d'envoyeur dans les messages KRB_SAFE ou KRB_PRIV. Elles no doivent pas être utilisées comme adresse de ticket ou dans un message KRB_AP_REQ. Ce type d'adresse devrait être utilisé seulement dans des situations où la partie qui envoie sait que la partie qui reçoit prend en charge le type d'adresse. Cela signifie généralement que les adresses directionnelles ne peuvent être utilisée que quand le protocoles d'application exige leur prise en charge. Les adresses directionnelles dont du type (3)

Échange de messages KDC: transports IP

Kerberos définis 2 mécanismes de transport IP pour communiquer entre clients et serveurs: UDP/IP et TCP/IP.

UDP/IP

   Les KDC qui prennent en charge les transport IP doivent accepter les demandes UDP et devraient les écouter sur le port 88. Des accès de remplacement peuvent être utilisés quand plusieurs KDC fonctionnent sur plusieurs domaines sur le même hôte.

   Les clients Kerberos qui prennent en charge les transports IP devraient prendre en charge l'envoi des demandes UDP. Les client devraient utiliser la découverte de KDC pour identifier l'adresse et le port IP auquel ils veulent envoyer leur demande.

   Lorsqu'il contacte un KDC pour un KRB_KDC_REQ en utilisant UDP, le client doit envoyer un UDP ne contenant qu'un codage de la demande au KDC. Le KDC répondra avec un datagramme contenant seulement un encodage de la réponse (soi un KRB_ERROR, soit un KRB_KDC_REP) à l'adresse IP de l'envoyeur. La réponse à une demande faite au moyen d'un transport UDP/IP doit aussi utiliser le transport UDP. Si la réponse ne peut être traitée en utilisant UDP (par exemple, parce qu'elle est trop grande), le KDC doit retourner KRB_ERR_RESPONSE_TOO_BIG, forçant le client à réessayer la demande en utilisant le transport TCP.

TCP/IP

   Les KDC qui prennent en charge les transports IP doivent accepter les demandes TCP et devraient les écouter sur le port 88. Les clients doivent prendre en charge l'envoi des demandes TCP, mais peuvent choisir d'essayer une demande en utilisant initialement le transport UDP. Les clients devraient utiliser la découverte de KDC pour identifier l'adresse et le port IP auquel ils enverront leur demande.

   Lorsque le message KRB_KDC_REQ est envoyé au KDC sur un flux TCP, la réponse doit être retournées au client sur le même flux TCP qui était établis pour le demandes. Le KDC peut fermer le flux TCP après avoir envoyé une réponse, mais peut laisser le flux ouvert pendant une durées raisonnable s'il attend une suite. Il faut veiller, dans la gestion des connexions TCP avec le KDC, à empêcher les attaques DOS fondées sur le nombre de connexions TCP ouvertes.

   Le client doit être prêt à voir le flux fermé par le KDC à tout moment après la réception d'une réponse. Une clôture de flux ne devrait pas être traitée comme une erreur fatale. Plutôt, si plusieurs échanges sont exigés (par exemple, par certaines formes de pré-authentification), le client peut avoir besoin d'établir une nouvelle connexion quand il est prêt à envoyer les messages suivants. Un client peut clore le flux après réception d'une réponse, et devrait clore le flux s'il ne prévoit pas d'envoyer de messages de suite.

   Un client peut envoyer plusieurs demandes avant de recevoir des réponses, bien qu'il doive être prêt à traiter la fermeture de la connexion après la première réponse.

   Chaque demande (KRB_KDC_REQ) et réponse (KRB_KDC_REP ou KRB_ERROR) envoyée sur le flux TCP est précédée par la longueur de la demande en 4 octets dans l'ordre des octets du réseau. Le MSB de la longueur est réservé à une expansion future et doit actuellement être mis à zéro. Si un KDC qui ne comprend pas comment interpréter un MSB mis dans le codage de longueur, reçoit une demande avec le MSB mis, il doit retourner un message KRB-ERROR avec l'erreur KRB_ERR_FIELD_TOOLONG et doit clore le flux TCP.

Découverte de KDC sur les réseaux IP

Les implémentations de client Kerberos doivent fournir un moyen pour que le client détermine la localisation des KDC. Traditionnellement, les implémentations Kerberos mémorisent de telles informations de configuration dans un fichier sur chaque machine cliente. L'expérience a montré que cette méthode de mémorisation des informations de configuration pose des problèmes d'informations périmées et d'évaluation, tout particulièrement lors de l'utilisation de l'authentification inter-domaine.

DNS

Dans Kerberos, les noms de domaine sont sensibles à la casse. Bien qu'il soit fortement recommandé que tous les noms de domaine soient en majuscule, cette recommandation n'a pas été adoptée par tous les sites. Certains sites utilisent des noms tout en minuscules et d'autres utilisent une casse mélangée. DNS, d'un autre côté, est insensible à la casse pour les interrogations.

Spécification de localisation de KDC avec DNS SRV

   Les informations de localisation de KDC sont à mémoriser en utilisant les DNS RR SRV . Le format de ce RR est le suivant:

  _Service._Proto.Realm TTL Class SRV Priority Weight Port Target

  Le proto peut être udp ou tcp. Si ces enregistrements de SRV doivent être utilisé, les enregistrements upd et tcp doivent tous 2 être spécifiés pour tous les développements de KDC. Le Realm est de domaine Kerberos auquel cet enregistrement correspond. Le domaine doit être un nom de domaine de style domaine. TTL, Class, SRV, Priority, Weight et Target ont la signification standar définis dans la rfc2782.

   Conformément à cette rfc, le numéro de port utilisé pour les enregistrement de SRV "_udp" et "_tcp" devraient être la valeur allouée à "kerberos" par l'IANA: 88, sauf si le KDC est configuré pour écouter sur un autre accès TCP.

Découverte de KDC pour les Realms name stype domaine

Ce sont des enregistrement DNS pour un domaine Kerberos EXAMPLE.COM. Il y a 2 serveurs Kerberos kdc1.example.com et kdc2.example.con. Les requêtes devraient d'abord être dirigées sur kdc1.example.com conformément à la priorité spécifée. Les pondérations ne sont pas utilisées dans cet échantillons d'enregistrements.

_kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.

Nom du TGS

L'identifiant de principal du TGS doit être composé de 3 parties: le domaine du KDC qui produit les tickets TGS, et un nom en 2 parties du type NT-SRV-INST, dont la première partie est "krbtgt" et la seconde partie est le nom du domaine qui va accepter le TGT. Par exemple, un TGT produit par le domaine ATHENA.MIT.EDU utilisé pour des tickets du KDC ATHENA.MIT.EDU a un identifiant de principal de "ATHENA.MIT.EDU" (domaine), ("krbtgt", "ATHENA.MIT.EDU") (nom). Un TGT produit par le domaine ATHENA.MIT.EDU utilisé pour obtenir des tickets du domaine MIT.EDU a l'identifiant de principal "ATHENA.MIT.EDU" (domaine), ("krbtgt", "MIT.EDU") (nom).

OID pour Kerberosv5

Cet OID peut être utilisé pour identifier les messages de protocoles Kerberos encapsulés dans d'autres protocoles:
id-krb5 OBJECT IDENTIFIER ::= {
iso(1) identified-organisation(3) dod(6) internet(1) security(5) kerberosV5(2)
}

Constantes du protocole et valeurs associées

Les tableaux qui suivent font la liste des constantes utilisées dans le protocole et définissent leur signification. Dans la partie "spécification" sont spécifiés les gammes qui limitent les valeurs des constantes pour lesquelles les valeurs sont définies ici.

Valeurs d'utilisation de clé

La spécification du chiffrement et de checksum exige en entrée un numéro d'utilisation de clé, pour altérer la clé de chiffrement utilisée dans tout message spécifique afin de rendre plus difficiles certains types d'attaques.

1. timestamp padata AS-REQ PA-ENC-TIMESTAMP, chiffré avec la clé de client
2. Tickets AS-REP et TGS-REP (inclut la clé de session TGS ou la clé de session d'application), chiffrés avec la clé de service
3. Partie chiffrée de AS-REP (inclut la clé de session TGS ou la clé de session d'application), chiffrée avec la clé de client
4. Données d'autorisation TGS-REQ KDC-REQ-BODY, chiffrées avec la clé de session TGS
5. Données d'autorisation TGS-REQ KDC-REQ-BODY, chiffrées avec la sous-clé d'authentifiant TGS
6. Somme de contrôle d'authentifiant AP-REQ de padata TGS-REQ PA-TGS-REQ, frappée avec la clé de session TGS
7. Authentifiant AP-REQ de padata TGS-REQ PA-TGS-REQ (inclut la sous-clé d'authentifiant de TGS), chiffré avec la clé de session TGS
8. Partie chiffrée de TGS-REP (inclut la clé de session d'application), chiffrée avec la clé de session TGS
9. Partie chiffrée de TGS-REP (inclut la clé de session d'application), chiffrée avec la sous-clé d'authentifiant de TGS
10. Somme de contrôle d'authentifiant AP-REQ, frappée avec la clé de session d'application
11. Authentifiant AP-REQ (inclut la sous-clé d'authentifiant d'application), chiffré avec la clé de session d'application
12. Partie chiffrée de AP-REP (inclut la sous-clé de session d'application), chiffré avec la clé de session d'application
13. Partie chiffrée de KRB-PRIV, chiffrée avec une clé choisie par l'application
14. Partie chiffrée de KRB-CRED, chiffrée avec une clé choisie par l'application
15. Somme de contrôle KRB-SAFE, frappé avec une clé choisie par l'application
16-18. Réservés à une utilisation future dans Kerberos et les protocoles qui s'y rapportent.
19. Somme de contrôle AD-KDC-ISSUED (ad-checksum)
20-21. Réservés à une utilisation future dans Kerberos et les protocoles qui s'y rapportent.
22-25. Réservés à une utilisation future dans les mécanismes GSS-API de Kerberos Version 5 [RFC4121].
26-511. Réservés à une utilisation future dans Kerberos et les protocoles qui s'y rapportent.
512-1023. Réservés à des utilisations internes à une mise en œuvre Kerberos.
1024. Chiffrement à usage d'application dans les protocoles qui ne spécifient pas de valeurs d'usage de clés.
1025. Sommes de contrôle à usage d'application dans les protocoles qui ne spécifient pas de valeurs d'usage de clés
1026-2047. Réservé à l'usage d'application.

Types de données de pré-authentification

Padata et type de données (Padata-type) Commentaire
PA-TGS-REQ (1)
PA-ENC-TIMESTAMP (2)
PA-PW-SALT (3)
[reserved] (4)
PA-ENC-UNIX-TIME (5) déconseillé
PA-SANDIA-SECUREID (6)
PA-SESAME (7)
PA-OSF-DCE (8)
PA-CYBERSAFE-SECUREID (9)
PA-AFS3-SALT (10)
PA-ETYPE-INFO (11)
PA-SAM-CHALLENGE (12) sam/otp
PA-SAM-RESPONSE (13) sam/otp
PA-PK-AS-REQ_OLD (14) pkinit
PA-PK-AS-REP_OLD (15) pkinit
PA-PK-AS-REQ (16) pkinit
PA-PK-AS-REP (17) pkinit
PA-ETYPE-INFO2 (19) remplace pa-etype-info
PA-USE-SPECIFIED-KVNO (20)
PA-SAM-REDIRECT (21) sam/otp
PA-GET-FROM-TYPED-DATA (22) incorporé dans typed-data
TD-PADATA (22) incorpore padata
PA-SAM-ETYPE-INFO (23) sam/otp
PA-ALT-PRINC (24) crawdad@fnal.gov
PA-SAM-CHALLENGE2 (30) kenh@pobox.com
PA-SAM-RESPONSE2 (31) kenh@pobox.com
PA-EXTRA-TGT (41) Réservé extra TGT
TD-PKINIT-CMS-CERTIFICATES (101) CertificateSet du CMS
TD-KRB-PRINCIPAL (102) PrincipalName
TD-KRB-REALM (103) Domaine
TD-TRUSTED-CERTIFIERS (104 de PKINIT
TD-CERTIFICATE-INDEX (105) de PKINIT
TD-APP-DEFINED-ERROR (106) spécifique de l'application
TD-REQ-NONCE (107) ENTIER
TD-REQ-SEQ (108) ENTIER
PA-PAC-REQUEST (128) jbrezak@exchange.microsoft.com

Types d'adresse

IPv4 2
Directionnelle 3
ChaosNet 5
XNS 6
ISO 7
DECNET Phase IV 12
AppleTalk DDP 16
NetBios 20
IPv6 24

Types de données d'autorisation

Types de données d'autorisation Valeur de Ad-type
AD-IF-RELEVANT 1
AD-INTENDED-FOR-SERVER 2
AD-INTENDED-FOR-APPLICATION-CLASS 3
AD-KDC-ISSUED 4
AD-AND-OR 5
AD-MANDATORY-TICKET-EXTENSIONS 6
AD-IN-TICKET-EXTENSIONS 7
AD-MANDATORY-FOR-KDC 8
Valeurs réservées 9-63
OSF-DCE 64
SESAME 65
AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com)
AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com)
AD-ETYPE-NEGOTIATION 129 (lzhu@windows.microsoft.com)

Types de codages de transit

Type de codage traversé Valeur de Tr-type
DOMAIN-X500-COMPRESS 1
Valeurs réservées Toutes les autres

Numéro de version du protocole

pvno (5) Numéro de version en cours du protocole Kerberos

Types de message Kerberos

KRB_AS_REQ (10) Demande d'authentification initiale
KRB_AS_REP (11) Réponse à demande KRB_AS_REQ
KRB_TGS_REQ (12) Demande d'authentification fondée sur un TGT
KRB_TGS_REP (13) Réponse à demande KRB_TGS_REQ
KRB_AP_REQ (14) Demande d'application au serveur
KRB_AP_REP (15) Réponse à KRB_AP_REQ_MUTUAL
KRB_RESERVED16 (16) Réservé à une demande krb_tgt_request d'usager à usager
KRB_RESERVED17 (17) Réservé à une réponse krb_tgt_reply d'usager à usager
KRB_SAFE (20) Message d'application sûr (avec somme de contrôle)
KRB_PRIV (21) Message d'application privé (chiffré)
KRB_CRED (22) Message privé (chiffré) pour transmission d'accréditifs
KRB_ERROR (30) Réponse d'erreur

Types de noms

KRB_NT_UNKNOWN (0) Type de nom inconnu
KRB_NT_PRINCIPAL (1) Juste le nom du principal comme dans DCE, ou pour utilisateurs
KRB_NT_SRV_INST (2) Service et autre instance unique (krbtgt)
KRB_NT_SRV_HST (3) Service avec nom d'hôte comme instance (telnet, rcommands)
KRB_NT_SRV_XHST (4) Service avec hôte comme composants restants
KRB_NT_UID (5) ID unique
KRB_NT_X500_PRINCIPAL (6) Nom distinctif X.509 codé [RFC2253]
KRB_NT_SMTP_NAME (7) Nom en forme de nom de messagerie électronique SMTP (par exemple, user@example.com)
KRB_NT_ENTERPRISE (10) Nom d'entreprise; peut être transposé en nom de principal

Codes d'erreur

KDC_ERR_NONE (0) Pas d'erreur
KDC_ERR_NAME_EXP (1) L'entrée du client dans la base de données a expiré
KDC_ERR_SERVICE_EXP (2) L'entrée du serveur dans la base de données a expiré
KDC_ERR_BAD_PVNO (3) Numéro de version du protocole demandé non accepté
KDC_ERR_C_OLD_MAST_KVNO (4) La clé du client est chiffrée avec la vieille clé maîtresse
KDC_ERR_S_OLD_MAST_KVNO (5) La clé du serveur est chiffrée avec la vieille clé maîtresse
KDC_ERR_C_PRINCIPAL_UNKNOWN (6) Client non trouvé dans la base de données Kerberos
KDC_ERR_S_PRINCIPAL_UNKNOWN (7) Serveur non trouvé dans la base de données Kerberos
KDC_ERR_PRINCIPAL_NOT_UNIQUE (8) Plusieurs entrées du principal dans la de données
KDC_ERR_NULL_KEY (9) Le client ou le serveur a une clé nulle
KDC_ERR_CANNOT_POSTDATE (10) Ticket non éligible au postdatage
KDC_ERR_NEVER_VALID (11) Heure de début demandée postérieure à l'heure de fin
KDC_ERR_POLICY (12) La politique du KDC rejette la demande
KDC_ERR_BADOPTION (13) Le KDC ne peut pas traiter l'option demandée
KDC_ERR_ETYPE_NOSUPP (14) Le KDC ne prend pas en charge le type de chiffrement
KDC_ERR_SUMTYPE_NOSUPP (15) Le KDC n'accepte pas le type de somme de contrôle
KDC_ERR_PADATA_TYPE_NOSUPP (16) Le KDC ne prend pas en charge le type de padata
KDC_ERR_TRTYPE_NOSUPP (17) Le KDC ne prend pas en charge le type transité
KDC_ERR_CLIENT_REVOKED (18) Les accréditifs du client ont été révoqués
KDC_ERR_SERVICE_REVOKED (19) Les accréditifs du serveur ont été révoqués
KDC_ERR_TGT_REVOKED (20) Le TGT a été révoqué
KDC_ERR_CLIENT_NOTYET (21) Client pas encore valide ; réessayer plus tard
KDC_ERR_SERVICE_NOTYET (22) Serveur pas encore valide ; réessayer plus tard
KDC_ERR_KEY_EXPIRED (23) Mot de passe expiré ; changer le mot de passe pour recommencer
KDC_ERR_PREAUTH_FAILED (24) Informations de pré-authentification invalides
KDC_ERR_PREAUTH_REQUIRED (25) Pré-authentification supplémentaire exigée
KDC_ERR_SERVER_NOMATCH (26) Le serveur demandé et le ticket ne correspondent pas
KDC_ERR_DOIIVENT_USE_USER2USER (27) Principal de serveur valide seulement d'usager à usager
KDC_ERR_PATH_NOT_ACCEPTED (28) La politique du KDC rejette le chemin de transit
KDC_ERR_SVC_UNAVAILABLE (29) Un service n'est pas disponible
KRB_AP_ERR_BAD_INTEGRITY (31) Échec de vérification d'intégrité sur le champ déchiffré
KRB_AP_ERR_TKT_EXPIRED (32) Ticket expiré
KRB_AP_ERR_TKT_NYV (33) Ticket pas encore valide
KRB_AP_ERR_REPEAT (34) La demande est une répétition
KRB_AP_ERR_NOT_US (35) Le ticket n'est pas pour nous
KRB_AP_ERR_BADMATCH (36) Ticket et authentifiant ne correspondent pas
KRB_AP_ERR_SKEW (37) Biais d'horloge trop grand
KRB_AP_ERR_BADADDR (38) Adresse réseau incorrecte
KRB_AP_ERR_BADVERSION (39) Discordance de version de protocole
KRB_AP_ERR_MSG_TYPE (40) Type de message invalide
KRB_AP_ERR_MODIFIED (41) Flux de message modifié
KRB_AP_ERR_BADORDER (42) Message pas à son ordre
KRB_AP_ERR_BADKEYVER (44) Version de clé spécifiée non disponible
KRB_AP_ERR_NOKEY (45) Clé de service non disponible
KRB_AP_ERR_MUT_FAIL (46) Échec d'authentification mutuelle
KRB_AP_ERR_BADDIRECTION (47) Direction de message incorrecte
KRB_AP_ERR_METHOD (48) Autre méthode d'authentification exigée
KRB_AP_ERR_BADSEQ (49) Numéro de séquence incorrect dans le message
KRB_AP_ERR_INAPP_CKSUM (50) Type de somme de contrôle inapproprié dans le message
KRB_AP_PATH_NOT_ACCEPTED (51) La politique rejette le chemin de transit
KRB_ERR_RESPONSE_TOO_BIG (52) Réponse trop grosse pour UDP ; ressayer avec TCP
KRB_ERR_GENERIC (60) Erreur générique (description dans e-text)
KRB_ERR_FIELD_TOOLONG (61) Le champ est trop long pour cette mise en œuvre
KDC_ERROR_CLIENT_NOT_TRUSTED (62) Réservé pour PKINIT
KDC_ERROR_KDC_NOT_TRUSTED (63) Réservé pour PKINIT
KDC_ERROR_INVALID_SIG (64) Réservé pour PKINIT
KDC_ERR_KEY_TOO_WEAK (65) Réservé pour PKINIT
KDC_ERR_CERTIFICATE_MISMATCH (66) Réservé pour PKINIT
KRB_AP_ERR_NO_TGT (67) Pas de TGT disponible pour valider USER-TO-USER
KDC_ERR_WRONG_REALM (68) Réservé pour utilisation future
KRB_AP_ERR_USER_TO_USER_REQUIRED (69) Le ticket doit être pour USER-TO-USER
KDC_ERR_CANT_VERIFY_CERTIFICATE (70) Réservé pour PKINIT
KDC_ERR_INVALID_CERTIFICATE (71) Réservé pour PKINIT
KDC_ERR_REVOKED_CERTIFICATE (72) Réservé pour PKINIT
KDC_ERR_REVOCATION_STATUS_UNKNOWN (73) Réservé pour PKINIT
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE (74) Réservé pour PKINIT
KDC_ERR_CLIENT_NAME_MISMATCH (75) Réservé pour PKINIT
KDC_ERR_KDC_NAME_MISMATCH (76) Réservé pour PKINIT

Exigences d'intéropérabilité

La version 5 du protocole Kerberos accepte une myriade d'options. Parmi celles-ci, plusieurs types de chiffrement et de sommes de contrôle; des schéma de codage de remplacement pour le champ de transit; des mécanismes facultatifs pour la pré-authentification; le traitement de tickets sans adresse; des options pour l'authentification mutuelle; l'authentification d'utilisateur à utilisateur; la prise en change de proxy; le format des noms de domaines; le traitement des données d'autorisation; et la transmission, le post-datage, et le renouvellement de tickets.

Afin d'assurer l'intéropérabilité des domaines, il est nécessaire de définir une configuration minimale qui doit être prise en charge par toutes les mises en œuvre. Cette configuration minimale est sujette à changement ultérieurs.

Spécification 2

   Ce paragraphe définit la seconde spécification des options. Les implémentations qui sont configurées de cette façon peuvent être considérées comme prenant en charge la spécification 2 de Kerberos v5 (5.2).

Transport Le transport TCP/IP et UDP/IP doivent être pris en charge par les clients et KDC qui revendiquent la conformité à
la spécification 2. Méthodes de chiffrement et de somme de contrôle
Les mécanismes de chiffrement et de somme de contrôle suivants doivent être pris en charge:
Chiffrement: AES256-CTS-HMAC-SHA1-96 [RFC3962]
Somme de contrôle: HMAC-SHA1-96-AES256 [RFC3962]

   Les mises en œuvre devraient aussi accepter d'autres mécanismes, mais les mécanismes supplémentaires ne peuvent être utilisés qu'en communicant avec des principaux connus pour les accepter aussi. Les mécanismes suivants provenant de la [RFC3961] et de la [RFC3962] devraient être pris en charge:

Chiffrement: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD
Somme de contrôle: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128

   Les implémentations peuvent aussi accepter d'autres mécanismes, mais les mécanismes supplémentaires ne peuvent être utilisés qu'en communication avec des principaux connus pour les accepter aussi.

Noms de domaine Toutes les mises en œuvre doivent comprendre la hiérarchie des domaines à la fois dans le domaine Internet et dans le style X.500. Lorsque est demandé un TGT pour un domaine inconnu, le KDC doit être capable de déterminer les noms des domaines intermédiaires entre le domaine du KDC et le domaine demandé.
Codage de champ de transit DOMAIN-X500-COMPRESS doit être pris en charge. D'autres codages peuvent être acceptés, mais ils ne peuvent être utilisés lorsque ce codage est accepté par tous les domaines intermédiaires.
Méthodes de pré-authentification La méthode TGS-REQ doit être prise en charge. Elle n'est pas utilisée sur la demande initiale. La méthode PA-ENC-TIMESTAMP doit être acceptée par les clients, mais savoir si elle est activée par défaut peut être déterminé domaine par domaine. Si la méthode n'est pas utilisée dans la demande initiale et si l'erreur KDC_ERR_PREAUTH_REQUIRED est retournée, spécifiant PA-ENC-TIMESTAMP comme méthode acceptable, le client devrait ressayer la demande initiale en utilisant la méthode de pré-authentification PA-ENC-TIMESTAMP. Les serveurs n'ont pas besoin de prendre en charge la méthode PA-ENC-TIMESTAMP, mais si elle n'est pas acceptée, le serveur devrait ignorer la présence de la pré-authentification PA-ENC-TIMESTAMP dans une demande.
La méthode ETYPE-INFO2 doit être acceptée; cette méthode est utilisée pour communiquer l’ensemble des types de chiffrement acceptés, et les paramètres correspondants de salt et de string-to-key. La méthode ETYPE-INFO devrait être acceptée pour l’interopérabilité avec les mises en œuvre les plus anciennes.
Authentification mutuelle L’authentification mutuelle (via le message KRB_AP_REP) doit être acceptée.
Adresses et flags de ticket Tous les KDC doivent passer les tickets qui ne portent pas d’adresse (c’est-à-dire que si un TGT ne contient pas d’adresse, le KDC retournera des tickets dérivés). Les mises en œuvre devraient par défaut demander des tickets sans adresse, car cela augmente de façon significative l’interopérabilité avec la traduction d’adresse réseau. Dans certains cas, les domaines ou les serveurs d’application peuvent exiger que les tickets aient une adresse.

   Les mises en œuvre devraient accepter le type d’adresse directionnelle pour les messages KRB_SAFE et KRB_PRIV et devraient inclure des adresses directionnelles dans ces messages quand d’autres types d’adresse ne sont pas disponibles. Les tickets mandataires et transmis doivent être acceptés. Les domaines et serveurs d’application individuels peuvent y régler leur propre politique lorsque de tels tickets seront acceptés. Toutes les implémentations doivent reconnaître les tickets renouvelables et postdatés, mais ils n’ont pas besoin de les mettre réellement en œuvre. Si ces options ne sont pas prises en charge, l’heure de début et l’heure de fin dans le ticket devront spécifier l’entière durée de vie utile d’un ticket. Lorsque un ticket postdaté est décodé par un serveur, toutes les mises en œuvre devront rendre visible la présence du flag postdaté pour le serveur appelant

Authentification d’usager à usager La prise en charge de l’authentification d’usager à usager (via l’option ENC-TKT-IN-SKEY KDC) doit être fournie par les mises en œuvre, mais les domaines individuels peuvent décider au titre de leur politique de rejeter de telles demandes principal par principal ou domaine par domaine.
Données d’autorisation Les mises en œuvre doivent passer tous les sous-champs de données d’autorisation des TGT à tout ticket dérivé sauf si ils sont amenés à supprimer un sous-champ au titre de la définition de ce type de sous-champ enregistré. (Il n’est jamais incorrect de passer sur un sous-champ, et actuellement, aucun type de sous-champ enregistré ne spécifie la suppression au KDC.)
Les mises en œuvre doivent rendre disponible le contenu de tout sous-champ de données d’autorisation au serveur lorsque le ticket est utilisé. Les mises en œuvre ne sont pas obligées de permettre aux clients de spécifier le contenu des champs de données d’autorisation.
Gammes de constantes Toutes les constantes du protocole sont contraintes à des valeurs de 32 bits (signés) sauf contraintes supplémentaires provenant de la définition du protocole. Cette limite est donnée pour permettre aux mises en œuvre de faire des hypothèses sur les valeurs maximales qui seront reçues pour ces constantes. Les mises en œuvre recevant des valeurs hors de ces gammes peuvent rejeter la demande, mais elles doivent se récupérer proprement.

Valeurs de KDC recommandées

Durée de vie minimum 5 minutes
Durée de vie maximum renouvelable 1 semaine
Durée de vie maximum de ticket 1 jour
Biais d’horloge admissible 5 minutes
Adresses vides Admis
proxiable, etc. Admis

01 septembre 2013

rfc4422

Simple Authentication and Security Layer (SASL)

SASL est un framework fournissant des services d'authentification et de sécurité de données dans des protocoles orienté connexion utilisant des mécanismes remplaçable. SASL fournis une interface structurée entre les protocoles et les mécanismes. SASL fournis également un protocole pour sécuriser les échanges. SASL est conçu pour permettre à de nouveaux protocoles de réutiliser les mécanismes existants.

SASL fournis une couche d'abstraction entre les protocoles et les mécanismes. Pour utiliser SASL, chaque protocole fournis une méthode pour identifier le mécanisme à utiliser, une méthode pour échanger les challenges et une méthode pour la communication. Chaque mécanisme SASL définis une série de server-challenge et client-response qui fournissent les services d'authentification et de négociation de sécurisation des données.

Concept d'identité

   SASL nécessite 2 identités:

1) L'identité associé avec les accréditifs ( authentication identity )
2) L'identité qui agis en tant que ( authorization identity )

   Le client fournis ses accréditifs ( qui inclus ou implique un authentication identity) et optionnellement, une chaîne de caractère représentant l'authorization identity. Quand cette chaîne est omis ou vide, le client agis comme identité associé avec les accréditifs.

   Le serveur vérifie les accréditifs du clients et vérifie que l'identité qu'il associe avec les accréditifs du client (authorization idenity) a le droit d'agir comme authorization identity. Si une des vérifications échoue, l'échange SASL échoue.

Échange d'authentification

Chaque échange d'authentification consiste d'un message du client vers le serveur demandant une authentification via un mécanisme particulier, suivi par une ou plusieurs paires de challenges du serveur et de réponse du client, suivis par un message du serveur indiquant la sortie de l'échange d'authentification.

Exemple d'échange

C: Request authentication exchange
S: Initial challenge
C: Initial response
‹additional challenge/response messages›
S: Outcome of authentication exchange

Certains mécanismes spécifient que le client envoie une réponse initiale dans la requête. Plusieurs variantes sont possible.

Nommage des mécanismes

les mécanismes SASL sont nommés par des chaînes de caractère, de 1 à 20 caractère de long, en ASCII noté (ABNF) :
sasl-mech = 1*20mech-char
mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE

UPPER-ALPHA = %x41-5A ; A-Z (uppercase only)
DIGIT = %x30-39 ; 0-9
HYPHEN = %x2D ; hyphen (-)
UNDERSCORE = %x5F ; underscore (_)

Négociation de mécanisme

La négociation des mécanismes est spécifique au protocole. Généralement, un protocole spécifie que le serveur avertis le client des mécanismes disponibles et supportés. Le client choisira le meilleur protocole de cette liste qu'il supporte.

Demande d'échange d'authentification

L'échange d'authentification est initié par le client en demandant une authentification via le mécanisme qu'il spécifie. Le client envoie une message contenant le nom du mécanisme au serveur. Les particularité du message sont spécifiques au protocole. Noter que le nom du mécanisme n'est pas protégé par le mécanisme.

Challenges and Responses

Les challenges et réponse sont imbriqués dans des messages de protocole. Le mécanisme peut être:

- Authentifier le client auprès du serveur
- authentifier le serveur auprès du client
- Transférer une chaîne authorization identity
- Négocier une couche de sécurité
- Fournir d'autres services.

La négociation de couche de sécurité implique la négociation de services de sécurité à fournir dans la couche et comment ces services sont fournis. Après avoir reçu une requête d'authentification ou une réponse d'un client, le serveur peut fournir un challenge, annuler l'échange, ou indiquer la sortie de l'échange. Après avoir reçu un challenge, un mécanisme client peut fournir une réponse ou annuler l'échange.

Chaîne d'identité d'authorisation

Cette chaîne est une séquence de caractères unicode représentant l'identité qui qui agis en tant que. Si cette chaîne est absente, le demandeur agis en tant qu'identité que le serveur associe avec les accréditifs du client. Une chaîne non vide indique que le client souhaite agir en tant qu'identité représentée par la chaîne.

Annuler l'échange

Un client ou un serveur peut annuler l'échange.

Fin de l'authentification

La conclusion de l'échange, le serveur envoie un message spécifique au protocole, au client indiquant la sortie de l'échange. La sortie est un échec si:

- L'échange d'authentification a échoué pour une quelconque raison
- Les accréditifs du client n'ont pu être vérifiés
- Le serveur ne peut associer une identité avec les accréditifs du client
- L'authorization Identity fournie est mal formaté
- L'identité associé avec les accréditifs du client n'est pas autorisé à agir en tant qu'authorization identity
- La couche sécurité demandée (ou son absence) n'est pas disponible et n'est pas utilisable par le client et/ou le serveur

Le protocole peut inclure des données additionnelles dans le message.

Couches de sécurité

Les mécanismes SASL peuvent offrir une grande variété de services dans les couches de sécurité, incluant l'intégrité des données et la confidentialité des données. Si la couche de sécurité est négociée dans l'échange, la couche n'est installée par le serveur qu'après le message de sortie d'échange.

Authentification multiple

Sans être explicitement permis dans le protocole, seul un échange d'authentification réussis peut se produire dan une sessions. Quand plusieurs authentifications sont permis, en aucun cas il ne peut y avoir plusieurs couche de sécurité simultanés. Si une couche de sécurité est effective, et qu'une seconde négociation sélectionne une autre couche de sécurité, la seconde couche remplace la première.

Protocol requirements

Pour qu'un protocole offre des services SASL, ses spécifications doivent fournir les informations suivantes:

1) un nom de service, à sélectionner du registre de services pour la forme de nom de service basé sur l'hôte GSSAPI.
2) Détail des négociations de mécanisme que le protocole fournis.
3) Définition des messages nécessaires pour l'échange d'authentification
4) Décrire la syntaxe de chaîne d'authorization identity non-vide
5) Détailler les facilité que le protocole fournis qui permettent au client/serveur d'annuler un échange
6) Identifier précisément où les couches de sécurité nouvellement négociée prenent effet.
7) Si le protocole supporte d'autres couche de sécurité tel que TLS, la spécification doit décrire l'ordre dans lequel les couches de sécurité sont appliquées dans les données du protocole
8) indiquer si le protocole supporte l'authentification multiple

Mechanism requirement

Les spécification des mécanisme doivent fournir les informations suivantes:

1) le nom du mécanisme
2) Si le mécanisme est client-first ou server-first.
3) si le serveur doit fournir des données additionnelles en indiquant une sortie réussie
4) Si le mécanisme est capable de transférer l'authorization identity
5) Si le mécanisme offre une couche de sécurité
6) si la technologie cryptographique utilisée supporte l'intégrité des données

21 juillet 2014

rfc4556

PKINIT

   Ce document décrit des extensions au protocole Kerberos. Ces extensions fournissent une méthode pour intégrer le clé de chiffrement publique dans l'échange d'authentification initiale, en utilisant les clé asymétrique pour les algorithmes de chiffrement et/ou de signature dans les champs de donnée de pré-authentification.

   La pierre angulaire de Kerberos 5 sont le ticket et l'authenticator. Un ticket encapsule une clé symétrique ( la clé de session ) dans un enveloppe ( un message publique ) à destination d'un service spécifique. Le contenu de ce ticket est chiffré avec une clé secrète partagée entre le principale de service et le KDC. La partie chiffrée du ticket contient le nom du principal du client, et d'autre éléments. Un authenticator est un enregistrement qui est généré en utilisant la clé de session du ticket associé. La clé de session est connue du client qui demande le ticket. Le contenu de l'authenticator est chiffré avec cette clé de session et contient un timestamp et le nom du principal du client.

   Le protocole Kerberos 5 consiste des échanges de messages suivant, entre le client et le KDC, et le client et les services d'application:

- L'échange d'AS, où le client obtient un ticket initial, les TGT.
- L'échange TGT, où le client utilise sont TGT pour s'authentifier et demander des tickets de service.
- L'échange AP, où le client faite des demandes avec des messages consistant d'un ticket de service et d'un authenticator qui certifie que le client possède la clé de session du ticket. Le serveur peut optionnellement y répondre. Ces échange négocient généralement des clé de session symétriques.

Généralement, l'AS et le TGS sont intégrés dans un seul périphérique, appelé le KDC.
___________________+- - - - - - - +
________+- - - - -›|__KDC_________|
AS-REQ_/___+- - - -|______________|
______/___/________+- - - - - - - +
_____/___/__________^___________|
____/____|AS-REP___/____________|
___|_____|________/_TGS-REQ_____+_TGS-REP
___|_____|_______/_____________/
___|_____|______/_____________/
___|_____|_____/___+- - - - -+
___|_____|____/___/
___|_____|___/___/
___|_____|__/___/
___|_____v_/___v
__++- - -+- - - - +_____________+- - - - - - - - -+
__|__Client_______+- - - - - - ›|__Application____|
__|_______________|____AP-REQ___|__Server_________|
__|_______________|‹- - - - - - |_________________|
__+- - - - - - - -+____AP-REP___+- - - - - - - - -+

   Dans l'échange AS, la réponse du KDC contient la clé de session du ticket, avec d'autres éléments, qui est chiffré en utilisant une clé partagée entre le client et le KDC. La clé de réponse AS est généralement dérivée du mot de passe du client. Cependant, pour les personnes physiques, la force du protocole Kerberos est sujette à la force du mot de passe.

   L'utilisation d'une clé asymétrique sous la forme d'un certificat X.509 permet de faciliter l'authentification de l'origine des données et la préservation du secret. Un PKI fournis une gestion et des mécanismes de distribution des clés qui peuvent être utilisé pour établir une authentification et une communication sûre.

   L'avantage du TGT Kerberos est que le client expose sa clé à long-terme secrète seulement une fois. Le TGT est ses clé de session associés peuvent être utilisées pour d'autres demandes de ticket. Cela permet à toutes les autres authentification d'être indépendant de la méthode d'authentification initiale. En plus, l'utilisation de clé symétrique après l'authentification initial est préférable pour des raisons de performance.

Extensions

Cette section décris les extensions pour supporter le chiffrement à clé publique dans la requête initiale pour un ticket. Brièvement, cet document définis les extensions suivantes:

- Le client indique l'utilisation d'une authentification à clé publique en incluant un pré-authentifiant spécial dans la demande initiale. Ce pré-authentifiant contient la clé publique du client et une signature.
- Le KDC teste la demande du client avec sa stratégie d'authentification et les autorités de certification de confiance.
- Si le demande passe les tests de vérification, le KDC répond normalement, mais la réponse est chiffrée en utilisant soit:

- Un clé générée avec l'échange DH avec le client, signé avec la clé de signature du KDC; ou
- Un clé de chiffrement symétrique, signée avec la clé de signature du KDC est chiffrée en utilisant la clé publique du client.

- Le client valide la signature du KDC, obtient la clé de chiffrement, déchiffre la réponse, et traite la suite normalement.

Algorithmes requis

Toutes les implémentations PKINIT doivent supporter les algorithmes suivant:

- l'enctype de la réponse AS: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96
- L'algorithme de signature: sha-1WithRSAEncryption
- La méthode de livraison de la clé de la réponse AS: La méthode DH.

En plus, les implémentations de cette spécification doivent être capable de traiter l'extension EKU et le id-pkinit-san otherName de l'extention SAN dans les certificat X.509.

Algorithmes recommandés

Toutes les implémentations PKINIT devraient supporter les algorithmes suivant:

- La méthode de livraison de la clé de la réponse AS: voir la section Utiliser le chiffrement à clé publique

Pour les implémentations qui supporte le chiffrement à clé publique pour les méthodes de livraison de clé, Les algorithmes suivant doivent être supportés:

- Les algorithmes de transport de clé identifiés dans le champ keyEncryptionAlgorithm du type KeyTransRecipientInfo pour le chiffrement de clé temporaire dans le champ encryptedKey avec un clé publique: rsaEncryption.
- Les algorithmes de chiffrement de contenu identifiés dans le champ contentEncryptionAlgorithm du type EncryptedContentInfo pour le chiffrement de la clé de réponse AS avec la clé temporaire contenue dans le champ encryptedKey du type KeyTransRecipientInfo: des-ede3-cbc

Messages définis et types de chiffrement

PKINIT utilise les types de pré-auhentification suivants:
PA_PK_AS_REQ 16
PA_PK_AS_REP 17
PKINIT utilisé les types de données d'autorisation suivants:
AD_INITIAL_VERIFIED_CAS 9
PKINIT introduit les nouveaux codes d'erreurs suivants:
KDC_ERR_CLIENT_NOT_TRUSTED 62
KDC_ERR_INVALID_SIG 64
KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
KDC_ERR_CANT_VERIFY_CERTIFICATE 70
KDC_ERR_INVALID_CERTIFICATE 71
KDC_ERR_REVOKED_CERTIFICATE 72
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
KDC_ERR_CLIENT_NAME_MISMATCH 75
KDC_ERR_INCONSISTENT_KEY_PURPOSE 77
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED 78
KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED 79
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED 80
KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED 81
PKINIT utilise les type de données suivant pour les erreurs:
TD_TRUSTED_CERTIFIERS 104
TD_INVALID_CERTIFICATES 105
TD_DH_PARAMETERS 109

Type de chiffrement Kerberos pour CMS Algorithm Identifiers

   PKINIT définis les numéros de type de chiffrement Kerberos, qui peut être utilisé dans le champ etype du message AS-REQ pour indiquer au KDC l'acceptation du client les algorithmes correspondant ( incluant les algorithmes de transport de clé algorithmes de chiffrement de contenu, et algorithmes de signature ). Les type de chiffrement dans le champ etype sont dans l'ordre décroissant de préférence du client. La présent de chacun de ces types de chiffrement dans le champ etype est équivalent à la présence du l'OID l'algorithme correspondant la le champ supportedCMSTypes, et l'ordre de préférence dans le champ supportedCMSTypes a précédence sur l'ordre de préférence dans le champ etype.

Kerberos Encryption Type Name____Num____Corresponding Algorithm OID
=============================____===____===============================
id-dsa-with-sha1-CmsOID__________ 9_____id-dsa-with-sha1 [RFC3370]
md5WithRSAEncryption-CmsOID______10_____md5WithRSAEncryption [RFC3370]
sha-1WithRSAEncryption-CmsOID____11_____sha-1WithRSAEncryption [RFC3370]
rc2-cbc-EnvOID___________________12_____rc2-cbc [RFC3370]
rsaEncryption-EnvOID_____________13_____rsaEncryption [RFC3447][RFC3370]
id-RSAES-OAEP-EnvOID_____________14_____id-RSAES-OAEP [RFC3447][RFC3560]
des-ede3-cbc-EnvOID______________15_____des-ede3-cbc [RFC3370]

   Les numéros de type de chiffrement ci-dessus sont seulement utilisé pour indiquer le support des algorithmes correspondant dans PKINIT; ils ne correspondant pas aux types de chiffrement Kerberos actuels et ne doivent pas être utilisé dans le champ etype. L'assignation des numéros de type de chiffrement Kerberos pour indiquer le support pour les algorithmes CMS est déprécié, et les nouveaux numéros ne devraient pas être assignés dans ce but. À la place, le champ supportedCMSTypes devrait être utilisé pour identifier les algorithmes supportés par le client et l'ordre de préférence du client.

   Pour une intéropérabilité maximiale, cependant, les clients PKINIT désirant indiquer au KDC le support pour un ou plusieur algorithmes listés ci-dessus devraient inclure les numéros dans le champ etype de l'AS-REQ.

Syntaxe et utilisation de la pré-authentification PKINIT

Cette section définie la syntaxe et l'utilisation des champs de pré-authentification utilisés par PKINIT.

Génération d'une demande client

   La demande d'authentification initilale ( AS-REQ ) est envoyée avec un élément de pré-authentification, dont le padata-type est PA PK_AS_REQ et dont padata-value contient le DER du type PA-PK-AS-REQ.

PA-PK-AS-REQ ::= SEQUENCE {
    signedAuthPack    [0] IMPLICIT OCTET STRING
    trustedCertifiers [1] SEQUENCE OF ExternalPrincipalIdentifier OPTIONAL
    kdcPkId [2] IMPLICIT OCTET STRING OPTIONAL
    ...
}
DHNonce ::= OCTET STRING
ExternalPrincipalIdentifier ::= SEQUENCE {
    subjectName [0] IMPLICIT OCTET STRING OPTIONAL
    issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL
    subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL
    ...
}
AuthPack ::= SEQUENCE {
    pkAuthenticator [0] PKAuthenticator,
    clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL
    supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier OPTIONAL
    clientDHNonce [3] DHNonce OPTIONAL
    ...
}
PKAuthenticator ::= SEQUENCE {
    cusec [0] INTEGER (0..999999)
    ctime [1] KerberosTime
    nonce [2] INTEGER (0..4294967295)
    paChecksum [3] OCTET STRING OPTIONAL
    ...
}

signedAuthPack Contient un CMS type ContentInfo. Le champ contentType est id-signedData (1.2.840.113549.1.7.2), et le champ tontent est un SignedData. le Champ eContentType pour le type SignedData est id-pkinit-authData (1.3.6.1.5.2.3.1), et le champ eContent contient le DER du type AuthPack
trustedCertifiers Liste de CA, trusté par le client qui peuvent être utilisés pour certifier le KDC.
kdcPkId Contient un CMS type SignerIdentifier. Identifie, si présent, une clé publique d'un KDC particulier que le client a déjà.
subjectName Conient un nom de type PKIX. Identifie le sujet du certificat par le nom distinct du sujet.
issuerAndSerialNumber Contient un type CMS IssuerAndSerialNumber. Identifie un certificat du sujet.
subjectKeyIdentifier Identifie la clé publique du sujet par une ID de clé.
clientPublicValue Spécifie les paramètres de domaine DH et la valeur de clé publique du client.
supportedCMSTypes Liste d'algorithmes CMS qui identifie les algorithmes de transport de clé ou de signature supportés par le client, par ordre de préférence.
clientDHNonce Présent seulement si le client indique qu'il souhaite ré-utiliser les clés DH ou autoriser le KDC à le faire.
paChecksum Contient le checksum SHA1.

eContentType ce champ pour le type SignedData est id-pkinit-authData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) authData(1) }
eContent Ce champ pour le type SignedData contient le DER du type AuthPack
signerInfos Ce champ pour le type SignedData contient un simple signerInfo, qui contient la signature du type AuthPack.
AuthPack Cette structure contient un PKAuthenticator, les informations de clé publique client, les type de chiffrement CMS supportés et un DHNonce.

pkAuthenticator certifie au KDC que le client a une connaissance récente de la clé de signature qui authentifie le client.
clientPublicValue spécifie les paramètre de domaine DH et la valeur de clé publique du client. La valeur de clé publique SH est encodée en BIT STRING.
clientPublicValue est présent seulement si le client désire utilisé DH.
supportedCMSTypes spécifie la liste des ID d'algorithmes CMS qui sont supportés par le client et peut être utilisé pour identifier un algorithme de signature ou un algorithme de transport de clé dans le champ keyEncryptionAlgorithm de type KeyTransRecipientInfo, ou un algorithme de chiffrement de contenu dans le champ contentEncryptionAlgorithm de type EncryptedContentInfo.
clientDHNonce est décrit plus bas

ctime dans la structure PKAuthenticator contient l'heure courante dans l'hôte du client, et le champ cusec est la partie micro-secondes. Ils sont utilisé ensemble pour spécifier un timestamp suffisamment précis. le champ nonce est choisi au hasard. le champ paChechsum doit être présent et contient un checksum SHA1. Pour faciliter les migrations futures de l'utilisation de SHA1, le champ paChecksum est optionnel: quand la demande est étendue à la négociation d'algorithmes de hash, le nouveau client qui souhaite ne pas utiliser SHA1 va envoyer la demande sans ce champ. Le KDC ce conformant à cette spécification doivent retourner KRB-ERROR avec le code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. Cela permet à un nouveau client de retenter avec SHA1 si permis par la stratégie locale.
certificates de type SignedData, contient les certificats utilisés pour la construction du chemin de certification, pour que le KDC puisse vérifier la signature sur le type AuthPack. Cet certificats devraient être suffisants pour construire au moins chemin de certification depuis le certificat client. Le client doit être capable d'inclure un tel jeu de certificats s'il est configuré pour le faire. Le champ certificates ne doit pas contenir de certificat CA root.
clientPublicValue La valeur public Diffie-Hellman est inclues si le client veut utiliser la méthode DH. Les paramètres de domaine DH pour la clé public du client sont spécifiés dans le champ algorithm du type SubjectPublicKeyInfo, et la valeur de clé publique DH du client est mapppé à un ubjectPublicKey. En utilisant la méthode d'agrément de clé DH, les implémentations doivent supporter Oakley 1024-bits Modular Exponential (MODP) group 2 et OakleOakley 2048-bits Modular Exponential (MODP) group 14 et devraient supporter OakleOakley 4096-bits Modular Exponential (MODP) group 16.

   La structure ExternalPrincipalIdentifier est utilisée dans ce document pour identifier la clé publique du sujet. Cette structure est construite comme suit:

subjectName Contient un nom de type PKIX encodé en accord avec la rfc3280. Ce champ identifie le sujet du certificat par un nom de sujet distinct. Ce champ est requis quand il y a un distinguished subject name présent dans le certificat utilisé.
issuerAndSerialNumber Contient un type CMS encodé. Ce champ identifie un certificat du sujet. Il est requis pour TD-INVALID-CERTIFICATES et TD-TRUSTED-CERTIFIERS
subjectKeyIdentifier Identifie la clé publique du sujet par une key identifier. Quand un certificat X.509 est référencé, cette Key Identifier matche la valeur d'extention subjectKeyIdentifier. Quand d'autres fomats de certificat sont référencés, les documents qui spécifient le format de certificat et leur utilisation avec le CMS doivent inclurent les détails du match de key identifier au champ de certificat approprié.

   Le champ trustedCertifiers du type PA-PK-AS-REQ contient une liste de CA, trustés par le client, qui peut être utilisé pour certifier le KDC. Chaque ExternalPrincipalIdentifier identifie une CA ou un certificat CA. Le champ kdcPkId du type PA-PK-AS-REQ contient un type CMS SignerIdentifier encodé. Ce champ identifie, si présent, une clé publique d'un KDC particulier que le client possède.

Réception de la demande client

   Une fois reçu la demande du client, le KDC la valide. Le KDC vérifie la signature du client dans le champ signedAuthPack. Si, pendant la validation du certificat du client, le KDC ne peut pas construire un chemin de validation, il retourne un KRB-ERROR avec le code KDC_ERR_CANT_VERIFY_CERTIFICATE. Le e-data qui l'accompagne est un TYPED-DATA qui contient un élément dont data-type est TD_TRUSTED_CERTIFIERS, et contient le DER du type TD-TRUSTED-CERTIFIERS:

TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
    ExternalPrincipalIdentifier
    -- Identifies une liste de CA trustés par le KDC.
    -- Chaque ExternalPrincipalIdentifier identifies une CA
    -- ou un certificat CA

   Une fois ce message d'erreur reçu, le client devrait retenter seulement s'il a un jeu de certificats différent qui forment un chemin de certification acceptable pour le KDC.

   Si, pendant le traitement du chemin de certification, de KDC détermine qu'une signature dans le champ signedAuthPack est invalide, il retourne KRB-ERROR avec le code KDC_ERR_INVALID_CERTIFICATE. Le e-data qui l'accompagne est un TYPED-DATA qui contient un élément dont data-type est TD_INVALID_CERTIFICATES, et contient le DER du type TD-INVALID-CERTIFICATES:

TD-INVALID-CERTIFICATES ::= SEQUENCE OF
    ExternalPrincipalIdentifier
    -- Chaque ExternalPrincipalIdentifier identifie un
    -- Certificat (envoyé par le client) avec une signature invalide

   Si plus d'une signature est invalide, le KDC peut inclure un IssuerAndSerialNumber par signature invalide dans le TD-INVALID-CERTIFICATES. Le certificat X.509 du client est validé en accord avec la rfc3280.

   En fonction de la stratégie locale, le KDC peut également vérifier si un certificat X.509 dans le chemin de certification a été révoqué. Si c'est le cas, le KDC doit retourner un message d'erreur avec le code KDC_ERR_REVOKED_CERTIFICATE. Si le KDC tente de déterminer le statut de révocation mais n'est pas en mesure de le faire, il devrait retourner un message d'erreur avec le code KDC_ERR_REVOCATION_STATUS_UNKNOWN. Le ou les certificats affectés sont identifiés comme pour le code d'erreur KDC_ERR_INVALID_CERTIFICATE.

   Noter que les données d'erreur TD_INVALID_CERTIFICATES est uniquement utilisé pour identifier les certificats invalides envoyés par le client dans le demande.

   La clé publique du client est ainsi utilisée pour vérifier la signature. Si la vérification de la signature échoue, le KDC doit retourner un message d'erreur avec le code KDC_ERR_INVALID_SIG. Il n'y a pas de e-data pour ce message d'erreur.

   En plus de la validation de la signature du client, le KDC doit également vérifier que la clé publique du client utilisée pour vérifier la signature est liée au principal du client comme suit:

1. Si le KDC a sa propre liaison entre la clé publique du client ou le certificat du client et le nom du principal du client, il utilise cette liaison.
2. Sinon, si le certificat X.509 du client contient un SAN avec un KRB5PrincipalName dans le champ otherName de type GeneralName, il lie le certificat du client à ce nom.

Le type de champ otherName est AnotherName. Le champ type-id du type AnotherName est id-pkinit-san:
id-pkinit-san OBJECT IDENTIFIER ::=
    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
    x509SanAN (2) }

Et le champ valeur du type AnotherName est un KRB5PrincipalName:
KRB5PrincipalName ::= SEQUENCE {
    realm [0] Realm,
    principalName [1] PrincipalName
    }

   Si le nom du client dans le AS-REQ ne matche pas un nom lié par le KDC, ou s'il n'y a aucune liaison trouvée par le KDC, le KDC doit retourner un message d'erreur avec le code KDC_ERR_CLIENT_NAME_MISMATCH. Il n'y a pas de e-data pour ce type d'erreur.

   Même si le chemin de certification est validée et que le certificat est mappé au nom principal du client, le KDC peut décider de ne pas accepter le certificat du client, en fonction de la stratégie locale.

Le KDC peut imposer la présence du EKU KeyPurposeId id-pkinit-KDClientAuth dans le champ extensions du certificat du client:
id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
    pkinit(3) keyPurposeClientAuth(4) }
    -- PKINIT client authentication.
    -- Key usage bits that MUST be consistent:
    -- digitalSignature.

   Le bit d'utilisation de clé digitalSignature doit être présent quand le but du certificat du client est restreins avec le id-pkinit-KDClientAuth.

   Si ce EKU KeyPusposeId est requis mais n'est pas présent, ou si le certificat du client est restreins à ne pas l'utiliser pour PKINIT, le KDC doit retourner un message d'erreur avec le code KDC_ERR_INCONSISTENT_KEY_PURPOSE. Il n'y a pas de e-data pour cette erreur. Les KDC implémentant ce requis devraient également accepter le EKU KeyPurposeId id-ms-kp-sc-logon (1.3.6.1.4.1.311.20.2.2), vu que de nombreux certificats déployés pour PKINIT ont ce EKU.

   En conséquence de la stratégie locale, le KDC peut décider de rejeter les demandes sur la base de l'absence ou la présence d'autres EKU spécifiques.

   Si l'algorithme digest utilisé pour générer la signature CA pour la clé publique dans un certificat de la demande n'est pas acceptable, le KDC doit retourner un KRB-ERROR avec le code KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. Le e-data doit être un TYPED-DATA encodé, bien que rien n'est définis.

   Si la clé publique du client n'est pas acceptée pour des raisons autre que ceux spécifiés, le KDC retourne un message KRB-ERROR avec le code KDC_ERR_CLIENT_NOT_TRUSTED. Il n'y a pas de e-data dans ce message.

   Le KDC doit vérifier le timestamp pour s'assurer que la demande n'est pas rejouée, et que la plage de temps est dans la limite acceptable. Si la vérification échoue, le KDC doit retourner un code d'erreur KRB_AP_ERR_REPEAT ou KRB_AP_ERR_SKEW, respectivement.

   Si clientPublicValue est remplis, indiquant que le client désire utiliser la méthode d'agrément de clé DH, le KDC devrait vérifier si les paramètres satisfont sa stratégie. Si ce n'est pas le cas, il doit retourner un message d'erreur avec le code KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. Le e-data qui l'accompagne est un TYPED-DATA qui contient un élément dont le data-type est TD-DH--PARAMETERS:

TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
    -- Chaque AlgorithmIdentifier spécifie un jeu de
    -- paramètres de domaine Diifie-Hellman. Cette liste
    -- est dans l'ordre de préférence décroissante.

   La structure AlgorithmIdentifier est définie dans la rfc3280 et est renseigné en accord avec la rfc3279. Si le client inclus un champ kdcPkId dans le PA-PK-AS-REQ et que le KDC ne possède pas la clé correspondante, le KDC doit ignorer le kdcPkId comme si le client ne l'avait pas inclus.

   Si l'algorithme digest utilisé par le id-pkinit-authData n'est pas acceptable par le KDC, le KDC doit retourner un KRB-ERROR avec le code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED. Le e-data qui l'accompagne doit être encodé en TYPED-DATA, bien que rien n'est définis.

Génération de la réponse KDC

   Si le paChechsum dans la demande n'est pas présente, le KDC se conformant a cette spécification doivent retourner un KRB-ERROR avec le code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED. Le e-data qui l'accompagne doit être encodé dans un TYPED-DATA.

   En assumant que la demande du client a été validée, le KDC procède comme dans la rfc4120, excepté ce qui suit.

Le KDC doit mettre le flag initial et inclure un élément de donnée d'autorisation de ad-type AD_INITIAL_VERIFIED_CAS dans le ticket fournis. Le champ ad-data contient le DER du type AD-INITIAL-VERIFIED-CAS:
AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF ExternalPrincipalIdentifier
    -- Identifie le chemin de certification avec lequel le certificat
    -- client a été validé. Chaque ExternalPrincipalIdentifier
    -- identifie une CA ou un certificat CA

   Noter que la syntaxe pour les données d'autorisation AD-INITIAL-VERIFIED-CAS ne permet pas d'encoder des SEQUENCES vides. De tels séquences vides peuvent uniquement être utilisée si le KDC garantis lui-même le certificat du client.

   l'AS enveloppe toute donnée AD-INITIAL-VERIFIED-CAS dans des conteneur AD-IF-RELEVANT si la liste des CA satisfait la stratégie locale de l'AS. De plus, tout TGS doit copier de telles données d'autorisation depuis les tickets utilisé dans un PA-TGS-REQ du TGS-REQ dans le ticket résultant. Si la liste des CA satisfait la stratégie de domaine du KDC, le TGS peut envelopper les données dans le AD-IF-RELEVANT; sinon, il peut sortir les données d'autorisation du conteneur AD-IF-RELEVANT.

   Les serveurs d'application qui comprennent ce type de données d'autorisation devraient appliquer la stratégie locale pour déterminer si un ticket donné comportant un tel type non contenu dans un conteneur AD-IF-RELEVANT est acceptable. ( Cela correspond au serveur AP qui vérifie le champ transited quand le flag TRANSITED-POLICY-CHECKED n'est pas mis). Si un tel type de donnée est contenu dans un conteneur AD-IF-RELEVANT, les serveurs AP peuvent appliquer la stratégie locale pour déterminer si les données d'autorisation sont acceptables.

Un élément de donnée de pré-authentification, dont padata-type est PA_PK_AS_REP et dont padata-value contient le DER du type PA-PK-AS-REP, est inclus dans le AS-REP.
PA-PK-AS-REP ::= CHOICE {
    dhInfo [0] DHRepInfo,
    -- Sélectionné quand l'échange de clé DH est utilisé
    encKeyPack [1] IMPLICIT OCTET STRING,
    -- Sélectionné quand le chiffrement par clé publique est utilisé
    -- Contient un type CMS ContentInfo encodé
    -- le champ contentType de type ContentInfo est id-envelopedData (1.2.840.113549.1.7.3)
    -- Le champ content est un EnvelopedData
    -- le champ contentType pour le type EnvelopedData est id-signedData (1.2.840.113549.1.7.2)
    -- le champ eContentType pour le type SignedData est id-pkinit-rkeyData (1.3.6.1.5.2.3.3)
    -- et le champ eContent contient le DER du type ReplyKeyPack
}
KDCDHKeyInfo ::= SEQUENCE {
    subjectPublicKey [0] BIT STRING,
    -- La clé publique DH du KDC
    -- la clé publique DH est encodée en BIT STRING
    nonce [1] INTEGER (0..4294967295),
    -- Contient le nonce dans le champ pkAuthenticator dans le demande si les clés DH ne sont pas réutilisées. 0 sinon.
    dhKeyExpiration [2] KerberosTime OPTIONAL,
    -- Temp d'expiration pour la paire de clé du KDC, présent si est seulement si les clé DH sont réutilisées
    -- Si présent, la clé publique DH du KDC ne doit pas être utilisé passé cette expiration
    -- Si ce champ est omis, le champ serverDHNonce doit également être utilisé.
}

   Le contenu de AS-REP est inchangé sinon. Le KDC chiffre la réponse normalement, mais pas avec la clé long-terme du client. À la place, il le chiffre avec soit une clé partagée dérivée d'un échange DH, ou une clé de chiffrement générée. Le contenu de PA-PK-AS-REP indique quelle méthode de livraison de clé est utilisé.

   Si le client ne souhaite pas utiliser la méthode DH ( le champ clientPublicValue n'est pas présent dans la demande ) et que le KDC ne supporte pas la méthode de livraison de clé de chiffrement à clé publique, le KDC doit retourner un message d'erreur avec le code KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED. Il n'y a pas de e-data accompagnant ce message d'erreur.

   En plus, la durée de vie du ticket retourné par le KDC ne doit pas excéder celle de la paire de clé du client.

Utiliser l'échange de clé Diffie-Hellman

   Dans ce cas, le PA-PK-AS-REP contient une structure SHRepInfo. La structure ContentInfo pour le champ shSignedData est remplis comme suis:

1. Le champ contentType du type ContentInfo est id-signedData, et le champ content est un SignedData
2. Le champ eContentType pour le type SignedData est l'OID pour id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.
3. Le champ eContent pour le type SignedData contient le DER du type KDCDHKeyInfo.
4. La structure KDCDHKeyInfo contient la clé publique du KDC, un nonce, et optionnellement l'expiration de la clé DH du KDC qui est réutilisée. Le champ subjectPublicKey du type KDCDHKeyInfo identifie la clé publique DH du KDC. Ce clé est encodée en BIT STRING. Le champ nonce contient le nonce dans le champ pkAuthenticator dans le demande si les clés DH ne sont pas réutilisées. La valeur de ce champ nonce est 0 si les clés DH sont réutilisées. Le champ dhKeyExpiration est prisent si et seulement si les clé DH sont réutilisées. Si le champ dhKeyExpiration est présent, la clé publique DH du KDC dans cette structure KDCDHKeyInfo ne doit pas être utilisée passé ce temps. Si ce champ est omis, le champ serverDHNonce doit également être omis.
5. Le champ signerInfo du type SignedData contient un simple signerInfo, qui contient la signature pour le type KDCDHKeyInfo.
6. Le champ certificat du type SignedData contient les certificats prévus pour faciliter la construction du chemin de certification, pour que le client puisse vérifier la signature du KDC pour le type KDCDHKeyInfo. Les informations contenus dans le trustedCertifiers dans la demande devraient être utilisés par le KDC pour l'aider dans sa sélection d'une chaîne de certificats approprié à retourner au client. Ce champ peut être vide si la clé publique du KDC spécifiée par le champ kdcPkId dans le PA-PK-AS-REQ a été utilisé pour signer. Le KDC doit être capable d'inclure un tel jeu de certificat s'il est configuré pour le faire. Ce champ ne doit pas contenir de certificat CA root.
7. Si le client inclus le champ clientDHNonce, le KDC peut choisir de réutiliser ses clés DH, et doit inclure un temps d'expiration. Quand le serveur réutilise les clé DH, il doit inclure un serverDHNonce au moins aussi long que la longueur des clé pour le système de chiffrement symétrique utilisé pour chiffrer la réponse AS. Noter qu'inclure le serverDHNonce change la manière dont le client et le serveur calculent le clé à utiliser pour chiffrer la réponse. Le KDC ne dervait pas réutiliser les clé DH sauf si clientDHNonce est présent dans la demande.

   La réponse AS est dérivée comme suit:

1. Le KDC et le client calculent la clé partagée comme suit: Quand MODP Diffie-Hellman est utilisé, les DHSharedSecret être la valeur de clé secrète. DHSharedSecret est la valeur ZZ, et est remplis avec des 0 pour la taille en octets soit la même que le modulo, et représente une chaîne d'octet dans l'ordre big-endian.
2. Laisse K être la source de génération de clé de la réponse AS.
3. Définie la fonction octetstring2key() comme suis:

octetstring2key(x) == random-to-key(K-truncate(
    SHA1(0x00 | x) |
    SHA1(0x01 | x) |
    SHA1(0x02 | x) |
    ...
    ))

   où x est une chaîne d'octets, | est l'opérateur de concaténation, 0x00, etc. sont représentés comme octet simple, random-to-key() est une opération qui génère une clé de protocole depuis un bitstring de longueur K; et K-truncate tronque son entrée au premiers K bits.

4. Quand les clé DH sont réutilisées, laisse n_c être le clientDHNonce et n_k être le serverDHNonce, sinon ils sont vides.
5. La clé de réponse AS est: k = octetstring2key(DHSharedSecret | n_c | n_k)

Utiliser le chiffrement à clé publique

   Dans ce cas, le PA-PK-AS-REP contient le champ encKeyPack où la clé de réponse AS est chiffrée. La structure ContentInfo pour le champ encKeyPack est construit comme suit:

1. Le champ contentType du type ContentInfo est id-envelopedData, et le champ content est un EnvelopedData
2. Le champ contentType pour le type EnvelopedData est id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }
3. Le champ eContentType pour le type SignedData ( quand déchiffré depuis le champ EncryptedContent pour le type EnvelopedData) est id-pkinit-rkeyData: { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
4. Le champ eContent pour le type SignedData contient le DER du type ReplyKeyPack
5. Le champ signerInfos du type SignedData contient un simple signerInfo, qui contient la signature pour le type ReplyKeyPack.
6. Le champ certificates pour le type SignedData contient les certificats pour construire le chemin de certification, pour que le client puisse vérifier la signature du KDC pou le type ReplyKeyPack. Les informations contenues dans le trustedCertifiers dans la demande devraient être utilisés par le KDC comme guide dans sa sélection d'une chaîne de certification appropriée. Ce champ peut être vide si la clé publique du KDC spécifiée par le champ kdcPkId dans le PA-PK-AS-REQ a été utilisé pour signer. Sinon, pour la validation du chemin, ces certificats devraient être suffisant pour construire au moins un chemin de certification depuis le certificat du KDC. Le KDC doit être capable d'inclure un tel jeu s'il est configuré pour le faire. Ce champ ne doit pas contenir de certificat CA root.
7. Le champ recipientInfos du type EnvelopedData est un jeu qui doit contenir exactement un membre du type KeyTransRecipientInfo. Le encryptedKey de ce membre contient la clé temporaire qui est chiffrée en utilisant la clé publique du client.
8. Les champs unprotectedAttrs ou originatorInfos du type EnvelopedData peut être présent.

   S'il y a un champ supportedCMSTypes dans le AuthPack, le KDC doit vérifier s'il supporte un des types listés. S'il supporte plus d'un type, le KDC devrait utilisé le premiers qui listé. S'il n'en supporte aucun, le KDC doit retourner un message d'erreur avec le code KDC_ERR_ETYPE_NOSUPP.

   Le KDC calcule le checksum du AS-REQ dans la demande du client. Ce checksum est effectué sur le type AS-REQ, et la clé de protocole de l'opération checksum est le replyKey, et le numéro d'utilisation de clé est 6. Si le enctype de replyKey est "newer", l'opération checksum est l'opération checksum requise de ce enctype:

ReplyKeyPack ::= SEQUENCE {
    replyKey [0] EncryptionKey,
    -- contient la clé de session utilisé pour chiffrer le
    -- champ enc-part dans le AS-REP. par ex: la clé de réponse AS
    asChecksum [1] Checksum,
    -- Contient le checksum du AS-REQ correspondant au AS-REP
    -- Le checksum est effectué sur le type AS-REQ.
    ...
    }

   Les implémentations de cette méthode de livraison de clé de chiffrement RSA devraient supporter les clé RSA d'au moins 2048-bits.

Réception de la réponse du KDC

   Une fois la réponse du KDC reçus, le client procède comme suit. Si le PA-PK-AS-REP contient le champ dhSignedData, le client dérive le clé de réponse AS en utilisant la même procédure utilisée par le KDC. Sinon, le message contient le champ encKeyPack, et le client déchiffre de extrait la clé temporaire dans le champ encryptedKey du membre KeyTransRecipientInfo et l'utilise comme clé de réponse AS. Si la méthode de chiffrement à clé publique est utilisé, le client doit vérifier le asChecksum dans le ReplyKeyPack.

   Dans tous les cas, le client doit vérifier la signature dans le SignedData. En plus, sauf si le client peut vérifier que la clé publique utilisée pour vérifier la signature du KDC est liée au KDC du domaine cible, le certificat du KDC doit contenir un SAN ayant un AnotherName dont type-id est id-pkinit-san et dont la valeur est un KRB5PrincipalName qui correspond au nom du TGS du domaine cible.

À moins que le client connaisse par d'autres moyens que le certificat du KDC est prévu pour un KDC, le client doit imposer que le certificat du KDC contienne le EKU KeyPurposeId id-pkinit-KPKdc:
id-pkinit-KPKdc OBJECT IDENTIFIER ::=
    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) pkinit(3) keyPurposeKdc(5) }

   Le bit d'utilisation de clé digitalSignature doit être mis quand le but du certificat du KDC est restreins avec le EKU id-pkinit-KPKdc. Si le certificat du KDC contient le nom du TGS encodé en SAN id-pkinit-san, ce certificat est certifié par la CA qui l'a délivré, et donc l'EKU id-pkinit-KPKdc n'est pas requis. Si toutes les vérifications applicables sont satisfaites, le client déchiffre le champ enc-part du KDC-REP dans le AS-REP, utilisant la clé de réponse AS, puis procède normalement.

Prérequis d'intéropérabilité

Le client doit être capable d'envoyer un jer de certificats suffisant pour permettre au KDC de construire un chemin de certification pour le certificat du client, si le jeu correct de certificat est fournis via la configuration ou la stratégie. Si le client envoie tous les certificats X.509 dans un chemin de certification en une chaîne acceptable pour le KDC, et si le KDC ne peut par vérifier la clé publique du client, le KDC doit être capable de traiter la validation pour le certificat du client basé sur les certificats dans le demande.

Indication du support PKINIT

   Si la pré-authentification est requise mais n'est pas présente dans la requête, un message d'erreur avec le code KDC_ERR_PREAUTH_FAILED est retourné, et un objet METHOD-DATA sera présent dans le champ e-data du message KRB-ERROR pour spécifier quels mécanismes de pré-authentification sont acceptables. Le KDC peut ainsi indiquer le support de PKINIT en incluant un élément vide dont le padata-type est PA_PK_AS_REQ dans l'objet METHOD-DATA.

   Sinon s'il est requis par la stratégie local du KDC que le client doive être pré-authentifié en utilisant le mécanisme de pré-authentification spécifié dans ce document, mais qu'aucune pré-authentification PKINIT n'est présent dans la requête, une message d'erreur avec le code d'erreur KDC_ERR_PREAUTH_FAILED devrait être retourné.

   Le KDC doit laisser le champ padata-value de l'élément PA_PK_AS_REQ dans le METHOD-DATA du KRB-ERROR vide, et les clients doivent l'ignorer. De futures extensions de ce protocole peuvent spécifier d'autres données à envoyer au lieu d'un OCTET STRING vide.

19 octobre 2013

saslauthd

Service qui manipule les authentifications plaintext basé sur la librarie Cyrus SASL

OPTIONS

-a authmech Spécifie le mécanime à utiliser
-O option Options spécifiques au mécanisme, incluant l'hôte à contacter
-m path Chemin du socket pour les connexions (défaut : /var/state/saslauthd) sans "/mux"
threads Nombre de threads à traiter (défaut : 5)
-s size Taille de la table de hash en Ko
-t timeout temps d'expiration du cache d'authentification en secondes
-T' Honore les restriction de connection time-of-day
-c' Active le cache des crédentials
-l' Désactive l'utilisation d'un file lock pour contrôller l'accès à accept()
-r' Combine le roaume avec le login.
-d' Mode debug

Mécanismes d'authentification

getpwent Authentifie avec un fichier password local
kerberos4 Authentification kerberos v4
kerberos5 Authentification kerberos v5
pam' Utilise PAM
rimap' Remote IMAP server.
shadow' Utilise le fichier shadow local
sasldb' Authentifie avec la base SASL
ldap' Authentifie avec un serveur LDAP
sia' Authentifie en utilisant SE Linux

30 juin 2014

sclient

Application client exemple

sclient est une application d'exemple, principalement pour des tests. Il contacte un serveur d'exemple, sserver, et s'authentifie en utilisant un ticket Kerberos, puis affiche la réponse du serveur.

27 juin 2014

sserver

Serveur de démonstration

   sserver et sclient sont de simples progammes client/serveur de démonstration. Quand sclient se connecte à sserver, il effectue une authentification Kerberos, et le serveur retourne le principal Kerberos qui a été utilisé. Le nom de service utilisé par sserver et sclient est sample. sserver nécessite que l'entrée sample/hostname.domain.name@REALM.NAME dans le keytab. Ce keytab est généré en utilisant le programme kadmin. L'option -S permet d'utiliser un keytab différent de celui par défaut.

   Vu que sample n'a normalement pas de port définis dans /etc/services, il faut généralement ajouter:

  sample 13135/tcp

  En utilisant sclient, il faut d'abord avoir une entrée dans la base Kerberos, en utilisant kadmin, et obtenir des tickets Kerbeors avec kinit.

Exemple de réponse en utilisant sclient:
sendauth succeeded, reply is:
reply len 32, contents:
You are nlgilman@JIMI.MIT.EDU