headers
Stephen Kent | 1 Mar 2007 02:27
Picon

Re: NIST profiles for IPv6 (including IPsec)

At 10:10 PM -0500 2/27/07, Thomas Narten wrote:
>Dunno if folk here have looked at these, but NIST has issued draft
>profiles for IPv6 and IPsec:
>
>	 http://www.antd.nist.gov/usgv6-v1-comments.html
>
>These profiles are likely to have a siginificant impact on what
>vendors do and what USG buys.
>
>Have folk looked at the IPsec recommendations and do you think they
>are reasonable? (Comments are due this Friday.)
>
>One thing I note is that AH is optional rather than mandatory, with
>ESP and NULL encryption used for authentication where needed. Is that
>they way the market has gone at this point?

I don't know about what current products offer, but 4301 says that 
support for AH is optional, and for a long time we have suggested 
using ESP with NULL encryption in lieu of AH.

Steve
Permalink | Reply | 0 comments |
headers
Thomas Otto | 1 Mar 2007 13:10

Thesis "Extensible Network Access Authentication"

Hi all,

I would like to give a pointer to my recent announcment in EMU
Working Group. There, you can find a download link for my diploma
thesis about Extensible Network Access Authentication
(which is with 180 pages quite extensive ;-))

The URL is

http://www1.ietf.org/mail-archive/web/emu/current/msg00380.html

Thomas

(PS. If you think other IETF mailing lists might be more suitable for
this announcement, I'd be glad if you forward it there. Thanks!

If you want directly to me, my email is t.otto <at> tu-bs.de )
Permalink | Reply | 0 comments |
headers
RJ Atkinson | 2 Mar 2007 17:42
Favicon

Re: NIST profiles for IPv6 (including IPsec)


	It is important to differentiate between two different
deployment segments in this discussion, IMHO.

	In the specific context of VPNs, and the VPN implementers
have dominated the IPsec WG for some years now, AH is not very
popular.  (The reasons don't really matter in this thread,
so please lets not rat hole in that discussion.)

	In the broader context of IPv6 (i.e. outside of VPNs),
implementation of AH remains important.  AH and "ESP with Null
Encryption" provide different security properties.  For VPNs,
those differences might or might not matter (opinons vary and,
separately, deployment circumstances also vary).  For other uses,
that is not including VPNs, the differences in security properties
can matter a great deal.

	To pick one example, ESP with Null encryption can't protect
some routing protocols (e.g. PIM) because ESP cannot authenticate
IP-layer options (which are used/needed by the routing protocol).
I am told that this is why AH is the IETF standard approach to
PIM routing protocol authentication, though I'm far from a PIM expert.
For some other routing protocols, for example OSPFv3, AH is also
the standard authentication approach.  There is significant and
growing interest within the router implementer community in using
AH to protect IPv4 interior routing protocols -- and in the abstract
AH is probably a better approach than the sundry other mechanisms
we have for RIPv2 or OSPFv2.[1]  (I/IS-IS uses the link-layer,
not IP, so neither AH nor ESP are applicable to I/IS-IS.)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Doug Montgomery | 2 Mar 2007 18:12
Favicon

Re: NIST profiles for IPv6 (including IPsec)


RJ Atkinson wrote:
> 	Ideally, folks who write IPv6 feature profiles will sort
> through these dependencies and make all these requirements explicit,
> although that can be a lot of additional effort to build the total
> specification dependency graph.  So, implementers might want
> to consider that some authors of such profiles might not document
> things in such an explicit manner and some implicit requirements
> might also exist.
>   
We tried, .... it is a lot of effort, and can be quite an *interesting*
exercise with some IETF specs.

We are aware that we need to reconcile the "S+" for OSPF-AUTH (RFC 4552)
vs for "O" for AH in routers.  For this version that is not technically
in conflict, but the issue might be better documented and going forward
might need to be revisited.

