47th IETF ミーティング(アデレード)

インターネット・セキュリティ関連情報収集の報告

IPA セキュリティセンター

竹谷清康

山口嘉毅
isec-info@ipa.go.jp

1.全体概要

  47th IETFは、 3月25日から31日までアデレード(オー ストラリア)で開催された。その参加者は約1,600名であり、参加者の国 籍別比率は、高い順に 米国49%、オーストラリア11%、日本10%、英国4% であった。IPAからの参加者は 2名であった。次回のミーティング、 48th IETFは、2000年7月31日から8月4日までピッツバーグ(米国)で開催 される予定である。

2.IETFの概要

  IETF (Internet Engineering Task Force)は、ネット ワーク技術に関連した研究開発の国際コミュニティである。ここでは、 インターネットの標準技術をまとめた文書であるRFC に盛り込む技術に ついて議論される場となっている。現在、IETF を構成する次の8つのエ リアにおいて、73個のWG(working group)と16個のBOF(Birds of a Feather) によってセッションが行われた。

  全体的なセッションであるOpen Plenaryでは、現在各 エリアで具体的に取り組んでいない技術的な話題として WAP(Wireless Application Protocol)が取り上げられた。

3.SecurityAreaの概要

  現在、情報セキュリティに関するエリア(SEC)に存在 するWGの中で、今回セッションが行われたのは、次のWGであった。

  また、今後にWG として立ち上がるものとしてセッシ ョンが行われたのは、次のBOFであった。

  各セッションでは、Internet-Documentの内容に関す る議論と標準化に向けたスケジュールの提示がなされた。

 


idwg の報告

山口

  1998年10月に侵入検知技術のWGであるidwgが発足し、 交換されるデータの形式について議論がされてきた。具体的には、 次の項目について議論されており、各項目について Internet-Draftが公開されている。

  最新のInternet-Draft等は、チェアが運用する次 URL のサイトにて公開されている。 http://www.silicondefense.com/idwg/

1.要件 (Requirements Document)

  現状は、Internet-Draft (draft-ietf-idwg-requirements-02.txt) の通り。これをWGからIESG(Internet Engineering Steering Group) に提出 したところ、内容についてIESGからコメントがなされている。 IESGのコメントを受けて、作成者であるMark Wood氏が3週間以内に 更新する予定である。

2.データモデル (Data Defitnition)

  現状は、Internet-Draft (draft-ietf-idwg-data-model-02.txt)の通り。 データモデルについて、クラス構造に続き、Alert オブジェクトの記述例が 説明された。複数のノードからの同一攻撃やゆっくり実施される ポートスキャン等の脅威に対する記述については、更に検討との確認が なされた。Stuart Staniford-Chen 氏による発表であった。

  上記クラス構造は、次の図の通りである。

  また、Alert オブジェクトの記述例は、次の通りである。

      Alert.version = 1
      Alert.alertID = 14285812
      Alert.confidence = 100
      Alert.impact = 5
      Alert.success = 1
      Alert.method = 1
      Alert.name = cve.GENERIC-MAP-NOMATCH
      Alert.signature = Teardrop
      Alert.reaction = none
      Alert.Time.date = 1999/12/2
      Alert.Time.time = 12:01:25
      Alert.Time.miliseconds = 93464
      Alert.Analyzer.ident = 123123123
      Alert.Taget[0].Node.Address.category = 11
      Alert.Taget[0].Node.Address.data = 123.123.123.123
      Alert.Source[0].Node.Address.category = 11
      Alert.Source[0].Node.Address.data = 123.123.123.123
  

3.XMLとMIBの比較 (XML-DTD vs SMI-MIB)

  現状は、Internet-Draft (draft-mansfield-curry-idmef-xmlsmi-011.txt) の通り。XMLの実装におけるDTDとSMIの実装におけるSNMP MIB を比較した内容が確認された。IESGのコメントの中で、この比較内容に関連 した検討項目も確認され、今後、議論を継続する予定である。 Glenn Mansfield氏による発表であった。

