(57)【要約】  登録者からレジストリへのトラストチェーンを確立するためのシステムおよび方法を提供する。登録者の登録機関へのドメイン名レコードの変更要求には、ワンタイムパスワードなどの、少なくとも１つの登録者要素を含む。登録機関は、変更を実行するための、その要素を含む拡張ＥＰＰコマンドを作成し、これをレジストリに送信することができる。レジストリは、少なくとも１つの要素を少なくとも１つの検証サーバを使用して検証できる。要素の検証が成功した場合、ＥＰＰはレジストリにより処理することができる。要素が検証されなかった場合、ＥＰＰコマンドは処理されず、エラーメッセージが生成され、登録機関に送信される。
2012530965.tif 000002
【特許請求の範囲】
【請求項１】
認証の方法であって、
レジストリサーバで、登録者ワンタイムパスワードおよび登録者ＩＤを含む拡張ＥＰＰコマンドを登録機関サーバから受信する段階と、
登録者ワンタイムパスワードおよび登録者ＩＤをレジストリサーバから検証サーバに送信する段階と、
レジストリサーバで、検証サーバからの検証メッセージを受信する段階と、
検証メッセージが、登録者ワンタイムパスワードの検証が成功したことを示す場合にのみ、レジストリでＥＰＰコマンドを処理する段階と
を有することを特徴とする方法。
【請求項２】
ＥＰＰコマンドが、移管、作成、削除、延長、および更新のうちの少なくとも１つのコマンドを含むことを特徴とする請求項１に記載の方法。
【請求項３】
登録者ＩＤがトークンＩＤであることを特徴とする請求項１に記載の方法。
【請求項４】
登録者ＩＤが登録者ユーザＩＤに基づいていることを特徴とする請求項１に記載の方法。
【請求項５】
認証の方法であって、
レジストリサーバで、少なくとも１つの登録者要素を含むメッセージを登録機関から受信する段階と、
少なくとも１つの登録者要素を少なくとも１つの検証サーバに送信する段階と、
少なくとも１つの検証メッセージを少なくとも１つの検証サーバから受信する段階と、
検証メッセージが、少なくとも１つの登録者要素が検証に成功したことを示す場合にのみ、レジストリでメッセージを処理する段階と
を有することを特徴とする方法。
【請求項６】
メッセージがＥＰＰコマンドを含むことを特徴とする請求項５に記載の方法。
【請求項７】
メッセージが、少なくとも１つの要素を含む拡張ＥＰＰコマンドであることを特徴とする請求項５に記載の方法。
【請求項８】
メッセージが、移管、作成、削除、延長、および更新のうちの少なくとも１つのＥＰＰコマンドを含むことを特徴とする請求項５に記載の方法。
【請求項９】
要素が、生体認証情報、ワンタイムパスワード、ＰＫＩ情報、ＳＭＳ情報、自動音声通話識別、およびデバイスＩＤのうちの少なくとも１つの情報を含むことを特徴とする請求項５に記載の方法。
【請求項１０】
レジストリで、登録者情報を受信する段階をさらに有することを特徴とする請求項５に記載の方法。
【請求項１１】
登録者情報が、登録者トークンＩＤ、登録者ログオンＩＤに基づく情報、および登録者のネットワークアドレス情報のうちの少なくとも１つの情報を含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
検証のために第２の検証サーバに送信する段階をさらに有することを特徴とする請求項５に記載の方法。
【請求項１３】
メッセージを処理する段階が、ドメイン名レコードの移管、作成、削除、延長、および更新のうちの少なくとも１つの処理を行う段階を含むことを特徴とする請求項５に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
レジストリサービスが複数の独立した登録機関の間で共有されているドメイン名登録システムが、共有登録システム（Ｓｈａｒｅｄ  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ｓｙｓｔｅｍ、ＳＲＳ）である。現在インターネットで実装されているＳＲＳは、Ｅｘｔｅｎｓｉｂｌｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ  Ｐｒｏｔｏｃｏｌ（ＥＰＰ）という、複数のサービスプロバイダ（登録機関など）がレジストリなどの共有の中心にあるオブジェクトを使用した、オブジェクトのプロビジョニング操作を実行できるようにするテキスト／ＸＭＬプロトコルを利用している。ＥＰＰは、実装固有の機能とその他のオブジェクト管理機能の修正および／または追加を実現する拡張メカニズムを含む。
【０００２】
ＳＲＳでは、ドメイン名の登録の整合性を保護するためにセキュリティが必要である。たとえば、正式に認定された登録機関のみがレジストリのドメイン名レコードの追加、削除、またはその他の修正をできるようにするためのセキュリティ対策が実装されている。このようなセキュリティ対策は、レジストリがＥＰＰコマンドを処理する前に、レジストリへの登録機関の認証要求を含むことができる。レジストリは、登録機関のデジタル証明書の検証、登録機関のパスワードの要求と検証、登録機関の通信元が、登録機関に関連付けられていることが分かっているＩＰアドレス（またはアドレス範囲）からのものであることの検証によって登録機関を認証できる。
【０００３】
セキュリティ対策はまた、登録者と登録機関との間の通信に対しても実装できる。ドメイン名に対する修正要求が、登録者そのものなどの認証された団体から正しく発信されていることを確かめることが重要である。このようなセキュリティ対策は、登録機関での登録者パスワードの要求および検証、登録者のデジタル証明書の検証などを含むことができる。
【０００４】
別のセキュリティ対策としてＡｕｔｈ  Ｉｎｆｏがある。これは、ドメイン名の移管の認可に使用される第２のパスワードを含む。登録者が移管を開始したい場合、登録者はそのＡｕｔｈ  Ｉｎｆｏパスワードを、取得登録機関、つまりそのパスワードを使用して移管要求を行う登録機関に提供する。第２のＡｕｔｈ  Ｉｎｆｏパスワードを使用すると、無認可のドメイン名の移管を防ぐことができる。
【０００５】
既知のセキュリティ対策は、すべての脅威に対し全面的に効果があるというわけではない。たとえば、実際の登録者の証明書を盗んだ無認可の存在は、登録者を装い、登録者名のドメイン名レコードを不正に追加、削除、または修正できる。同様に、登録機関（または、登録機関の証明書を持つ、登録機関を装った存在）は登録者のドメイン名レコードを不正に追加、削除または修正できる。必要なのは、実際の登録者の、ドメイン名レコードの変更認可を確実に検証できるシステムである。
【発明の概要】
【課題を解決するための手段】
【０００６】
本発明は、一般に、レジストリに保持されているドメイン名レコードを管理するためのシステムに関する。特には、本発明は、登録者からレジストリへの、多要素認証を使用したトラストチェーンを提供するための方法とシステムに関する。このトラストチェーンは、レジストリに保持されているドメイン名レコードへのいかなる変更も適切に要求され認可されたことを確実にするために役立てることができる。この方法および技術は、ハードウェアまたはソフトウェアに実装されたワンタイムパスワード（Ｏｎｅ  Ｔｉｍｅ  Ｐａｓｓｗｏｒｄｓ、ＯＴＰ）、生体認証、スマートカード、ＳＭＳ、自動音声通話検証、デバイスＩＤなどのハードウェアまたはソフトウェアベースのＰＫＩ技術を含む、任意の適切な１つのあるいは複数の認証要素を使用して実装できる。この要素は、本発明の実施態様に従って、ドメイン、ホスト、電子メール転送、防衛的登録などのオブジェクトのプロビジョニングでＥＰＰトランザクションの認証と認可を行うために使用できる。
【０００７】
本発明の実施態様に従って、登録者は、１つまたは複数の要素（ＯＴＰを生成できるＩＤを有した登録者トークン使用、登録者の指紋、虹彩または網膜の生体認証スキャン使用、スマートカード上の登録者のデジタル証明書使用など）を生成できる。登録者は、登録機関のＷｅｂサイトにログオンし、レジストリが保持しているドメイン名登録の追加、削除、または修正（変更）要求を送信できる。たとえば、登録者はドメイン名ｔｅｓｔ．ｃｏｍの登録要求（登録できる場合）、既に登録されているドメイン名のいずれかのネームサーバの変更要求、ドメイン名の移管などを送信できる。本発明の実施態様に従うと、登録者は登録機関へ、１つまたは複数の要素、たとえば登録者のトークンにより生成されたＯＴＰ、登録者の生体認証データ、スマートカードなどにある登録者の証明書などを、登録機関へ、任意で登録者のトークンＩＤと共に送信できる。登録機関が、登録者の資格情報、また場合によっては支払いを検証し承認すると、登録機関はレジストリへ、要求された変更の完了要求を作成できる。たとえば、登録機関は、登録者から提供された要素（ＯＴＰ、生体認証および／またはＰＫＩデータなど）を含む拡張ＥＰＰ  ＣＲＥＡＴＥコマンドを含む要求をレジストリのアプリケーションサーバ宛に作成し送信できる。レジストリのアプリケーションサーバは、この要素を、検証のため検証サーバに送信できる。この要素の検証が成功した場合、検証サーバは検証を確認するメッセージをレジストリのアプリケーションサーバに送信でき、そうするとアプリケーションサーバはＥＰＰコマンドを処理して、登録者が要求したドメインのドメイン名レコードを作成することができる。この方法では、レジストリのゾーンファイルは、変更要求が本物で認可されていることが検証された後にのみ変更される。
【０００８】
本発明のこれらおよびその他の実施形態は、後述のテキストおよび添付の図面と共により詳細に説明される。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態に従った方法を示すフローチャートである。
【図２】本発明の一実施形態に従ったシステムを示す図である。
【図３】本発明の一実施形態に従ったメッセージフローを示す図である。
【図４】本発明の一実施形態に従った、登録者の認証および認可のみを行うメッセージフローを示す図である。
【図５】本発明の一実施形態に従った、認証／認可要素を無効にするメッセージフローを示す図である。
【発明を実施するための形態】
【００１０】
本発明の一実施形態に従うと、登録者のドメイン名レコードの変更（追加、削除、修正）要求を認証および／または認可するために使用できる登録者からの情報（「要素」）は、登録機関からレコードを維持するレジストリへの、変更を指示するメッセージにバインドされる。この要素は、レジストリが登録機関からの変更メッセージを処理する前に検証することができる。この要素が検証されない場合、このメッセージに具体化された変更要求をレジストリは拒否することができる。これにより、無認可の存在が、ドメイン名レコードに不正に変更を行うことを防ぐことができる。また、登録機関が、登録者または別の、このような変更を行うことを許可されている存在の認可なしでドメイン名レコードを変更することを防ぐこともできる。
【００１１】
本発明の一実施形態に従った方法を図１に示す。この実施形態では、要素は登録者が所有するトークンにより生成できるワンタイムパスワード（ＯＴＰ）である。このトークンは、ハードウェアトークンとすることができる。あるいは登録者の携帯電話などの任意の適切なプラットフォーム上で実行するソフトウェアで実現されるＯＴＰジェネレータとすることができる。
【００１２】
登録者は、ログオンＩＤおよびパスワード、つまり登録者と登録機関との間の共有秘密を使用するなどして登録機関のＷｅｂサイトにログオンできる。登録者のログオン資格情報の検証が成功すると、登録機関は登録者から、登録者のドメイン名レコードのいずれかの変更要求を受信し承認することができる。たとえば、登録者は、登録者が既に登録しているドメイン名に関連付けられたネームサーバの変更要求を送信しても良い。または、登録者は、新しいドメイン名を登録する要求を送信し、登録に必要な情報を登録機関に提供しても良い。また、登録者は登録機関に、登録者のドメイン名の登録のいずれかを削除するよう要請することもできる。この要求と共に、登録者はＯＴＰとトークンＩＤを送信できる。
【００１３】
登録機関はレジストリに送信するための適切なＥＰＰコマンドを作成し、要求された変更がレジストリのドメイン名登録レコードに対し行われるよう送信することができる。ＥＰＰコマンドと共に、登録機関は、登録者から受信したＯＴＰを送信することができる。
【００１４】
この通信を登録機関から受信すると、レジストリはＯＴＰを検証サーバに送信できる。検証サーバはレジストリ自身またはＶｅｒｉＳｉｇｎなどの信頼されたサードパーティが運営できる。検証サーバは、ＯＴＰが本当にトークンにより生成されたかを検証できる。検証サーバは、その検証結果をレジストリに送信できる。ＯＴＰの検証が成功した場合、レジストリは、ドメイン名の登録者からの要求、および／またはレジストリが適切に認可されたことを確認でき、要求された変更を行える。変更要求メッセージの処理の成功または失敗を報告するメッセージを、レジストリから登録機関に送信できる。ＯＴＰの検証が成功しなかった場合、レジストリはエラーメッセージを生成し、登録機関に送信し、要求された変更は完了しない。
【００１５】
本発明の一実施形態に従うと、ＥＰＰ  ＣＲＥＡＴＥおよびＵＰＤＡＴＥコマンドで、ＯＴＰおよび任意でトークンＩＤの受け渡しをサポートできる。トークンＩＤがコマンドに含まれている場合、ＯＴＰは検証され、検証が成功した場合に、トークンＩＤおよび（任意で）ＥＰＰ作成または更新コマンドの一部である子オブジェクトをプロビジョニングオブジェクトにバインドできる。
【００１６】
以下の例は、トークンのドメインへのバインドに使用できるＥＰＰ拡張を示す。
ＯＴＰデータの非ＯＴＰドメインへの追加
<command>
<update>
<domain:update 
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" 
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd">
<domain:name>test.com</domain:name>
<domain:add/>
<domain:rem/>
<domain:chg/>
</domain:update>
</update>
<extension>
<otpAuth:create 
xmlns:otpAuth="http://www.verisign-grs.com/epp/otpAuth-1.0" 
xsi:schemaLocation="http://www.verisign-grs.com/epp/otpAuth-1.0 otpAuth-1.0.xsd">
<otpAuth:id>1234</otpAuth:id>
<otpAuth:otp>abcl23</otpAuth:otp>
<otpAuth:type>VIP</otpAuth:type>
</otpAuth:create>
</extension>
</command>
</epp>
上記のコードは、ＥＰＰ  ＵＰＤＡＴＥコマンドへの拡張（＜ｅｘｔｅｎｓｉｏｎ＞から＜／ｅｘｔｅｎｓｉｏｎ＞までの間）を示す。この拡張で、ｘｍｌｎｓ名前空間（ｈｔｔｐ：／／ｗｗｗ．ｖｅｒｉｓｉｇｎ−ｇｒｓ．ｃｏｍ／ｅｐｐ／ｏｔｐＡｕｔｈ−１．０）、トークンＩＤ（上記の「１２３４」）、およびＯＴＰ自身（「ａｂｃ１２３」）を指定する。
【００１７】
以下の例は、本発明の実施形態に従った拡張ＥＰＰ  ＵＰＤＡＴＥコマンドを示す。この例では、ＯＴＰのみがレジストリに送信され、トークンはドメインオブジェクトにバインドされたトークンＩＤを検索することにより読み出される。
ＯＴＰ認可を使用したドメイン更新
<?xml version="l.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:ietf:params:xml:ms:epp-1.0 epp-1.0.xsd">
<command>
<update>
<domain:update 
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" 
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd">
<domain:name>test.com</domain:name>
<domain:add>
<domain:ns>
<domain:hostObj>ns1.test.com</domain:hostObj>
</domain:ns>
<domain:status s="clientDeleteProhibited"/>
</domain:add>
<domain:rem/>
<domain:chg/>
</domain:update>
</update>
<extension>
<otpAuth:auth 
xmlns:otpAuth="http://www.verisign-grs.com/epp/otpAuth-1.0" 
xsi:schemaLocation="http://www.verisign-grs.com/epp/otpAuth-1.0 otpAuth-1.0.xsd">
<otpAuth:otp>abcl23</otpAuth:otp>
</otpAuth:auth>
</extension>
</command>
</epp>
上記のコードは、ドメイン「ｔｅｓｔ．ｃｏｍ」の登録を追加するＥＰＰ  ＵＰＤＡＴＥコマンドを示す。追加されたドメイン名レコードは、ホスト名「ｎｓｌ．ｔｅｓｔ．ｃｏｍ」を含め、レコードはロックされる（「ｃｌｉｅｎｔＤｅｌｅｔｅＰｒｏｈｉｂｉｔｅｄ」）。この拡張（＜ｅｘｔｅｎｓｉｏｎ＞から＜／ｅｘｔｅｎｓｉｏｎ＞タグの間）には、名前空間の情報およびＯＴＰ自身である「ａｂｃ１２３」が含まれる。
【００１８】
以下の例は、本発明の一実施形態に従った拡張ＥＰＰ  ＤＥＬＥＴＥコマンドを示す。
ＯＴＰ認可を使用したドメイン削除
<?xml version="l.0" encoding="UTF-8" standalone="no"?>
<epp 
xmlns="urn:ietf:params:xml:ns:epp-1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"
>
<command>
<delete>
<domain:delete 
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" 
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd"
>
<domain:name>test.com</domain:name>
</domain:delete>
</delete>
<extension>
<otpAuth:auth 
xmlns:otpAuth="http://www.verisign-grs.com/epp/otpAuth-1.0" 
xsi:schemaLocation="http://www.verisign-grs.com/epp/otpAuth-1.0 otpAuth-1.0.xsd">
<otpAuth:otp>abcl23</otpAuth:otp>
</otpAuth:auth>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
上記のコード例は、拡張ＥＰＰ  ＤＥＬＥＴＥコマンドに含められたＯＴＰ（「ａｂｃ１２３」）を示す。
【００１９】
以下の例は、本発明の一実施形態に従った拡張ＥＰＰ  ＴＲＡＮＳＦＥＲコマンドを示す。
ＯＴＰ認可を使用したドメイン移管要求
<epp 
xmlns="urn:ietf:params:xml:ns:epp-1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"
>
<command>
<transfer op="request">
<domain:transfer 
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" 
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd"
>
<domain:name>test.com</domain:name>
<domain:period unit="y">1</domain:period>
<domain:authInfo>
<domain:pw>corepw</domain:pw>
</domain:authInfo>
</domain:transfer>
</transfer>
<extension>
<otpAuth:auth 
xmlns:otpAuth="http://www.verisign-grs.com/epp/otpAuth-1.0" 
xsi:schemaLocation="http://www.verisign-grs.com/epp/otpAuth-1.0 otpAuth-1.0.xsd">
<otpAuth:otp>abcl23</otpAuth:otp>
</otpAuth:auth>
</extension>
</command>
</epp>
上記のコードは、ＥＰＰ  ＴＲＡＮＳＦＥＲコマンド拡張のＯＴＰ「ａｂｃ１２３」を含む。
【００２０】
場合によっては、登録機関は、プロビジョニングオブジェクトを本発明の実施形態に従った拡張セキュリティに更新する必要があることがある。たとえば、ドメインが自動延長されているが登録機関が登録者からの支払いを得られない場合などである。このような場合に、登録機関はドメインを削除（登録機関に登録手数料が払い戻されないことを避けるため）または、既存の登録者または新しい登録者からの支払いを得られるまでゾーンファイルから削除したいことがある。
【００２１】
本発明の実施形態は、ＥＰＰコマンドに登録機関のＯＴＰを含めることで、このような状況に対応できる。登録機関のＯＴＰがＥＰＰコマンドで提供された場合、登録者のＯＴＰを検証せずにドメインを更新できる。
【００２２】
自動化処理の一部として、多数のドメインを修正する必要がある場合は、ＥＰＰコマンドにＯＴＰ無効属性を含めることができる。この属性が「無効」に設定されると、ドメインは、登録機関または登録者のＯＴＰのいずれも検証せずに更新できる。ＥＰＰコマンドにはまた、ドメインレコードがＯＴＰなしで更新される理由の説明のために使用できる「無効理由」属性を含めることができる。無効の発生は、レジストリにより追跡でき、登録機関に報告できる。
【００２３】
トークンを紛失した場合、登録機関はＶｅｒｉＳｉｇｎなどのトークンプロバイダに連絡し、新しいトークンを、紛失したトークンが保護していたプロビジョニングオブジェクトにバインドさせることができる。登録機関は、登録者のＩＤを検証することにより新しいトークンが正しい登録者に届いていることを確認できる。
【００２４】
本発明の一実施形態に従って、登録機関は、古いトークンＩＤ、紛失したトークンから生成したＯＴＰ、および新しいトークンのＩＤを含むＥＰＰ  ＵＰＤＡＴＥコマンドを送信することにより、紛失したトークンを置き換えることができる。紛失したトークンから生成したＯＴＰの検証が成功すると、新しいトークンＩＤを更新するプロビジョニングオブジェクトにバインドできる。
【００２５】
本発明の実施形態は、複数要素を検証するため複数のベンダーで運用可能である。ベンダーは、ＳＲＳのセキュリティ要件を満たし、統合メカニズムを提供するものとする。一実施形態における検証サーバは、レジストリからの検証サーバおよびサードパーティからの検証サーバを含むことができる。
【００２６】
本発明に従ったシステムを図２に示す。登録者２０１は、登録機関２０２と通信し、登録機関は次にレジストリ２０３と通信する。登録者２０１は、１つまたは複数の登録者要素ジェネレータ２０４〜２０６にアクセスする。この実施形態では、登録者要素ジェネレータ２０４は、登録者ＯＴＰを生成できる登録者トークンである。登録者要素ジェネレータ２０５は指紋リーダまたは虹彩スキャナなどの生体認証リーダである。登録者２０１は、任意の数の要素ジェネレータを使用して良い。登録機関２０２は登録機関要素ジェネレータ２０７〜２０８と接続している。登録機関要素ジェネレータ２０７は、登録機関ＯＴＰを生成できる登録機関トークンである。登録機関は、任意の数の要素ジェネレータを使用して良い。レジストリ２０３は、検証サーバ２０９〜２１１と通信する。検証サーバ２０９はＯＴＰ検証サーバデータベース２１２に接続されているＯＴＰ検証サーバである。検証サーバデータベース２１２は、特定のトークンＩＤと、ＯＴＰの生成に使用されるトークンに格納された共有秘密とを関連付けるレコードを格納できる。他の検証サーバ２１０および２１１は、登録者および／または登録機関により提供された他の種類の要素（生体認証、証明書など）の検証に使用できる。検証サーバは、ＶｅｒｉＳｉｇｎなどの信頼できるサードパーティにより運営されていても良い。または、例えばレジストリ検証サーバ２１１として示すように、レジストリ自身が運営していても良い。
【００２７】
登録者２１０は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネットなどのネットワークを通じて登録機関２０２と通信する登録者コンピュータとやりとりするユーザとなることができる。ＯＴＰジェネレータ２０４および２０７は、ＯＡＴＨ準拠、タイムベース、ＬＤＡＰ、およびＯＴＰ生成用ＯＤＢＣをサポート可能なＶｅｒｉＳｉｇｎにより提供されるＵｎｉｆｉｅｄ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎトークン、あるいはその他の適切なＯＴＰジェネレータとすることができる。生体認証ジェネレータ２０５および２０８は、網膜スキャナ、虹彩スキャナ、指紋リーダ、音声認識ソフトウェア、またはその他の適切な生体認証要素ジェネレータとすることができる。
【００２８】
登録機関２０２は登録機関サーバとすることができ、ゲートウェイ、登録機関データベースおよびその他の登録機関を構成する当該技術において知られているコンポーネントを含むことができる。レジストリ２０３はゲートウェイサーバ、レジストリアプリケーションサーバおよびレジストリデータベースを含むことができる。ＯＴＰ検証サーバ２０９は、ＶｅｒｉＳｉｇｎ  Ｕｎｉｆｉｅｄ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ検証サーバ、または登録者２０１と登録機関２０２により送信されたＯＴＰを検証できる任意のその他の検証サーバとすることができる。生体認証検証サーバ２１０は、登録者２０１または登録機関２０２により送信された生体認証（網膜スキャン、指紋など）を検証できるサーバとすることができる。
【００２９】
図３は、本発明の一実施形態に従った、登録者からのドメイン名レコード変更要求の認証および認可にＯＴＰが使用されるメッセージフローを示す。登録者は登録機関Ｗｅｂサーバにログインし、登録者ＯＴＰを生成する。登録者ＯＴＰは、登録機関に、ドメイン名登録レコードの変更要求と共に送信される。登録機関は、要求された変更を完了するための登録者ＯＴＰを含む拡張ＥＰＰコマンドを含む要求を、レジストリへのトランスミッション用に作成する。レジストリが拡張ＥＰＰコマンドを登録機関から受信すると最初に、登録者のＯＴＰを、検証サーバに送信することにより検証する。検証サーバがＯＴＰを検証した場合、その結果をレジストリに返すためのメッセージを送信する。レジストリは、拡張ＥＰＰコマンドに記述されている変更を行い、応答を登録機関に返すことができる。そうすると登録機関は、要求された変更が正常に行われたことを登録者に知らせることができる。検証サーバがＯＴＰの検証に失敗した場合、その結果をレジストリに返すためのメッセージを送信できる。レジストリは拡張ＥＰＰコマンドを完了せず、エラーメッセージを登録機関に返す。
【００３０】
図４は、登録者が不在で、登録機関がたとえばレコードの削除や、現在のまたは別の登録者からの支払いを受領するまでのゾーンファイルからの削除といったドメイン名レコードの変更を行いたい場合の、本発明の一実施形態に従ったメッセージフローを示す。この場合、登録機関はＯＴＰを生成し、登録機関ＯＴＰを含む拡張ＥＰＰ要求を作成し、これをレジストリに送信する。レジストリは、登録機関ＯＴＰを検証サーバに送信して検証する。検証サーバが、登録機関ＯＴＰが検証されたことを通知した場合、レジストリはＥＰＰコマンドを処理する。検証サーバが検証が失敗したことを通知した場合、エラーメッセージが生成されレジストリに送信される。そうするとレジストリは、エラーメッセージを登録機関に送信できる。
【００３１】
図５は、無効条件が存在する（多数のドメインを変更する要求など）、変更の実施に要素を必要としない本発明の一実施形態に従った、メッセージフローを示す。この実施形態では、登録機関はＯＴＰ無効属性およびＯＴＰ無効理由属性を含む拡張ＥＰＰ要求を作成する。この拡張ＥＰＰコマンドは、レジストリで検査する人間のオペレータによって自動的に検査または参照される。検査者が、無効理由はＥＰＰコマンドを最初に要素検証することなく処理することを正当化するにふさわしいと判断した場合、ＥＰＰコマンドが処理される。検査者が、無効理由が不適当であると見なした場合、ＥＰＰコマンドは処理されず、エラーメッセージが登録機関へ送信される。
【００３２】
ＥＰＰコマンドと共に提供された要素は、本発明のさまざまな実施形態に従い、さまざまな方法で検証サーバにより検証することができる。一実施形態では、トークンＩＤはまた、レジストリに送信された拡張ＥＰＰコマンドに含まれる。トークンＩＤは、ＯＴＰと一緒に検証サーバに渡され、検証サーバはトークンＩＤを使用してＯＴＰ生成のベースとして使用される共有秘密を検索する。検証サーバは、この共有秘密をＯＴＰの検証に使用できる。別の実施形態では、登録機関は拡張ＥＰＰコマンド内に含められた、あるいは拡張ＥＰＰコマンドに加えて送信された登録者識別情報を含める。この登録者識別情報（登録者ユーザＩＤ、ログオンＩＤ、ハンドル、登録者ネットワークアドレス情報（ソースアドレス情報など）など）は、要素を検証するために使用できる登録者参照項目（トークン秘密、生体認証サンプルまたはそのハッシュ、証明書情報など）を検索するため、検証サーバが使用できる。
【００３３】
本発明のさらにその他の実施形態では、登録者からのドメイン名登録レコードの変更要求を認証および認可するために１つまたは複数の要素を使用しても良い。たとえば、登録者は登録機関への変更要求にＯＴＰおよび生体認証データを含めても良い。登録機関は、ＯＴＰと生体認証データの両方を、レジストリに送信する１つのＥＰＰコマンドに含めることができる。レジストリは、ＥＰＰコマンドを処理する前にＯＴＰと生体認証データの両方を検証できる。同様に、登録者からレジストリへのトラストチェーンを提供するため、任意の適切な要素の組み合わせを使用しても良い。それぞれの異なる要素は、他の要素と同じまたは異なる検証サーバに送信しても良い。
【００３４】
レジストリは、ＥＰＰコマンドの処理のための任意の適切なポリシーを実装できる。たとえば、レジストリは、通常のドメインに対するＥＰＰコマンドの処理には単一要素の検証を要求することができるが、高価値またはロックされているドメインに対するＥＰＰコマンド処理への前提条件として複数の要素の検証を要求することができる。レジストリは、ＥＰＰコマンドの処理前に複数の団体が検証可能な要素を提供することを要求することができる。たとえば、レジストリはドメインに対する「２者による制御」またはｎ人による制御ポリシーを実装することができる。
【００３５】
本発明はＥＰＰコマンドの使用に制限されない。任意の適切なプロビジョニングプロトコルにとって、本発明の実施形態の実装により確立できるトラストチェーンが有益となり得る。たとえば、出版−購読型システムのメッセージ受信者は、送信者が１つまたは複数の要素をメッセージと一緒にリレーサーバに出版のために送信すると、メッセージの送信者を認証できる。メッセージを受信すると、受信者は１つまたは複数の要素を１つまたは複数の検証サーバに、検証のため送信できる。検証の成功または失敗によりメッセージが本物であるかどうかを示すことができる。メッセージが実行可能な場合、受信者がこのメッセージを実行するかどうかは検証の成否が決定付けることができる。
【００３６】
本発明の実施形態に従うと、要素検証の１回または複数回試行が失敗すると、ＥＰＰコマンドの処理以外の動作が行われる結果となる。たとえば、検証失敗が繰り返されると、不正である可能性があると登録機関に、または更に詳細な解析のために不正検出および防止サービスに報告される。試行が行われる速度（たとえば単位時間（ｎ秒、ｍ分など）当たりの試行失敗回数）を、特定のドメイン、ドメインの種類、要求元、登録機関、登録者、登録者の種類などに関して報告できる。報告は、試行回数または頻度が、特定のしきい値に達するか超えた場合に行うようにすることができる。同様に、ドメインにバインドされているトークンが頻繁に変更される場合、具体的にはこのような変更が指定したしきい値（週に５度を超える場合など）を超えた場合にも報告できる。攻撃の回数または頻度が多い場合も、サービス妨害攻撃を示す場合があり、この場合も報告および適切な対応策をとることができる。セキュリティ違反の検出に対応するため、１つまたは複数のドメインに対する登録のロック、登録機関などの特定のソースから処理される要求回数の制限、特定の要素ジェネレータ（トークン、ＰＫＩスマートカード、生体認証リーダなど）または登録者からの処理要求の回数の制限などの任意の適切なアクションを取っても良い。
【００３７】
本発明の実施形態は、要素を非同期的に検証できる。たとえば、登録者は登録機関に、ドメイン名レコードを更新する要求を、ＯＴＰ、生体認証データ、スマートカードからのＰＫＩデータなどの少なくとも１つの要素と共に送信できる。登録機関は、更新コマンドと要素をレジストリに送信できる。レジストリはコマンドを受信して、対象（ドメイン）をｐｅｎｄｉｎｇＵｐｄａｔｅなどの保留ステータスに設定することにより、登録機関に成功メッセージを返すことができる。次にレジストリは、少なくとも１つの要素を１つまたは複数の検証サーバに、検証のため送信できる。検証結果に基づき、レジストリはドメイン名レコードへの更新を適用し、または適用せず、保留ステータスを削除する。そうすると登録機関は、保留中の要求の結果を、たとえばＥＰＰポーリングメッセージ経由で通知される。
【００３８】
本明細書で説明した例および実施形態は、例示のみを目的とし、その実例に鑑みたさまざまな修正または変更が、当業者によって想起され、これらは本出願および添付の特許請求の範囲の精神と範囲内に含まれるものである。
【符号の説明】
【００３９】
２０１  登録者
２０２  登録機関
２０３  レジストリ
２０４  登録者ワンタイムパスワードジェネレータ
２０５  登録者生体認証ジェネレータ
２０６  登録者要素ジェネレータ
２０７  登録機関ワンタイムパスワードジェネレータ
２０８  登録機関生体認証ジェネレータ
２０９  ワンタイムパスワード検証サーバ
２１０  生体認証検証サーバ
２１１  レジストリ検証サーバ
２１２  ワンタイムパスワード検証サーバデータベース
【図１】
2012530965.tif 000003
【図２】
2012530965.tif 000004
【図３】
2012530965.tif 000005
【図４】
2012530965.tif 000006
【図５】
2012530965.tif 000007
【国際調査報告】
2012530965.tif 000008