Other than that, we solicit comments
(http://www.antd.nist.gov/usgv6-v1-comments.html) on other requirements
(explicit or implicit) that you feel should be clarified in the profile.  

thanks
dougm
Permalink | Reply | 0 comments |
headers
Stephen Farrell | 5 Mar 2007 11:06
Picon
Picon

W3C work on web security context ...


There's a new-ish W3C security group [1] who're trying
to figure out what might be better that a lock icon in
a browser, or, more generally, how to better present
security context information to "web" users.

The group's 1st public document is out now [2] and
feedback is welcome (there's an address for that in
the doc itself).

Cheers,
S.

[1] http://www.w3.org/2006/WSC/
[2] http://www.w3.org/TR/wsc-usecases/
Permalink | Reply | 0 comments |
headers
Narayanan, Vidya | 15 Mar 2007 09:36

IP Mobility Threat Analysis and Security Requirements - Request for Review and Comments

All,
The IETF has been involved with developing a suite of IP mobility
protocols to handle global and local mobility of nodes. Most of these
protocols are based on tunneling packets meant for one, relatively
stable, IP address to another, relatively transient, IP address that
identifies the topologically correct location of the node. Examples of
this class of protocols include the Mobile IP suite of protocols such as
Mobile IPv4, Mobile IPv6, Fast MIP4/6, Hierarchical MIP6, Proxy MIP4/6,
Regional registration for MIP4, other network-based mobility protocols,
network mobility (NEMOv4/6), etc. MOBIKE also shares some of the similar
properties. 

Security solutions for some of these protocols have been proposed and
for some other protocols, solutions are currently under development.
While some of these protocols have done their own, independent threat
analysis, some others have not. Consequently, there is not a good common
understanding of the threat model or security requirements needed in a
particular solution. 

draft-vidya-ip-mobility-threats-00 and
draft-vidya-ip-mobility-sec-reqs-00 attempt to provide such a threat
analysis and set of security requirements for IP mobility protocols.
Reviews and comments are greatly appreciated.  

Regards,
Vidya
Permalink | Reply | 0 comments |
headers
Narayanan, Vidya | 15 Mar 2007 10:01

Security Analysis of RFC4285

All,
A couple of years ago, the MIP6 WG decided to specify an alternate
security mechanism for Mobile IPv6, following the model used for Mobile
IPv4. While such a document was published (RFC4285), it was published
with a lot of resistance from a security perspective. Eventually, the
IESG put a note on the document, pretty much to the effect that the
document has not gone through any security reviews. However, there is no
documented reason for the IESG note and the note often goes unnoticed
and gets dismissed when mentioned and consequently, this protocol
continues to be proposed and used in various deployments. 

I wrote a draft
(http://www.ietf.org/internet-drafts/draft-vidya-rfc4285-security-analys
is-00.txt) explaining the security issues with RFC4285. Russ suggested I
get a review from SAAG on the document to see if people think this is
worth publishing. I'd appreciate review and feedback. 

Thanks,
Vidya
Permalink | Reply | 0 comments |
headers
Tobias Gondrom | 21 Mar 2007 14:34
Picon
Favicon

LTANS meeting summary

Hi,

LTANS (Long Term Archive and Notary Services) held a short meeting in Prague, to review the status of the active working group documents.

The Requirements document passed IETF LC and will be released as informational RFC 4810. ERS is currently in IESG review.

The WG will now focus on LTAP and the XML representations of ERS and LTAP.

Work proceeds with ERS/SCVP and PKI Retention aiming to start WGLC in April.

The two drafts validate (related to preserving verification data) and ARI (architecture of LTA Services) will continue but require review/feedback. (Decision on whether these documents shall be continued as WG items is open at the moment.)

The meeting had presentations about LTAP (Long-term archive protocol), XMLERS (XML representation of ERS), VALIDATE (Verification Data) and a product implementation of ERS (by Fraunhofer).

There has been a short discussion about whether WG should use more “current” ASN.1 instead of 88-ASN.1 in their modules (and which one to make normative and which informative if both are provided). Argument to use 88-ASN.1 as normative at the moment, is that there is still no free ASN.1 compiler fully capable of 1997/2002-ASN.1. Counter argument is that there exists asn1c. AD pointed out that this compiler has been evaluated and still had some deficiencies. Last item on the agenda was to discuss about the usage of non-RFC3161 TS in ERS. (this item had to be deferred to the mailing-list as the WG ran out of time.)


More detailed meeting minutes has been uploaded to the Materials page.

Tobias

Chair of LTANS


__________________________________________
Tobias Gondrom
Head of Open Text Security Team

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom <at> opentext.com
Internet: http://www.opentext.com/ 

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:  DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton

This email is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This email may only be lawfully received, accessed, displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above ("Authorized Recipient") for the purpose for which it was sent by OTC. All other rights and licenses to this email are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this email in its entirety without printing, copying, using, and/or re-transmitting this email, either in whole or in part. The transmission of this email by OTC is not to be construed as a waiver by OTC and/or the individual sending this email on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising.

<div>

<p align="LEFT"><span lang="en-gb">Hi,</span></p>

<p align="LEFT"><span lang="en-gb">LTANS</span><span lang="de"></span><span lang="de"></span><span lang="en-gb"> (Long Term Archive and Notary Services)</span><span lang="de"></span><span lang="de"></span><span lang="en-gb"> held a short meeting</span><span lang="de"></span><span lang="de"></span><span lang="en-gb"> in Prague,</span><span lang="de"></span><span lang="de"></span><span lang="en-gb"> to review the status of the active working group documents.</span></p>

<p align="LEFT"><span lang="en-gb">The Requirements document passed IETF LC and will be released as informational RFC 4810. ERS is currently in IESG review. </span></p>

<p align="LEFT"><span lang="en-gb">The WG will now focus on LTAP and the XML representations of ERS and LTAP. </span></p>

<p align="LEFT"><span lang="en-gb">Work proceeds with ERS/SCVP and PKI Retention aiming to start WGLC in April. </span></p>

<p align="LEFT"><span lang="en-gb">The two drafts validate (related to preserving verification data) and ARI (architecture of LTA Services) will continue but require review/feedback. (Decision on whether these documents shall be continued as WG items is open at the moment.)</span></p>

<p align="LEFT"><span lang="en-gb">The meeting had presentations about LTAP (Long-term archive protocol), XMLERS (XML representation of ERS), VALIDATE (Verification Data) and a product implementation of ERS (by Fraunhofer). </span></p>

<p align="LEFT"><span lang="en-gb">There has been a short discussion about whether WG should use more &ldquo;current&rdquo; ASN.1 instead of 88-ASN.1 in their modules (and which one to make normative and which informative if both are provided). Argument to use 88-ASN.1 as normative at the moment, is that there is still no free ASN.1 compiler fully capable of 1997/2002-ASN.1. Counter argument is that there exists asn1c. AD pointed out that this compiler has been evaluated and still had some deficiencies. Last item on the agenda was to discuss about the usage of non-RFC3161 TS in ERS. (this item had to be deferred to the mailing-list as the WG ran out of time.)</span><span lang="de"></span><span lang="de"></span><span lang="en-gb"></span></p>
<br><p align="LEFT"><span lang="en-gb">M</span><span lang="de"></span><span lang="de"></span><span lang="en-gb">ore detailed meeting minutes has been uploaded to the Materials page.</span></p>

<p align="LEFT"><span lang="en-gb">Tobias</span></p>

<p align="LEFT"><span lang="en-gb">Chair of LTANS</span><span lang="de"></span><span lang="de"></span><span lang="en-gb"></span></p>
<br><p align="LEFT"><span lang="de-de"></span><a name=""><span lang="de-de">__________________________________________</span></a><span lang="de"></span><span lang="de-de"><br></span><span lang="de"></span><span lang="de"></span><span lang="de-de">Tobias Gondrom</span><span lang="de"></span><span lang="de-de"><br></span><span lang="de"></span><span lang="de"></span><span lang="de-de">Head of Open Text Security Team<br></span><span lang="de"></span><span lang="de-de"><br></span><span lang="de"></span><span lang="de"></span><span lang="de-de">Open Text Corporation</span><span lang="de"></span><span lang="de-de"><br></span><span lang="de"></span><span lang="de-de">Technopark 2<br>
Werner-von-Siemens-Ring 20<br>
D-85630 Grasbrunn</span><span lang="de"></span><span lang="de-de"><br></span><span lang="de"></span><span lang="de"></span><span lang="de-de"></span></p>

<p align="LEFT"><span lang="de-de">Phone: +49 (0) 89 4629-1816<br>
Mobile: +49 (0) 173 5942987<br>
Telefax: +49 (0) 89 4629-33-1816<br>
eMail:</span><span lang="de"></span><span lang="de"></span><span lang="de-de"> <a href="mailto:tobias.gondrom <at> opentext.com">mailto:tobias.gondrom <at> opentext.com</a><br></span><span lang="de"></span><span lang="de"></span><span lang="de-de">Internet:</span><span lang="de"></span><span lang="de"></span><span lang="de-de"> <a href="http://www.opentext.com/">http://www.opentext.com/</a>&nbsp; </span></p>

<p align="LEFT"><span lang="de-de">Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:&nbsp; DE 114 169 819 | Managing Director / Gesch&auml;ftsf&uuml;hrer: John Shackleton</span></p>

<p align="LEFT"><span lang="de-de">This email is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This email may only be lawfully received, accessed, displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above ("Authorized Recipient") for the purpose for which it was sent by OTC. All other rights and licenses to this email are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this email in its entirety without printing, copying, using, and/or re-transmitting this email, either in whole or in part. The transmission of this email by OTC is not to be construed as a waiver by OTC and/or the individual sending this email on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising.</span></p>

<p align="LEFT"><span lang="en-gb"></span></p>

</div>
Permalink | Reply | 0 comments |
headers
Stephen Kent | 21 Mar 2007 15:30
Picon

PKIX WG Smmary

PKIX Meeting Summary

Major WG item actions:

      - Jim Schaad will revise his CMC documents based on IESG feedback, we will have a new Wg last call, and resend to the IESG.

     - The design team for the ECC algorithms draft will be reconstituted to try to develop a new solution, one that will not run afoul of Russ's objections.

        - Stefan will revise his SAN for Service Name I-D to address internationalization issues raised by he IESG. There is still an open issue re an "applicability statement" the needs to be resolved. In any case, we will need to conduct a WG last call, again.


Other WG actions of significance:

- the WG will track progress in he EAI WG, since we will likely need to change the SAN definition to accommodate this

   - Denis Pinkas will be asked to provide an outline and lent estimate for his proposed new document, an Informational RFC dealing with key rollover

      - We will work with Scott Lawrence et al. to help them develop a certificate profile for use with SIP
<div>
<div>PKIX Meeting Summary<br><br>
Major WG item actions:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Jim Schaad will revise
his CMC documents based on IESG feedback, we will have a new Wg last
call, and resend to the IESG.<br><br>&nbsp;&nbsp;&nbsp;&nbsp; - The design team for the ECC
algorithms draft will be reconstituted to try to develop a new
solution, one that will not run afoul of Russ's objections.<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Stefan
will revise his SAN for Service Name I-D to address
internationalization issues raised by he IESG. There is still an open
issue re an "applicability statement" the needs to be resolved. In
any case, we will need to conduct a WG last call, again.<br><br><br>
Other WG actions of significance:<br><br>- the WG will track progress in he EAI WG, since we
will likely need to change the SAN definition to accommodate this<br><br>&nbsp;&nbsp; - Denis Pinkas will be asked to provide an
outline and lent estimate for his proposed new document, an
Informational RFC dealing with key rollover<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - We will work with
Scott Lawrence et al. to help them develop a certificate profile for
use with SIP</div>
</div>
Permalink | Reply | 0 comments |
headers
Gregory M. Lebovitz | 21 Mar 2007 16:10
Picon

pki4ipsec - wg status

PKI4IPSEC did NOT meet here in Prague.

We have only two documents in all.

draft-ietf-pki4ipsec-ikecert-profile-12.txt -
 was in IESG review and is stuck on some DISCUSS issues that are being addressed by the author. When solution determined, doc will rev and be released as RFC. We will be sure to take the issue and discussion of it to list before moving on, as this is the appropriate process via PROTO.

Requirements for an IPsec Certificate Management Profile - RFC 4809   the cert mgmt protocol profile requirements document has moved to RFC.   does not how up on wg web page; ticket into secretariate to fix. As soon as ike-cert profile goes to RFC, wg will close. Gregory.
<div>
PKI4IPSEC did NOT meet here in Prague.<br><br>
We have only two documents in all.<br><br>
draft-ietf-pki4ipsec-ikecert-profile-12.txt - <br>
&nbsp;was in IESG review and is stuck on some DISCUSS issues that are
being addressed by the author. When solution determined, doc will rev and
be released as RFC. We will be sure to take the issue and discussion of
it to list before moving on, as this is the appropriate process via
PROTO.<br><br>Requirements for an IPsec Certificate Management Profile - RFC 4809
&nbsp; the cert mgmt protocol profile requirements document has moved to
RFC.
&nbsp; does not how up on wg web page; ticket into secretariate to fix.

As soon as ike-cert profile goes to RFC, wg will close.

Gregory.</div>
Permalink | Reply | 0 comments |

Gmane