Subject: [mile] 6046-bis - Client certificate identity check

From: <[email-masked]>
Date: Wed, 25 Jan 2012 12:39:13 -0500

Brian and Kathleen,

I think I found something in looking at the text related to the question about
certificate identities, but some more input would be useful.

The 6046-bis-08 draft says:

   RID systems MUST verify the identity of their peers against that
   stored in the certificate presented, as in section 6 of [RFC6125].

That covers verification of the identity of the receiving system (the identity
in the TLS server certificate has to match host component of URI for HTTP), but
I don't think it covers verification of the identity of the sending system, as
Section 6 of RFC 6125 concerns only service identity.

I'd suggest adding some text that requires that the identity of the sending
system in the TLS client certificate match the NodeName in the Node element
of the RIDPolicy class if the NodeName is present. That "is present" complication
is courtesy of 6045-bis reusing the IODEF Node class from RFC 5070, because
RFC 5070 does not require that NodeName be present. 

I'm not sure what to do if NodeName is absent - a possible approach would be to
not go there, and instead add a requirement to 6045-bis that NodeName MUST be
present in the Node element of the RIDPolicy class in order to facilitate
this identity check.

What do other people think?

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: <[email-masked]>
Date: Wed, 25 Jan 2012 13:20:52 -0500

Hi David,

Thank you for the comments.  If text is added, it will need to be specific to the instance of Node in RID or IODEF.  This would mean the CN would be used for this purpose (if UTF-8 names are OKed for use in RID NodeNames with the internationalization discussions).  RID uses Node in two places and it may make more sense to reference the one in the IODEF document or change something in RID.

Instances of where 'Node' appears:
1) Node in SourceFound would not apply here.

2) Node in RID RIDPolicy is tied to MsgDestination and would be the receiving Node or the suspected source of an incident if a traceback were in play.  

3) This means the connection would need to be to the IODEF document and would require the document to be decrypted to verify if this were necessary.  Or adding a Node instance specific to the sending host information.

4) If it were tied to IODEF, the use of Node in the System class is specific to the source and destination addresses involved in an attack. The EventData where contact category is set to "infrastructure" is the place where systems involved in communicating IODEF documents are listed.  This is the path information for incident data (lists all of the 'from' systems in RID communications).

Thanks,
Kathleen (as editor)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 25, 2012 12:39 PM
To: [email-masked]
Subject: [mile] 6046-bis - Client certificate identity check

Brian and Kathleen,

Thanks,
--David

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: <[email-masked]>
Date: Wed, 25 Jan 2012 14:00:19 -0500

Hi Kathleen,

I missed the connection between Node and MsgDestination in 6045-bis - my mistake.

It might be useful to repeat the following text from the specification of "MsgDestination"
in the specification of the Node element in RIDPolicy, as those specifications are 5
pages apart, and the current specification of the Node element is not precise about
usage:

         the meaning of the value
         in the Node element is determined by the MsgDestination element

OTOH, I now don't see anything in RID that represents the identity of the system sending
the RID message, and I don't think adding that is important enough to make a change at
this juncture.  I also don't see any point in trying to use the enveloped IODEF document
to carry the identity of the sending RID system, as that document could get forwarded
in a different RID message, for which it would contain the wrong sending RID system
identity.

If there's no instance of the sending RID system's identity in the RID message, then I
suppose the client identity verification would have to be based on the information used
to set up the trust relationships in the consortium.  The 6046-bis draft already has a
reference to the PKI discussion in 6045-bis. Would it make sense to clarify 6046-bis
to indicate that RFC 6125 Section 6 applies only to server identity verification and the
PKI material in 6045-bis applies to both server and client identity verification?

Thanks,
--David

> From: Moriarty, Kathleen
> Sent: Wednesday, January 25, 2012 1:21 PM
> To: Black, David; [email-masked]
> Subject: RE: 6046-bis - Client certificate identity check
> 
> Hi David,
> 
> Thank you for the comments.  If text is added, it will need to be specific to the instance of Node in
> RID or IODEF.  This would mean the CN would be used for this purpose (if UTF-8 names are OKed for use
> in RID NodeNames with the internationalization discussions).  RID uses Node in two places and it may
> make more sense to reference the one in the IODEF document or change something in RID.
> 
> 2) Node in RID RIDPolicy is tied to MsgDestination and would be the receiving Node or the suspected
> source of an incident if a traceback were in play.
> 
> 3) This means the connection would need to be to the IODEF document and would require the document to
> be decrypted to verify if this were necessary.  Or adding a Node instance specific to the sending host
> information.
> 
> 4) If it were tied to IODEF, the use of Node in the System class is specific to the source and
> destination addresses involved in an attack. The EventData where contact category is set to
> "infrastructure" is the place where systems involved in communicating IODEF documents are listed.
> This is the path information for incident data (lists all of the 'from' systems in RID
> communications).
> 
> Thanks,
> Kathleen (as editor)
>

---

From: <[email-masked]>
Date: Wed, 25 Jan 2012 14:28:08 -0500

Hi David,

Thank you.  The Node information contained within IODEF is important to know the systems involved in handling an incident.  This is important at the IODEF document level as the incident information would stay with the IODEF document even though a new RID message may be used.  I hope that helps to clarify the reason for this information at the IODEF document level.

I am not sure.  RFC6045-bis would say verify the role as opposed to client for authentication and I am pretty sure that is already in there.  The only thing I think that needs to be decided is if we have to clarify the NOT RECOMMENDED in the paragraph about mutual authentication since this may be read as specific to mutual authentication, where DNS-ID is required.  Maybe it is fine...

I think the only outstanding issue is with RFC6045 and if Punycode should be allowed in the RID XML document.

Thanks,
Kathleen

-----Original Message-----
From: Black, David 
Sent: Wednesday, January 25, 2012 2:00 PM
To: Moriarty, Kathleen; [email-masked]
Subject: RE: 6046-bis - Client certificate identity check

Hi Kathleen,

         the meaning of the value

Thanks,
--David

---

From: <[email-masked]>
Date: Wed, 25 Jan 2012 14:46:44 -0500

Hi Kathleen,

Thank you for the response.

> I think the only outstanding issue is with RFC6045 and if Punycode should be allowed in the RID XML

Ok, adding text to the Node description in RIDPolicy to say that MsgDestination determines what Node means
is editorial. I missed this connection due to the distance between the descriptions of Node and
MsgDestination, but if you don't see the need for this as editor of the draft, that's your choice.

My outstanding concern for 6046-bis is that the following text in -08 appears to be wrong because