4.XMLによる実装(DTD Definition)

  上記データモデルに基づき、XMLによる実装例が説明された。 teardrop とloadmodule攻撃に対するAlertオブジェクトを、 XMLによって記述した例を示し、タグ等が説明された。 Stuart Staniford-Chen 氏による発表であった。

  teardrop のXML記述例は、次の通りである。

   <idef-message version="0.2">
     <alert id="12345">
       <priority>1</priority>
       <severity>1.0</severity>
       <idsid>
         <id>123123123</id>
       </idsid>
       <time>
         <alert-time>
           <yy>1999</yy><mm>09</mm><dd>29</dd>
           <h>08</h><m>30</m><s>10</s>
           <offset>-4</offset>
         </alert-time>
       </time>
       <name>Denial of service/Net/Teardrop</name>
       <signature>Teardrop</signature>
       <method>knowledge</method>
       <trust>1.0</trust>
       <a_singlehost>
         <dst>
           <netaddress type="ipv4">
             <address>123.234.231.121</address>
             <info>Web server</info>
           </netaddress>
         </dst>
         <as_realorigin>
           <src>
             <netaddress type="ipv4">
               <address>222.121.111.112</address>
             </netaddress>
           </src>
         </as_realorigin>
       </a_singlehost>
     </alert>
   </idef-message>
    

  loadmodule攻撃 のXML記述例は、次の通りである。

   <idef-message version="0.2">
     <alert id="9873653az">
       <priority>1</priority>
       <severity>1.0</severity>
       <idsid>
         <id>12345678</id>
       </idsid>
       <time>
         <alert-time>
           <yy>1999</yy><mm>09</mm><dd>29</dd>
           <h>08</h><m>45</m><s>10</s>
           <offset>-4</offset>
         </alert-time>
       </time>
       <name>Privileges/Bad Parameter/Loadmodule</name>
       <signature>loadmodule forking shell</signature>
       <method>1</method>
       <trust>1.0</trust>
       <a_singlehost>
         <dst>
           <name>machine.domain.com</name>
           <netaddress type="ipv4">
             <address>123.234.345.456</address>
           </netaddress>
         </dst>
         <as_application>
           <service>
             <name>loadmodule</name>
             <process>
               <ident>12345</ident>
               <pathname>/usr/openwin/bin/loadmodule</pathname>
             </process>
           </service>
           <asa_user>
             <user type="unix">
               <username>joe</username>
               <userid>13243</userid>
             </user>
           </asa_user>
         </as_application>
       </a_singlehost>
     </alert>
   </idef-message>
    

5.syslogの概要

  1999年11月に開催されたBOFに引き続き行われたもので、 今後、WGとする予定である。 Syslogは、イベントログを収集するシステムのデファクトスタンダードであるが、 イベントログを収集するシステムのプロトコル部分は、 正式的にドキュメント化されてこなかった。 そのプロトコルについては、知られながらも ドキュメント化されていないセキュリティ上の問題が指摘されてきた。 このワーキンググループの目標は、既存のSyslogの仕組みにおける セキュリティやインテグリティ上の問題についてドキュメント化することである。 この作業においては、既存のプロトコルについて ドキュメント化するものとされた。 具体的には、メッセージを認証する仕組み等が検討される予定である。 また、実装については、既存の仕組みを邪魔しないことが確認された。 今回は議論の範囲の提示に止まった。

  最新のInternet-Draft等は、次 URLのサイトにて公開されている。 http://njlug.rutgers.edu/projects/syslog/archive/month

6.所感

  最新の国際的な業界標準をIPAの研究開発事業に活かすことや、 逆に、IPAの研究開発事業の成果を国際的な業界標準にする機会をつくること が非常に有意義である。不正アクセス対策技術の分野においては、IPA セキュリティセンターにおける研究開発プロジェクトの成果が、idwg と連携を図ってきたが、WGの動向より IPAからIETFに対する関わり方を 再検討すべきである。

以 上


Public-Key Infrastructure (X.509) WG(pkix)報告

竹谷

New Part 1 of RFC2459/ W. Polk (NIST)

内容更新部分
6 Certification Path Validation
追加部分  
4.2.1.15 Inhibit Any-Policy
4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point)
検討項目 
1988 ASN.1 syntaxでの記述
Elliptic Curve Digital Signature Algorithm (ECDSA)の扱い
     (7章に組込むか7章とECDSAとを合体する)
以上の課題を解決して、4月末までにはWGlastcallとしたいと説明。

Qualified Certificates/Stefan Santesson(addtrust)

SerialNumber については、D. Pinkas(Bull)が下記の提案を行ったため、今回も決着がつかず。
a) "Mary White 3" and "Mary White 22".
"A serial Number attribute may be used either in a DN or a
SubjectAltName to differentiate between two names (for two different
individuals) that otherwise would not be different."