> >    stored in the certificate presented, as in section 6 of [RFC6125].

For the client certificate, it looks like the only means of identity verification is path validation
of the TLS client certificate against the server's trust store.  A sentence to say that directly
could be an alternative to a pointer to 6045-bis's PKI material.

Thanks,
--David

> Sent: Wednesday, January 25, 2012 2:28 PM
> Thank you.  The Node information contained within IODEF is important to know the systems involved in
> handling an incident.  This is important at the IODEF document level as the incident information would
> stay with the IODEF document even though a new RID message may be used.  I hope that helps to clarify
> the reason for this information at the IODEF document level.
> 
> I am not sure.  RFC6045-bis would say verify the role as opposed to client for authentication and I am
> pretty sure that is already in there.  The only thing I think that needs to be decided is if we have
> to clarify the NOT RECOMMENDED in the paragraph about mutual authentication since this may be read as
> specific to mutual authentication, where DNS-ID is required.  Maybe it is fine...
>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 25 Jan 2012 20:50:31 +0100

Hi, David,

Thanks for the comments; I've been out of contact all day so am catching up. I'll top-post my summary reply at first; I may have further detail replies in a subsequent message.

1. I would need to think more deeply about the implications of any authentication also cross-checking the DNS-ID against not only network-layer available identifiers but also against information stored within the RID document itself. There seems to be a bit of a chicken and egg problem there, and it seems to me that there may be valid exceptions to a policy that would be simple enough to be (a) implementable and (b) verifiable. 

2. It is not the intent that 6125 section 4 applies solely to the authentication of the TLS server; _all_ authentication in RID over HTTPS must be mutual, and I believe the current proposed text (copied below straight from xml source) to be clear on this point, in context. If that's not the case, then we'll need to change it.

    <t>RID systems MUST use TLS version 1.1 <xref target="RFC4346"/> or higher
    for confidentiality, identification, and authentication, when sending RID
    messages over HTTPS. HTTPS is specified in Section 2 of <xref
    target="RFC2818"/>. RID systems MUST use mutual authentication; that is,
    both RID systems acting as HTTPS clients and RID systems acting as HTTPS
    servers MUST be identified by an <xref target="RFC5280">X.509
    certificate</xref>. Mutual authentication requires full path validation on
    each certificate, as defined in <xref target="RFC5280"/>.</t>

    <t>The TLS session MUST use non-NULL ciphersuites for authentication,
    integrity, and confidentiality. Sessions MAY be renegotiated within these
    constraints.</t>

    <t>RID systems MUST verify the identity of their peers against that stored
    in the certificate presented. All RID systems MUST be identified by a
    certificate containing a <xref target="RFC5280">DNS-ID identifier</xref>
    as in section 6.4 of <xref target="RFC6125"/>. The inclusion of Common
    Names (CN-IDs) in certificates identifying RID systems is NOT RECOMMENDED.
    Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate
    identifying a RID system. Additional general information on the use of PKI
    with RID systems is detailed in Section 9.3 of <xref
    target="I-D.ietf-mile-rfc6045-bis"/>.</t>

    <t>RID systems MUST support TLS version 1.1 and SHOULD support TLS version
    1.2 <xref target="RFC5246"/>; RID systems MUST NOT request, offer, or use
    any version of SSL, or any version of TLS prior to 1.1, due to known
    security vulnerabilities in prior versions of the protocol; see Appendix E
    of <xref target="RFC5246"/> for more.</t>

Best regards,

Brian

---

From: <[email-masked]>
Date: Wed, 25 Jan 2012 14:50:45 -0500

I am happy to add some text to the Node description, sorry I didn't address that in my last email.

I'll leave the other comment to Brian.

Thank you,
Kathleen (as editor)

-----Original Message-----
From: Black, David 
Sent: Wednesday, January 25, 2012 2:47 PM
To: Moriarty, Kathleen; [email-masked]
Subject: RE: 6046-bis - Client certificate identity check

Hi Kathleen,

Thanks,
--David

---

From: <[email-masked]>
Date: Wed, 25 Jan 2012 14:55:11 -0500

Hi Brian,

You can save your time on #1, the question/request was withdrawn.  The sending RID server may only appear within the IODEF document and not the RID XML document.

Thank you,
Kathleen

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Wednesday, January 25, 2012 2:51 PM
To: Black, David
Cc: Moriarty, Kathleen; [email-masked]
Subject: Re: [mile] 6046-bis - Client certificate identity check

Hi, David,

Best regards,

Brian

---

From: <[email-masked]>
Date: Wed, 25 Jan 2012 15:24:56 -0500

Hi Brian,

Kathleen quickly disposed of #1, so please ignore that.  She'll add some text to
6045-bis to help other readers avoid the mistake that I made.

For #2, the short summary of my concern with the current text involves this sentence:

>     in the certificate presented.

How does a RID system (as TLS client or server) do that?

The next sentence explains what the identity is, but not how to verify it:

> 	All RID systems MUST be identified by a
>     as in section 6.4 of <xref target="RFC6125"/>.

In particular, section 6.4 of RFC 6125 doesn't specify what the certificate identity
is checked against.  It may even be that section 6.4 of RFC 6125 doesn't apply to
client certificates, because the client identity check my be subsumed by PKIX path
validation of the client certificate against the server's trust store, which does
name comparison according to RFC 5280, not RFC 6125.

A sentence or two on how to do that required (MUST) identity verification would help.

Thanks,
--David

> Sent: Wednesday, January 25, 2012 2:55 PM
> To: Brian Trammell; Black, David
> Cc: [email-masked]
> Subject: RE: [mile] 6046-bis - Client certificate identity check
> 
> Hi Brian,
> 
> You can save your time on #1, the question/request was withdrawn.  The sending RID server may only
> appear within the IODEF document and not the RID XML document.
> 
> Thank you,
> Kathleen
> 
> Thanks for the comments; I've been out of contact all day so am catching up. I'll top-post my summary
> reply at first; I may have further detail replies in a subsequent message.
> 
> 1. I would need to think more deeply about the implications of any authentication also cross-checking
> the DNS-ID against not only network-layer available identifiers but also against information stored
> within the RID document itself. There seems to be a bit of a chicken and egg problem there, and it
> seems to me that there may be valid exceptions to a policy that would be simple enough to be (a)
> implementable and (b) verifiable.
> 
> 2. It is not the intent that 6125 section 4 applies solely to the authentication of the TLS server;
> _all_ authentication in RID over HTTPS must be mutual, and I believe the current proposed text (copied
> below straight from xml source) to be clear on this point, in context. If that's not the case, then
> we'll need to change it.
>

---

From: <[email-masked]>
Date: Wed, 25 Jan 2012 14:29:39 -0600

Folks,

I must have been asleep here but we are not looking to put punycode into  the XML are we?  That would be really ugly…

Why shouldn't the punycode translation be handled by the DNS client and keep the XML document to UTF-8 encoding, including the NodeName?

Thanks.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>
Date: Wed, 25 Jan 2012 13:50:45 -0600
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] 6046-bis - Client certificate identity check

Thank you,
Kathleen (as editor)

-----Original Message-----
From: Black, David
Sent: Wednesday, January 25, 2012 2:47 PM
To: Moriarty, Kathleen; [email-masked]<mailto:[email-masked]>
Subject: RE: 6046-bis - Client certificate identity check

Hi Kathleen,

I think the only outstanding issue is with RFC6045 and if Punycode should be allowed in the RID XML
document.

Thanks,
--David

-----Original Message-----
From: Moriarty, Kathleen
Sent: Wednesday, January 25, 2012 2:28 PM
To: Black, David; [email-masked]<mailto:[email-masked]>
Subject: RE: 6046-bis - Client certificate identity check
Hi David,
I think the only outstanding issue is with RFC6045 and if Punycode should be allowed in the RID XML
document.
Thanks,
Kathleen
-----Original Message-----
From: Black, David
Sent: Wednesday, January 25, 2012 2:00 PM
To: Moriarty, Kathleen; [email-masked]<mailto:[email-masked]>
Subject: RE: 6046-bis - Client certificate identity check
Hi Kathleen,
> To: Black, David; [email-masked]<mailto:[email-masked]>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>        Mobile: +1 (978) 394-7754
> [email-masked]<mailto:[email-masked]>

_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

---

From: Brian Trammell <[email-masked]>
Date: Wed, 25 Jan 2012 22:17:46 +0100

Hi, David,

The reference identifier (defined in RFC 6215 section 1.8; explained in 6.2) in RID transport is (presumably) the identity one system uses to connect to another (see paragraph 12 of 6046-bis-08 section 3: "...the use of stable DNS names to address RID Systems is RECOMMENDED"). This could perhaps be made more explicit but it seemed obvious enough.

For mutual authentication, this would have to be derived from a reverse mapping of the network address back to a name (either by DNS PTR records, or a whitelist of consortium members). 

Perhaps stating "each RID system MUST maintain a DNS-ID reference identifier for those RID systems it participates in a consortium with, and use this for comparison with the DNS-ID stored in the certificate presented by RID system peers" would address this concern?

Regards,

Brian

---

From: <[email-masked]>
Date: Wed, 25 Jan 2012 16:54:03 -0500

Hello,

The comment period on changes to this draft has a come to a close.  Thank you all for your comments and contributions to improve the work.  Thank you Brian for your efforts to resolve any issues or discussions.  Please post an -09 version to finalize any of the discussion points that were agreed upon.

Great job!

Best regards,
Kathleen (as a WG chair)

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Wednesday, January 25, 2012 4:18 PM
To: Black, David; Moriarty, Kathleen
Cc: Peter Saint-Andre; Alexey Melnikov; Sean Turner; [email-masked]
Subject: Re: [mile] 6046-bis - Client certificate identity check

Hi, David,

Regards,

Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 25 Jan 2012 16:16:30 -0700

David is right that TLS client needs to have some expectations about the
domain name of the TLS server. In RFC 6125 this is called a "reference
identifier". In client-server protocols the expectation is typically set
by a human user who has configured a client with account information,
typed a URL in a browser location bar, etc. In protocols that have two
servers interacting, you'd typically get the reference identifier from
user-generated messages (e.g., email or IM) or in the case of something
like RID have a whitelist of entities that are members of your
consortium. So the text that Brian suggests seems reasonable to me.