b) "C = US ;OU = Delta ; OU1= Corporate ; CN= Mary White"
"C = US ;OU = Delta ; OU1= Marketing ; CN= Mary White"
"C = US ;OU = Delta ; OU1= Corporate ; CN= Mary Green "
while the permanent identifier would be
"C = US ; OU = Delta ; SN= 12345"
"A serial Number attribute may be used in a permanentIdentifier in
an otherName from a SubjectAltName. In that case, when used in
combination with the other components of the permanentIdentifier, it
defines a permanent identifier for the certificate owner for the
issuing CA (that is, two different entities will never get the same
permanent identifier)."

PKIX Roadmap/S. Turner(IECA)

draft-ietf-pkix-roadmap-05.txtの更新内容は次の通り。
参照ドキュメントの追加
[2459bis] "Internet X.509 Public Key Infrastructure Certificate and CRL Profile," <draft-ietf-pkix-new-part1-00.txt>
[2510bis] "Internet X.509 Public Key Infrastructure Certificate Management Protocols", <draft-ietf-pkix- rfc2510bis-00.txt>,
 [TECHNR] Internet X.509 Public Key Infrastructure Technical Requirements for a non-Repudiation Service <draft-ietf-pkix- technr-01.txt>
DOCUMENT TITLE: A String Representation of General Name
<draft-ietf-pkix-generalname-00.txt>
記述変更
[DVCS] とPOP for Key Management Keysに関する記述の変更 .
5.3 Key Usage Bitsの変更と5.4 Non-Repudiationの追加

Timestamp Protocol/D. Pinkas(Bull)
TimeStampToken のASN.1記述追加
TimeStampToken ::= ContentInfo
-- contentType is id-signedData ([CMS])
-- content is SignedData ([CMS])
ISOとの調整項目として@ Request message('mechanism' field)AError codesの追加があったが修正の必要なしと判断した様子。

DVCS (Data Validation and Certification Server) Protocols/Peter Sylvester (EdelWeb)

今回は、DVCS の概要をプレゼンテーションして、PKIX−WGのメンバーに積極的な支持を求めていた。
今回のドラフトが第4版になるが、TSP(タイムスタンプ)、SCVP、OCSP などに比べて、これまでWGのメンバーからのコメントが少なかった。
DVCS のサービスのタイプとしては次の 4つがある。