On 1/25/12 2:17 PM, Brian Trammell wrote:
> Hi, David,
> 
> The reference identifier (defined in RFC 6215 section 1.8; explained
> in 6.2) in RID transport is (presumably) the identity one system uses
> to connect to another (see paragraph 12 of 6046-bis-08 section 3:
> "...the use of stable DNS names to address RID Systems is
> RECOMMENDED"). This could perhaps be made more explicit but it seemed
> obvious enough.
> 
> For mutual authentication, this would have to be derived from a
> reverse mapping of the network address back to a name (either by DNS
> PTR records, or a whitelist of consortium members).
> 
> Perhaps stating "each RID system MUST maintain a DNS-ID reference
> identifier for those RID systems it participates in a consortium
> with, and use this for comparison with the DNS-ID stored in the
> certificate presented by RID system peers" would address this
> concern?
> 
> Regards,
> 
> Brian
> 
>> Kathleen quickly disposed of #1, so please ignore that.  She'll add
>> some text to 6045-bis to help other readers avoid the mistake that
>> I made.
>> 
>>> <t>RID systems MUST verify the identity of their peers against
>>> that stored in the certificate presented.
>> 
>>> All RID systems MUST be identified by a certificate containing a
>>> <xref target="RFC5280">DNS-ID identifier</xref> as in section 6.4
>>> of <xref target="RFC6125"/>.
>> 
>> In particular, section 6.4 of RFC 6125 doesn't specify what the
>> certificate identity is checked against.  It may even be that
>> section 6.4 of RFC 6125 doesn't apply to client certificates,
>> because the client identity check my be subsumed by PKIX path 
>> validation of the client certificate against the server's trust
>> store, which does name comparison according to RFC 5280, not RFC
>> 6125.
>> 
>> Thanks, --David
>>> -----Original Message----- From: Moriarty, Kathleen Sent:
>>> Wednesday, January 25, 2012 2:55 PM To: Brian Trammell; Black,
>>> David Cc: [email-masked] Subject: RE: [mile] 6046-bis - Client
>>> certificate identity check
>>> 
>>> Hi Brian,
>>> 
>>> You can save your time on #1, the question/request was withdrawn.
>>> The sending RID server may only appear within the IODEF document
>>> and not the RID XML document.
>>> 
>>> Thank you, Kathleen
>>> 
>>> -----Original Message----- From: Brian Trammell
>>> [mailto:[email-masked]] Sent: Wednesday, January 25,
>>> 2012 2:51 PM To: Black, David Cc: Moriarty, Kathleen;
>>> [email-masked] Subject: Re: [mile] 6046-bis - Client certificate
>>> identity check
>>> 
>>> Hi, David,
>>> 
>>> Thanks for the comments; I've been out of contact all day so am
>>> catching up. I'll top-post my summary reply at first; I may have
>>> further detail replies in a subsequent message.
>>> 
>>> 1. I would need to think more deeply about the implications of
>>> any authentication also cross-checking the DNS-ID against not
>>> only network-layer available identifiers but also against
>>> information stored within the RID document itself. There seems to
>>> be a bit of a chicken and egg problem there, and it seems to me
>>> that there may be valid exceptions to a policy that would be
>>> simple enough to be (a) implementable and (b) verifiable.
>>> 
>>> 2. It is not the intent that 6125 section 4 applies solely to the
>>> authentication of the TLS server; _all_ authentication in RID
>>> over HTTPS must be mutual, and I believe the current proposed
>>> text (copied below straight from xml source) to be clear on this
>>> point, in context. If that's not the case, then we'll need to
>>> change it.
>>> 
>>> <t>RID systems MUST use TLS version 1.1 <xref target="RFC4346"/>
>>> or higher for confidentiality, identification, and
>>> authentication, when sending RID messages over HTTPS. HTTPS is
>>> specified in Section 2 of <xref target="RFC2818"/>. RID systems
>>> MUST use mutual authentication; that is, both RID systems acting
>>> as HTTPS clients and RID systems acting as HTTPS servers MUST be
>>> identified by an <xref target="RFC5280">X.509 certificate</xref>.
>>> Mutual authentication requires full path validation on each
>>> certificate, as defined in <xref target="RFC5280"/>.</t>
>>> 
>>> <t>The TLS session MUST use non-NULL ciphersuites for
>>> authentication, integrity, and confidentiality. Sessions MAY be
>>> renegotiated within these constraints.</t>
>>> 
>>> <t>RID systems MUST verify the identity of their peers against
>>> that stored in the certificate presented. All RID systems MUST be
>>> identified by a certificate containing a <xref
>>> target="RFC5280">DNS-ID identifier</xref> as in section 6.4 of
>>> <xref target="RFC6125"/>. The inclusion of Common Names (CN-IDs)
>>> in certificates identifying RID systems is NOT RECOMMENDED. 
>>> Wildcards MUST NOT appear in the DNS-ID or CN-ID of a
>>> certificate identifying a RID system. Additional general
>>> information on the use of PKI with RID systems is detailed in
>>> Section 9.3 of <xref target="I-D.ietf-mile-rfc6045-bis"/>.</t>
>>> 
>>> <t>RID systems MUST support TLS version 1.1 and SHOULD support
>>> TLS version 1.2 <xref target="RFC5246"/>; RID systems MUST NOT
>>> request, offer, or use any version of SSL, or any version of TLS
>>> prior to 1.1, due to known security vulnerabilities in prior
>>> versions of the protocol; see Appendix E of <xref
>>> target="RFC5246"/> for more.</t>
>>> 
>>> Best regards,
>>> 
>>> Brian
>>> 
>>>> It might be useful to repeat the following text from the
>>>> specification of "MsgDestination" in the specification of the
>>>> Node element in RIDPolicy, as those specifications are 5 pages
>>>> apart, and the current specification of the Node element is not
>>>> precise about usage:
>>>> 
>>>> the meaning of the value in the Node element is determined by
>>>> the MsgDestination element
>>>> 
>>>> OTOH, I now don't see anything in RID that represents the
>>>> identity of the system sending the RID message, and I don't
>>>> think adding that is important enough to make a change at this
>>>> juncture.  I also don't see any point in trying to use the
>>>> enveloped IODEF document to carry the identity of the sending
>>>> RID system, as that document could get forwarded in a different
>>>> RID message, for which it would contain the wrong sending RID
>>>> system identity.
>>>> 
>>>> If there's no instance of the sending RID system's identity in
>>>> the RID message, then I suppose the client identity
>>>> verification would have to be based on the information used to
>>>> set up the trust relationships in the consortium.  The 6046-bis
>>>> draft already has a reference to the PKI discussion in
>>>> 6045-bis. Would it make sense to clarify 6046-bis to indicate
>>>> that RFC 6125 Section 6 applies only to server identity
>>>> verification and the PKI material in 6045-bis applies to both
>>>> server and client identity verification?
>>>> 
>>>> Thanks, --David
>>>> 
>>>>> -----Original Message----- From: Moriarty, Kathleen Sent:
>>>>> Wednesday, January 25, 2012 1:21 PM To: Black, David;
>>>>> [email-masked] Subject: RE: 6046-bis - Client certificate
>>>>> identity check
>>>>> 
>>>>> Hi David,
>>>>> 
>>>>> Thank you for the comments.  If text is added, it will need
>>>>> to be specific to the instance of Node
>>> in
>>>>> RID or IODEF.  This would mean the CN would be used for this
>>>>> purpose (if UTF-8 names are OKed for
>>> use
>>>>> in RID NodeNames with the internationalization discussions).
>>>>> RID uses Node in two places and it
>>> may
>>>>> Instances of where 'Node' appears: 1) Node in SourceFound
>>>>> would not apply here.
>>>>> 
>>>>> 2) Node in RID RIDPolicy is tied to MsgDestination and would
>>>>> be the receiving Node or the suspected source of an incident
>>>>> if a traceback were in play.
>>>>> 
>>>>> 3) This means the connection would need to be to the IODEF
>>>>> document and would require the document
>>> to
>>>>> be decrypted to verify if this were necessary.  Or adding a
>>>>> Node instance specific to the sending
>>> host
>>>>> information.
>>>>> 
>>>>> 4) If it were tied to IODEF, the use of Node in the System
>>>>> class is specific to the source and destination addresses
>>>>> involved in an attack. The EventData where contact category
>>>>> is set to "infrastructure" is the place where systems
>>>>> involved in communicating IODEF documents are listed. This is
>>>>> the path information for incident data (lists all of the
>>>>> 'from' systems in RID communications).
>>>>> 
>>>>> Thanks, Kathleen (as editor)
>>>>> 
>>>>> -----Original Message----- From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of
>>>>> [email-masked] Sent: Wednesday, January 25, 2012 12:39
>>>>> PM To: [email-masked] Subject: [mile] 6046-bis - Client
>>>>> certificate identity check
>>>>> 
>>>>> Brian and Kathleen,
>>>>> 
>>>>> I think I found something in looking at the text related to
>>>>> the question about certificate identities, but some more
>>>>> input would be useful.
>>>>> 
>>>>> RID systems MUST verify the identity of their peers against
>>>>> that stored in the certificate presented, as in section 6 of
>>>>> [RFC6125].
>>>>> 
>>>>> That covers verification of the identity of the receiving
>>>>> system (the identity in the TLS server certificate has to
>>>>> match host component of URI for HTTP), but I don't think it
>>>>> covers verification of the identity of the sending system,
>>>>> as Section 6 of RFC 6125 concerns only service identity.
>>>>> 
>>>>> I'd suggest adding some text that requires that the identity
>>>>> of the sending system in the TLS client certificate match the
>>>>> NodeName in the Node element of the RIDPolicy class if the
>>>>> NodeName is present. That "is present" complication is
>>>>> courtesy of 6045-bis reusing the IODEF Node class from RFC
>>>>> 5070, because RFC 5070 does not require that NodeName be
>>>>> present.
>>>>> 
>>>>> I'm not sure what to do if NodeName is absent - a possible
>>>>> approach would be to not go there, and instead add a
>>>>> requirement to 6045-bis that NodeName MUST be present in the
>>>>> Node element of the RIDPolicy class in order to facilitate 
>>>>> this identity check.
>>>>> 
>>>>> Thanks, --David 
>>>>> ---------------------------------------------------- David L.
>>>>> Black, Distinguished Engineer EMC Corporation, 176 South St.,
>>>>> Hopkinton, MA  01748 +1 (508) 293-7953             FAX: +1
>>>>> (508) 293-7786 [email-masked]        Mobile: +1 (978)
>>>>> 394-7754 
>>>>> _______________________________________________ mile mailing
>>>>> list [email-masked] 
>>>> _______________________________________________ mile mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/mile

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 26 Jan 2012 19:21:26 +0000

> For mutual authentication, this would have to be derived from a reverse mapping of the network address back to a name (either by DNS PTR records, or a whitelist of consortium members).
David is correct that RFC 6125 can only be used by the entity that 
actively connect to another one (i.e. by the client to verify the server).

If you find the burden of maintaining the reverse DNS mapping to be 
acceptable for your protocol (for deployments of some other protocols, 
like SMTP that burden was found to be unacceptable), then you can use 
RFC 6125 for verifying clients by servers.

If you are not concerned about one RID member masquerading as another, 
it might be sufficient for your protocol to allow client certificates to 
come from a known CA (or a set of CAs), or be whitelisted.  So basically 
you will use more relaxed verification rules from RFC 5280.

> Regards,
>
> Brian
>
> On Jan 25, 2012, at 9:24 PM,<[email-masked]>  <[email-masked]>  wrote:
>
>> Hi Brian,
>>
>>>     certificate containing a<xref target="RFC5280">DNS-ID identifier</xref>
>>>     as in section 6.4 of<xref target="RFC6125"/>.
>>>     <t>RID systems MUST use TLS version 1.1<xref target="RFC4346"/>  or higher
>>>     messages over HTTPS. HTTPS is specified in Section 2 of<xref
>>>     servers MUST be identified by an<xref target="RFC5280">X.509
>>>     each certificate, as defined in<xref target="RFC5280"/>.</t>
>>>
>>>     certificate containing a<xref target="RFC5280">DNS-ID identifier</xref>
>>>     as in section 6.4 of<xref target="RFC6125"/>. The inclusion of Common
>>>     with RID systems is detailed in Section 9.3 of<xref
>>>     1.2<xref target="RFC5246"/>; RID systems MUST NOT request, offer, or use
>>>     of<xref target="RFC5246"/>  for more.</t>
>>>
>>> Best regards,
>>>
>>> Brian
>>>
>>> On Jan 25, 2012, at 8:00 PM,<[email-masked]>  wrote:
>>>
>>>> Hi Kathleen,
>>>>

---

From: <[email-masked]>
Date: Thu, 26 Jan 2012 14:33:51 -0500

Hello Alexy,

If you look at the current version, the sentence that said the CA was trusted as opposed to having an association of a certificate to an entity, has been removed.  That should no longer be a concern.  Here is the text in RFC6046-bis in the current draft that is relevant:

   HTTPS is specified in Section 2 of [RFC2818].
   RID systems MUST use mutual authentication; that is, both RID systems
   acting as HTTPS clients and RID systems acting as HTTPS servers MUST
   be identified by an X.509 certificate [RFC5280].  Mutual
   authentication requires full path validation on each certificate, as
   defined in [RFC5280].

I'll let Brian address the second question on stable DNS names.

Thanks,
Kathleen

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 26 Jan 2012 12:34:21 -0700

> actively connect to another one (i.e. by the client to verify the server).

English nit: s/i.e./e.g./ (because it can be used by one server
connecting to another server, as we're sort of doing here).

> RFC 6125 for verifying clients by servers.

My sense is that in RID consortia, this is seen as an acceptable burden
because the number of members in each consortium is manageable. But
that's something that RID participants probably need to verify.

> you will use more relaxed verification rules from RFC 5280.

Well, I think you'd probably still want to do the domain check, no?

>> identifier for those RID systems it participates in a consortium with,
>> and use this for comparison with the DNS-ID stored in the certificate
>> presented by RID system peers" would address this concern?
> 
>> Regards,
>>
>> Brian
>>
>>> some text to
>>> certificate identity
>>> store, which does
>>>> The sending RID server may only
>>>> catching up. I'll top-post my summary
>>>> authentication of the TLS server;
>>>> authentication,
>>>> that stored
>>>> TLS version
>>>>> specification of "MsgDestination"
>>>>>> Thank you for the comments.  If text is added, it will need to be
>>>>>> specific to the instance of Node
>>>> in
>>>>>> in RID NodeNames with the internationalization discussions).  RID
>>>>>> uses Node in two places and it
>>>> may
>>>>>> be decrypted to verify if this were necessary.  Or adding a Node
>>>>>> instance specific to the sending
>>>> host
>>>>>> information.
>>>>>>
>>>>>> "infrastructure" is the place where systems involved in
>>>>>> communicating IODEF documents are listed.
>>>>>> approach would be to

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: <[email-masked]>
Date: Thu, 26 Jan 2012 14:41:28 -0500

I'll leave the rest to Brian, but confirm the consortium expectations:

In terms of incident sharing groups, right now they are either industry based or small groups.  People want to share with people that they know and hence think they can trust.  The Advanced Cyber Security Center (ACSC) is an example in New England that is cross industry.  They are setting a model that others are starting to follow where membership is limited to 30 organizations and they meet regularly in person (in addition to any online sharing).  This group plans to peer with other groups and the sharing arrangements could vary within the consortium or between other consortiums.  The consortiums work out detailed agreements, so maintaining this type of information really should not be an issue in those models.