導入事例として
フランスの郵便サービス(La Poste http://www.laposte.fr/
KITETOA( http://www.kitetoa.com/)があると説明。

OCSP−X/Michael Myers(VeriSign Inc.)

draft-ietf-pkix-ocspx-01.txt
今回の修正部分
有効性パスを完全に確認するOCSP serversのレスポンスの定義の記述
id-pkix-ocsp-valid in the responseType field of the ResponseBytes syntax.
id-pkix-ocsp-valid OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }
追加の要求項目としては@Server Type(OCSP or OCSP-X)の定義
Aレスポンス(id-pkix-ocsp-valid or/and id-pkix-ocsp-path)の定義
Bポリシィ構造の定義CValidation data discovery(有効を確認する情報)
がある。

OCSP and SCVP/Ambarish Malpani(ValiCert)

draft-ietf-pkix-scvp-02.txt
両方のプロトコル(OCSPとSCVP)の必要性を説明していた。
(Malpani(両方の執筆者)の本音はSCVPのほうがいいと思っている?)

OCSPにおける役割分担

クライアントの役割

サーバーの役割

Build Cert Chain

Provide all requested Cert Status

Deal with policy Issues

Provide other Attribute informationtOP

Offline Cert Verification

 

SCVPにおける役割分担

クライアントの役割

サーバーの役割

Send Cert

Build Cert Chain

Send Disired Usaget

Offline Cert Verification

Send Trusted RootsOP

Find Status of Chain

Send Intermediate CertOP

Figure out Applicability of Cert for usage

 

Provide other Attribute informationtOP

SCVPの特徴

優位性

弱点

Simplify Client

Complicated Server

Enable Faster PKI Integration

Place a lot of Power

Centralized Cert policy management

 

Ability to support cpmplex Cert hierarchies

 

Syntax independentuse XML

 

 

属性証明書(Attribute Certificate) Profile/S. Farrell (Baltimore)

X.509 syntax と記述の同期や誤植などのマイナーな修正を完成してドラフトを完成予定。

son-of-RFC 2510/S. Farrell(Baltimore)
このドラフトは実装結果を踏まえたRFC2510の更新版である。
Revocation Passphraseの変更可能性以外は特に問題がない模様。

Mobile Credentials/Stephen Farrell (baltimore)

要件
wireless/keybackup/swiching platform but retaining id/"virtual"smartcard
NOT key escrow
課題
security of the protocol
IETFのどのWGで検討するか
(PKIX,BOF,overlap with IPSRA)
次回のミーティングではおそらくBOFとして開催される予定である。

PKI Disclosure Statement/ Stefan Santesson (addtrust)

公開内容
A contact info:
Certificate type, validation procedures and usage:
Reliance limits:
Obligations of subscribers:
Certificate status checking obligations of relying parties:
Limited warranty & disclaimer/Limitation of liability:
Applicable agreements, Certification Practice Statement, Certificate Policy:
Privacy policy:
Refund policy:
Applicable law and dispute resolution:
CA and repository licenses, trust marks, and audit:


S/MIME Mail Security WG(smime)

竹谷

"S/MIME Freeware Library" (SFL)
1月14日の米国輸出規制の改訂により、SFLのソースコードへのWebアクセスが自由になった。
http://www.armadillo.huntsville.al.us/software/smime/index.html

Electronic Signature Formats for long term electronic signature/J Ross (Security & Standards) D Pinkas (Bull)
draft-ietf-smime-esformats-00.txt
このドラフトはinformational RFCで、ETSI ES 201 733 V.1.1.1と技術仕様としては同じものです。(すなわち、EUの標準を公知することを目的としている。)
このドラフトのベースとなる標準化ドキュメントは次の通り。
* RFC 2630 Crytographic Message Syntax (CMS);
* ITU-T Recommendation X.509 Authentication framework;
* RFC 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile;
* RFC (to be published) PKIX Timestamping protocol.
* RFC (to be published) An Internet Attribute Certificate Profile for Authorization.


IP Security Protocol WG(ipsec)

竹谷

The Candidate AES Cipher Algorithms and Their Use With Ipsec/S. Frankel(NIST)

<draft-ietf-ipsec-ciph-aes-cbc-00.txt>
このドラフトは、AES最終5候補をIPsec Encapsulating Security Payload (ESP)で利用する仕様を記述したものである。
AESの初期の要件は、unclassified、publicly disclosed、available royalty-free worldwide、 capable of handling a block size of at least 128 bits、at a minimum, capable of handling key sizes of 128, 192, and 256 bitsで最終選定にあたっては、security、computational efficiency and memory requirements on a variety of software and hardware, including smart cards、flexibility and simplicityの要件が検討され、1 or 2 のAES暗号が選ばれる予定である。
Mode Cipher Block Chaining (CBC) mode
 Key size default key size for IPsec is 128 bits.
 Weak key 発見された場合は決して利用しないこと。
   (AES最終5候補には、今のところweak keyが見つかっていない)
Block size 16-octet (128-bit) blocksize
Rounds

Algorithm

Negotiable?

Default # of Rounds 

MARS

Yes

32

RC6

Yes

20

Rijndael

Yes

10, 12, 14*

Serpent

Yes

32

Twofish

Yes

16



IP Security Protocol WGにNISTから次のAESに対するコメント依頼が届いている。

Hi-
I would like to remind the IPSec community of the upcoming end to the Advanced Encryption Standard Round 2 comment period.
Public comments are due by May 15, 2000, and NIST would certainly be very interested in your community's opinions regarding the five AES finalists,MARS, RC6, Rijndael,Serpent, and Twofish.
After May 15, NIST will be reviewing all of the comments and analysis received to-date on the finalists, and then we will make our selection for the draft AES standard.
So, the end is quickly approaching, and this is the last opportunity that people will have to help us determine what the AES will be.
Official public comments should be sent to <AESRound2@nist.gov>. Any comments that you might care to provide will be appreciated.
Here are some helpful links:
Some suggested topics for public comments are listed in our call for Round2 comments (Sept. 1999):
<http://csrc.nist.gov/encryption/aes/round2/aes_9909.htm#sec3>
Papers submitted to the Third AES Candidate Conference(April 13-14, 2000):
<http://csrc.nist.gov/encryption/aes/round2/conf3/aes3papers.html>
Round 2 public comments received to-date:
<http://csrc.nist.gov/encryption/aes/round2/pubcmnts.htm>
The Candidate AES Cipher Algorithms and Their Use with IPSec:
<http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-00.txt>
AES Home Page:
<http://www.nist.gov/aes>
Thanks for your time & consideration.

Gratefully,
Jim
NIST AES team

XML Digital Signatures WG(xmldsig)

竹谷

CHAIR: Donald Eastlake (motorola)
今回2つのプレゼンテーション有り。
XML encoded SPKI certificates/ Juha Paarjavi
 単に証明書の形式がシンプルだという理由でSPKIを利用しているが、会場からは疑問の意見がでた。個人的にもこのドラフトはWGの同意を得られそうにないと思われる。

Demo of IBM XMLDSIG, XML element-wise encryption, and ASN.1<->XML code/羽田(日本IBM)
http://www.alphaworks.ibm.com/
XML Signaturesを実装したIBMのXML Security Suiteの説明とデモ

Signature

DetachedEnvelopingEnveloped

Algorithms

SHA1BASE64HMAC/ SHA1DSA/ SHA1RSA/ SHA1IBMJCE),XLM C14MXSLT Transform