Thanks,
Kathleen

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]]
Sent: Thursday, January 26, 2012 2:34 PM
To: Alexey Melnikov
Cc: Brian Trammell; Black, David; Moriarty, Kathleen; Sean Turner; [email-masked]
Subject: Re: [mile] 6046-bis - Client certificate identity check

--
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 26 Jan 2012 13:09:06 -0700

Thanks for the clarification.

OT: I think the "meeting in person" part is important!

On 1/26/12 12:41 PM, [email-masked] wrote:
> In terms of incident sharing groups, right now they are either
> industry based or small groups.  People want to share with people
> that they know and hence think they can trust.  The Advanced Cyber
> Security Center (ACSC) is an example in New England that is cross
> industry.  They are setting a model that others are starting to
> follow where membership is limited to 30 organizations and they meet
> regularly in person (in addition to any online sharing).  This group
> plans to peer with other groups and the sharing arrangements could
> vary within the consortium or between other consortiums.  The
> consortiums work out detailed agreements, so maintaining this type of
> information really should not be an issue in those models.
> 
> Thanks, Kathleen
> 
> -----Original Message----- From: Peter Saint-Andre
> [mailto:[email-masked]] Sent: Thursday, January 26, 2012 2:34 PM 
> To: Alexey Melnikov Cc: Brian Trammell; Black, David; Moriarty,
> Kathleen; Sean Turner; [email-masked] Subject: Re: [mile] 6046-bis -
> Client certificate identity check
> 
>>> The reference identifier (defined in RFC 6215 section 1.8;
>>> explained in 6.2) in RID transport is (presumably) the identity
>>> one system uses to connect to another (see paragraph 12 of
>>> 6046-bis-08 section 3: "...the use of stable DNS names to address
>>> RID Systems is RECOMMENDED"). This could perhaps be made more
>>> explicit but it seemed obvious enough.
>>> 
>>> reverse mapping of the network address back to a name (either by
>>> DNS PTR records, or a whitelist of consortium members).
>> If you find the burden of maintaining the reverse DNS mapping to
>> be acceptable for your protocol (for deployments of some other
>> protocols, like SMTP that burden was found to be unacceptable),
>> then you can use RFC 6125 for verifying clients by servers.
> 
> My sense is that in RID consortia, this is seen as an acceptable
> burden because the number of members in each consortium is
> manageable. But that's something that RID participants probably need
> to verify.
> 
>> If you are not concerned about one RID member masquerading as
>> another, it might be sufficient for your protocol to allow client
>> certificates to come from a known CA (or a set of CAs), or be
>> whitelisted.  So basically you will use more relaxed verification
>> rules from RFC 5280.
> 
>>> Perhaps stating "each RID system MUST maintain a DNS-ID
>>> reference identifier for those RID systems it participates in a
>>> consortium with, and use this for comparison with the DNS-ID
>>> stored in the certificate presented by RID system peers" would
>>> address this concern?
>> 
>>> Regards,
>>> 
>>> Brian
>>> 
>>>> Kathleen quickly disposed of #1, so please ignore that.  She'll
>>>> add some text to 6045-bis to help other readers avoid the
>>>> mistake that I made.
>>>> 
>>>>> <t>RID systems MUST verify the identity of their peers
>>>>> against that stored in the certificate presented.
>>>>> All RID systems MUST be identified by a certificate
>>>>> containing a<xref target="RFC5280">DNS-ID identifier</xref> 
>>>> In particular, section 6.4 of RFC 6125 doesn't specify what
>>>> the certificate identity is checked against.  It may even be
>>>> that section 6.4 of RFC 6125 doesn't apply to client
>>>> certificates, because the client identity check my be subsumed 
>>>> by PKIX path validation of the client certificate against the
>>>> server's trust store, which does name comparison according to
>>>> RFC 5280, not RFC 6125.
>>>> 
>>>>> Wednesday, January 25, 2012 2:55 PM To: Brian Trammell;
>>>>> Black, David Cc: [email-masked] Subject: RE: [mile] 6046-bis -
>>>>> Client certificate identity check
>>>>> 
>>>>> Hi Brian,
>>>>> 
>>>>> You can save your time on #1, the question/request was
>>>>> withdrawn. The sending RID server may only appear within the
>>>>> IODEF document and not the RID XML document.
>>>>> 
>>>>> Thank you, Kathleen
>>>>> 
>>>>> [email-masked] Subject: Re: [mile] 6046-bis - Client
>>>>> Thanks for the comments; I've been out of contact all day so
>>>>> am catching up. I'll top-post my summary reply at first; I
>>>>> may have further detail replies in a subsequent message.
>>>>> 
>>>>> 1. I would need to think more deeply about the implications
>>>>> of any authentication also cross-checking the DNS-ID against
>>>>> not only network-layer available identifiers but also against
>>>>> information stored within the RID document itself. There
>>>>> seems to be a bit of a chicken and egg problem there, and it 
>>>>> seems to me that there may be valid exceptions to a policy
>>>>> that would be simple enough to be (a) implementable and (b)
>>>>> verifiable.
>>>>> 
>>>>> 2. It is not the intent that 6125 section 4 applies solely to
>>>>> the authentication of the TLS server; _all_ authentication in
>>>>> RID over HTTPS must be mutual, and I believe the current
>>>>> proposed text (copied below straight from xml source) to be
>>>>> clear on this point, in context. If that's not the case,
>>>>> then we'll need to change it.
>>>>> 
>>>>> <t>RID systems MUST use TLS version 1.1<xref
>>>>> target="RFC4346"/> or higher for confidentiality,
>>>>> identification, and authentication, when sending RID messages
>>>>> over HTTPS. HTTPS is specified in Section 2 of<xref 
>>>>> target="RFC2818"/>. RID systems MUST use mutual
>>>>> authentication; that is, both RID systems acting as HTTPS
>>>>> clients and RID systems acting as HTTPS servers MUST be
>>>>> identified by an<xref target="RFC5280">X.509 
>>>>> certificate</xref>. Mutual authentication requires full path 
>>>>> validation on each certificate, as defined in<xref
>>>>> target="RFC5280"/>.</t>
>>>>> 
>>>>> authentication, integrity, and confidentiality. Sessions MAY
>>>>> be renegotiated within these constraints.</t>
>>>>> 
>>>>> <t>RID systems MUST verify the identity of their peers
>>>>> against that stored in the certificate presented. All RID
>>>>> systems MUST be identified by a certificate containing a<xref
>>>>> target="RFC5280">DNS-ID identifier</xref> as in section 6.4
>>>>> of<xref target="RFC6125"/>. The inclusion of Common Names
>>>>> (CN-IDs) in certificates identifying RID systems is NOT 
>>>>> RECOMMENDED. Wildcards MUST NOT appear in the DNS-ID or CN-ID
>>>>> of a certificate identifying a RID system. Additional general
>>>>> Section 9.3 of<xref 
>>>>> <t>RID systems MUST support TLS version 1.1 and SHOULD
>>>>> support TLS version 1.2<xref target="RFC5246"/>; RID systems
>>>>> MUST NOT request, offer, or use any version of SSL, or any
>>>>> version of TLS prior to 1.1, due to known security
>>>>> vulnerabilities in prior versions of the protocol; see 
>>>>> Appendix E of<xref target="RFC5246"/>  for more.</t>
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> Brian
>>>>> 
>>>>>> specification of "MsgDestination" in the specification of
>>>>>> the Node element in RIDPolicy, as those specifications are
>>>>>> 5 pages apart, and the current specification of the Node
>>>>>> element is not precise about usage:
>>>>>> 
>>>>>> the meaning of the value in the Node element is determined
>>>>>> by the MsgDestination element
>>>>>> 
>>>>>> think adding that is important enough to make a change at 
>>>>>> this juncture.  I also don't see any point in trying to use
>>>>>> the enveloped IODEF document to carry the identity of the
>>>>>> sending RID system, as that document could get forwarded in
>>>>>> a different RID message, for which it would contain the
>>>>>> wrong sending RID system identity.
>>>>>> 
>>>>>> If there's no instance of the sending RID system's identity
>>>>>> in the RID message, then I suppose the client identity
>>>>>> verification would have to be based on the information
>>>>>> used to set up the trust relationships in the consortium.
>>>>>> The 6046-bis draft already has a reference to the PKI
>>>>>> discussion in 6045-bis. Would it make sense to clarify
>>>>>> 6046-bis to indicate that RFC 6125 Section 6 applies only
>>>>>> to server identity verification and the PKI material in
>>>>>> 6045-bis applies to both server and client identity 
>>>>>> verification?
>>>>>> 
>>>>>> Thanks, --David
>>>>>> 
>>>>>>> Thank you for the comments.  If text is added, it will
>>>>>>> need to be specific to the instance of Node
>>>>> in
>>>>>>> RID or IODEF.  This would mean the CN would be used for
>>>>>>> this purpose (if UTF-8 names are OKed for
>>>>> use
>>>>>>> in RID NodeNames with the internationalization
>>>>>>> discussions).  RID uses Node in two places and it
>>>>> may
>>>>>>> 2) Node in RID RIDPolicy is tied to MsgDestination and
>>>>>>> would be the receiving Node or the suspected source of an
>>>>>>> incident if a traceback were in play.
>>>>>>> 
>>>>>>> 3) This means the connection would need to be to the
>>>>>>> IODEF document and would require the document
>>>>> to
>>>>>>> be decrypted to verify if this were necessary.  Or adding
>>>>>>> a Node instance specific to the sending
>>>>> host
>>>>>>> information.
>>>>>>> 
>>>>>>> 4) If it were tied to IODEF, the use of Node in the
>>>>>>> System class is specific to the source and destination
>>>>>>> addresses involved in an attack. The EventData where 
>>>>>>> contact category is set to "infrastructure" is the place
>>>>>>> where systems involved in communicating IODEF documents
>>>>>>> are listed. This is the path information for incident
>>>>>>> data (lists all of the 'from' systems in RID 
>>>>>>> communications).
>>>>>>> 
>>>>>>> [email-masked] Sent: Wednesday, January 25, 2012
>>>>>>> 12:39 PM To: [email-masked] Subject: [mile] 6046-bis -
>>>>>>> Client certificate identity check
>>>>>>> 
>>>>>>> Brian and Kathleen,
>>>>>>> 
>>>>>>> I think I found something in looking at the text related
>>>>>>> to the question about certificate identities, but some
>>>>>>> more input would be useful.
>>>>>>> 
>>>>>>> RID systems MUST verify the identity of their peers
>>>>>>> against that stored in the certificate presented, as in
>>>>>>> section 6 of [RFC6125].
>>>>>>> 
>>>>>>> match host component of URI for HTTP), but I don't think
>>>>>>> it covers verification of the identity of the sending
>>>>>>> system, as Section 6 of RFC 6125 concerns only service
>>>>>>> identity.
>>>>>>> 
>>>>>>> I'd suggest adding some text that requires that the
>>>>>>> identity of the sending system in the TLS client
>>>>>>> certificate match the NodeName in the Node element of the
>>>>>>> RIDPolicy class if the NodeName is present. That "is 
>>>>>>> present" complication is courtesy of 6045-bis reusing the
>>>>>>> IODEF Node class from RFC 5070, because RFC 5070 does not
>>>>>>> require that NodeName be present.
>>>>>>> 
>>>>>>> I'm not sure what to do if NodeName is absent - a
>>>>>>> possible approach would be to not go there, and instead
>>>>>>> add a requirement to 6045-bis that NodeName MUST be 
>>>>>>> present in the Node element of the RIDPolicy class in
>>>>>>> order to facilitate this identity check.
>>>>>>> 
>>>>>>> David L. Black, Distinguished Engineer EMC Corporation,
>>>>>>> 176 South St., Hopkinton, MA  01748 +1 (508) 293-7953
>>>>>>> FAX: +1 (508) 293-7786 [email-masked]        Mobile:
>>>>>>> +1 (978) 394-7754 
>>>>>>> _______________________________________________ mile
>>>>>>> mailing list [email-masked] 
>>>>>> _______________________________________________ mile
>>>>>> mailing list [email-masked]

---

From: <[email-masked]>
Date: Thu, 26 Jan 2012 15:51:55 -0500

> How would you derive a domain name for the connecting entry (what I
> called "client")? The server only has an IP address and port. So other
> than doing reverse DNS mapping or similar, I don't think anything will
> result in a domain.

The HTTP/TLS client can check the server's certificate against the domain
in the URL, and I read RFC 6125 as requiring this check.  The HTTP/TLS
server needs to do something else.

The current -09 version of 6046-bis requires that sufficient domain name
information be kept based on consortium setup so that both the HTTP/TLS
client and server can both perform a domain name reference identifier
check against the TLS certificate presented by the other party:

   The use of stable DNS names to address RID systems is RECOMMENDED; in
   addition to facilitating connection to RID systems within a
   consortium, these are to be used as reference identifiers for a RID
   system's peers.  [... unrelated sentence snipped ...]
   The protocol provides no in-band method for handling a
   change of address of a RID system.

...

   All RID systems MUST be identified by a certificate containing a
   DNS-ID identifier [RFC5280] as in section 6.4 of [RFC6125]; RID
   systems MUST verify the reference identifiers of their peers against
   those stored in the certificates presented.

Thanks,
--David

> Sent: Thursday, January 26, 2012 3:25 PM
> To: Peter Saint-Andre
> On 26/01/2012 19:34, Peter Saint-Andre wrote:
> A server connecting to another is acting as a client, but never mind ;-).
> Agreed.
> How would you derive a domain name for the connecting entry (what I
> called "client")? The server only has an IP address and port. So other
> than doing reverse DNS mapping or similar, I don't think anything will
> result in a domain.
> >>>>> validation on

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 26 Jan 2012 20:24:35 +0000