Notyet implemented

Quoted PrintableManifestXpath Filtering

Never implemented

Minimal  C14M 

XLMの製品化が各社で盛んになってきている様子である。


IP Security Policy WG(ipsp)

竹谷

CHAIR: Luis A. Sanchez (bbn)
このWGは過去3回のBOF後、今年からWGとなった。
主な活動目的は

@標準的なIPsecのポリシーモデルの決定

Aベンダー仕様に依存しないポリシー記述言語の決定

B ポリシーの公開、交換プロトコルの開発

であり、今回のミーティングでは以下のドラフトの説明があった。

IPsec Configuration Policy Model/Jamie Jason(Intel)
draft-jason-ipsp-config-policy-model-00.txt
Security Policy Specification Language/M. Condell, (BBN)
draft-ietf-ipsp-spsl-00.txt
Compliance Checking and IPSEC Policy Management/Matt Blaze(AT&T)
draft-blaze-ipsp-trustmgt-00.txt



他のエリア

Applications Area

Applications Open Area Meeting(apparea)

アプリケーションエリアWG/BOFは活動状況により大きく4つに分類できる。
(1) 順調に活動している WG (2)ドラフトの検討がほぼ完了したWG (3)休止状態に近いWG (4)新しい検討テーマのBOF

(1) 今回ミーティングが開催され活動が順調なWG

Calendaring and Scheduling (calsch)  良好
Common Name Resolution Protocol (cnrp)  良好
Content Negotiation (conneg)  ほぼ完了
Instant Messaging and Presence Protocol (impp)  活動中
Internet Fax (fax)  活動中
Internet Open Trading Protocol (trade)  活動中
Internet Printing Protocol (ipp)  活動中
LDAP Duplication/Replication/Update Protocols (ldup)  活動中
LDAP Extension (ldapext)  良好
Message Tracking Protocol (msgtrk)  ほぼ良好
Resource Capabilities Discovery (rescap)  活動中
Web Versioning and Configuration Management (deltav) 活動中

(2) 完了またはほぼ完了したWG

Mail and Directory Management (madman)  完了
Printer MIB (printmib)  完了
Detailed Revision/Update of Message Standards (drums)  ほぼ完了
Electronic Data Interchange-Internet Integration (ediint)  ドラフトがほぼ完了
Extensions to FTP (ftpext)  1つのドラフト以外は完了
HyperText Transfer Protocol (http)  ほぼ完了
Telnet TN3270 Enhancements (tn3270e)  ほぼ完了
Uniform Resource Names (urn)  ほぼ完了
Usenet Article Standard Update (usefor)  活動中
Web Replication and Caching (wrec)  活動中
Application Configuration Access Protocol (acap)

(3) 活動が休止または進捗が遅いWG

DAV Searching and Locating (dasl)  休止
WWW Distributed Authoring and Versioning (webdav)  休止状態
NNTP Extensions (nntpext)  進捗が遅い

(4) 今回BOFとして開催されたテーマ

Voice Profile for Internet Mail BOF(vpim)
Internet Message Access Protocol Extension BOF(imapext)
An Application Protocol Framework & A Model Application BOF(blocks)
High Quality Document Transfer BOF(qualdocs)
Business to Business XML Data Communication Strategies BOF(b2bxml)
Spatial Location BOF(spatial)

以上