Agreed.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 26 Jan 2012 16:13:27 -0700

> server needs to do something else.

Right, the identities need to be checked in both directions. That's why
I likened it to the server-to-server case in SMTP or XMPP.

>    those stored in the certificates presented.

Looks good to me.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: <[email-masked]>
Date: Fri, 27 Jan 2012 09:50:25 -0500

Alexey,

It appears your questions for RFC6046-bis have been addressed, can you confirm?

Thank you,
Kathleen (as Chair)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Thursday, January 26, 2012 6:13 PM
To: Black, David
Cc: [email-masked]; [email-masked]
Subject: Re: [mile] 6046-bis - Client certificate identity check

Looks good to me.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: <[email-masked]>
Date: Fri, 27 Jan 2012 16:23:29 -0500

Thank you.  Can we handle this in Auth48 and progress this document?

Yes, the discussions have been very good!

Thanks,
Kathleen

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Friday, January 27, 2012 4:21 PM
To: Moriarty, Kathleen
Cc: [email-masked]; [email-masked]
Subject: Re: [mile] 6046-bis - Client certificate identity check

Hi Kathleen,
> It appears your questions for RFC6046-bis have been addressed, can you confirm?
draft-ietf-mile-rfc6046-bis-09 looks good to me. One thing that can be 
improved is to say that the server that accepts a TCP connection would 
use reverse DNS lookup to retrieve the identity of the connecting 
server. "Stable DNS identity" doesn't quite say that to me.

Best Regards,
Alexey

P.S. This discussion was very productive and enjoyable. Thank you to all 
parties involved!

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 27 Jan 2012 14:24:09 -0700

> server. "Stable DNS identity" doesn't quite say that to me.

I think that's a good improvement.

> P.S. This discussion was very productive and enjoyable. Thank you to all

Hear, hear!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 27 Jan 2012 21:20:59 +0000

Hi Kathleen,

Best Regards,
Alexey

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 27 Jan 2012 14:27:08 -0700

> Thank you.  Can we handle this in Auth48 and progress this document?

It's up to your responsible AD, but I think that would be fine.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Sean Turner <[email-masked]>
Date: Fri, 27 Jan 2012 16:36:02 -0500

> It's up to your responsible AD, but I think that would be fine.

I think we can handle this during AUTH48.

spt

---

From: <[email-masked]>
Date: Fri, 27 Jan 2012 16:45:27 -0500

Thank you, that closes out all open issues for RFC6046-bis.

Kathleen

-----Original Message-----
From: Sean Turner [mailto:[email-masked]] 
Sent: Friday, January 27, 2012 4:36 PM
To: Moriarty, Kathleen
Cc: Peter Saint-Andre; [email-masked]; [email-masked]
Subject: Re: [mile] 6046-bis - Client certificate identity check

spt

---

From: SM <[email-masked]>
Date: Fri, 27 Jan 2012 22:14:29 -0800

At 13:20 27-01-2012, Alexey Melnikov wrote:
>draft-ietf-mile-rfc6046-bis-09 looks good to me. One thing that can 
>be improved is to say that the server that accepts a TCP connection 
>would use reverse DNS lookup to retrieve the identity of the 
>connecting server. "Stable DNS identity" doesn't quite say that to me.

DNS PTR is not that good as an identifier for security checks.  These 
DNS records are not always well-maintained.  There was a network in 
the Far East where the reverse DNS lookup was pointing to "localhost 
(this was not for .0.0.127.in-addr.arpa).

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 27 Jan 2012 22:28:09 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Friday, January 27, 2012 10:14 PM
> To: [email-masked]
> DNS records are not always well-maintained.  There was a network in the
> Far East where the reverse DNS lookup was pointing to "localhost (this
> was not for .0.0.127.in-addr.arpa).

The dnsop WG had a draft some time ago, which they keep promising/threatening to resurrect, that is basically a BCP against that practice.

---

From: SM <[email-masked]>
Date: Fri, 27 Jan 2012 22:44:33 -0800

At 22:28 27-01-2012, Murray S. Kucherawy wrote:
>The dnsop WG had a draft some time ago, which they keep 
>promising/threatening to resurrect, that is basically a BCP against 
>that practice.

I cannot recall whether it was that document or some RFC which has 
some material about the topic.

BTW, there is a performance impact if the feature is enabled in a 
well-known web server implementation.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 27 Jan 2012 23:22:10 -0800

> Sent: Friday, January 27, 2012 10:45 PM
> To: [email-masked]
> I cannot recall whether it was that document or some RFC which has some
> material about the topic.

You might be thinking about RFC5451, which did reference the dnsop draft.

-MSK

---

From: <[email-masked]>
Date: Sat, 28 Jan 2012 13:02:23 -0500

I think we are good on this issue as going with a white list tied to the sharing profile for a peer or group (a cert for each peer in the group) is really how the authentication will work.  It is not that burdensome to maintain white lists for communities that go through legal processes to compare policies and determine sharing arrangements in formal agreements to set up a profile and tie certificates in a white list to the appropriate profile.  They will be worried about how markers trigger security protections for specific profiles as well (even whether or not some data will get shared or who it can be shared with).  The DNS-ID is not where the authentication really happens, this wouldn't match the security requirements for these systems.

Brian proposed text to the document in Auth48, white list is the best option to provide the security level needed for these highly sensitive systems.

Thanks for the comments.  

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Saturday, January 28, 2012 2:22 AM
To: [email-masked]
Subject: Re: [mile] 6046-bis - Client certificate identity check

-MSK