gmane.ietf.saag

Fwd: I-D Action: draft-saintandre-username-interop-00.txt

Sean Turner — 2013-05-09T09:33:04

Some on this list might find this of interest.

spt

-------- Original Message --------
Subject: I-D Action: draft-saintandre-username-interop-00.txt
Date: Wed, 08 May 2013 20:52:20 -0700
From: internet-drafts< at >ietf.org
Reply-To: internet-drafts< at >ietf.org
To: i-d-announce< at >ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


Title           : Username Interoperability
Author(s)       : Peter Saint-Andre
Filename        : draft-saintandre-username-interop-00.txt
Pages           : 9
Date            : 2013-05-08

Abstract:
    Various Internet protocols have defined constructs for usernames.
    This document describes a subset of characters to allow in usernames
    for maximal interoperability across Internet protocols.  The subset
    might prove useful in cases where a provider offers multiple services
    using the same underlying identifier.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-saintandre-username-interop

T

Fwd: Just Announced: New NIST Security Controls Document - SP 800-53 Rev 4 Training

Stephen Farrell — 2013-05-07T14:39:56

FYI

-------- Original Message --------
Subject: Just Announced:  New NIST Security Controls Document - SP
800-53 Rev 4 Training
Date: Tue, 07 May 2013 08:34:28 -0600
From: NIST Security Controls SP 800-53 Rev 4 Workshop
<Training< at >NIST800-53Rev4.potomacforum.org>
To: <stephen.farrell< at >cs.tcd.ie>

 Just Released NIST SP 800-53 Rev 4 (FINAL) Security Controls Document -
Released on April 30th. NIST Keynote and Featured Presentation. Workshop
will Present a Detailed Analysis of the Document-  Please Forward To
Your Associates - CIO, Security, IG, CFO, Program Managers & Staff,
Industry Interested in IT Security - Government & Industry -

New NIST Security Controls Publication
SP 800-53 Revision 4
(April 30, 2013)

http://www.potomacforum.org

http://www.potomacforum.org
Security and Privacy Controls
for Federal Information Systems and Organizations
Training Workshop

Gov Security Controls:
What is New
What Has Changed
How Does Rev 4 Effect Government Security Programs

Government and Industry Invited to Atte

Fwd: [AVTCORE] I-D Action:draft-ietf-avtcore-rtp-security-options-03.txt

Magnus Westerlund — 2013-05-06T09:57:08

Security People,

AVTCORE WG are developing an overview document over available security
options for RTP. As several of these comes from various corners of the
security area as well as some being developed in AVT WG. I am thus
requesting review of this document.

Or maybe you want to be astonished of the flora of things you have
produced that can be applied to securing a protocol like RTP in its
various usages.

Thanks

Magnus Westerlund

Biggest Fake Conference in Computer Science

2013-04-27T18:03:04

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit t

BoF dates for Berlin IETF

Stephen Farrell — 2013-04-23T20:33:13

Hiya,

If someone is interested in a security related BoF in Berlin
you probably need to be talking to Sean or me real soon now.

The dates are:

• 2013-06-17 (Monday): Cutoff date for BOF proposal requests to Area
Directors at UTC 24:00. To request a BOF, please see instructions on
Requesting a BOF.
• 2013-06-20 (Thursday): Cutoff date for Area Directors to approve BOFs
at UTC 24:00.

Cheers,
S.

Requesting review of AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)

Magnus Westerlund — 2013-04-18T13:37:54

Hi,

The AVTCORE WG has developed this application of AES-GCM and AES-CCM as
cipher suit for SRTP. I would really appreciate if some more security
knowledgeable would take a look at it before we request publication. If
they have any understanding of SRTP it would be a big plus.

https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/

Thanks

Magnus Westerlund
AVTCORE WG chair

SSH user key management - new draft and mailing list

Tatu Ylonen — 2013-04-06T13:45:12

A new draft "SSH Key Management for Automated Access - Current Recommended Practice" is now available at https://tools.ietf.org/html/draft-ylonen-sshkeybcp-01

The draft is relevant for anyone interested in SSH user key management and more generally identity and access management.  We have found hundreds of thousands to millions of SSH authorized keys from the IT environments of many large enterprises (many times more than they have interactive users), and bringing key-based access under control is very important.  The draft outlines the risks with unmanaged key-based access and presents a process for remediating the situation in an existing environment and implanting an ongoing process for monitoring and managing key-based access (and other automated passwordless access).

I am hoping the draft will evolve into a BCP (Best Current Practice) standard on managing SSH user keys in organizations.  The draft is mostly about process and policy, not technical protocols, as SSH user key management is really an iden

Fwd: Fwd: Choosing a header compression algorithm

Stephen Farrell — 2013-03-30T11:39:40

The httpbis wg are trying to figure out how to
do compression in HTTP/2.0 in a way that's not
so vulnerable to the CRIME attack.

They'd like additional security eyeballs on what
is quite a tricky problem.

If you're willing and able to help then that'd be
best done on the httpbis wg list.

Any other questions feel free to ask me or Mark
(httpbis wg chair, cc'd) offlist.

S.


-------- Original Message --------
Subject: Fwd: Choosing a header compression algorithm
Date: Sat, 30 Mar 2013 16:50:32 +1100
From: Mark Nottingham <mnot< at >mnot.net>
To: Stephen Farrell <stephen.farrell< at >cs.tcd.ie>, Sean Turner
<turners< at >ieca.com>

Any input from Security would be most welcome here…

Cheers,

Begin forwarded message:


--
Mark Nottingham   http://www.mnot.net/

Re: security consideration of CGA and SSAS - I-D action :draft-rafiee-6man-ssas

Steven Bellovin — 2013-03-26T18:04:36

On Mar 25, 2013, at 12:02 PM, Bob Hinden <bob.hinden< at >gmail.com> wrote:

See, for example, http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/


--Steve Bellovin, https://www.cs.columbia.edu/~smb

FW: New Version Notification fordraft-moriarty-pkcs12v1-1-01.txt

Moriarty, Kathleen — 2013-03-25T18:36:11

Hello,

I believe the attached version addresses all of the outstanding questions.  Please let me know if there are any further comments.  Once version 1.0 is published, then we can work on the more extensive changes in a revision.

Thank you,
Kathleen

-----Original Message-----
From: internet-drafts< at >ietf.org [mailto:internet-drafts< at >ietf.org] 
Sent: Monday, March 25, 2013 2:11 PM
To: Moriarty, Kathleen
Cc: mnystrom< at >microsoft.com; Parkinson, Sean; Rusch, Andreas; Scott, Michael2
Subject: New Version Notification for draft-moriarty-pkcs12v1-1-01.txt


A new version of I-D, draft-moriarty-pkcs12v1-1-01.txt
has been successfully submitted by Kathleen M. Moriarty and posted to the
IETF repository.

Filename: draft-moriarty-pkcs12v1-1
Revision: 01
Title: PKCS 12 v1: Personal Information Exchange Syntax
Creation date: 2013-03-25
Group: Individual Submission
Number of pages: 29
URL:             http://www.ietf.org/internet-drafts/draft-moriarty-pkcs12v1-1-01.txt
Status:          http://datatracker.ietf.org/d

Re: security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas

Ray Hunter — 2013-03-25T06:35:04

Because as processors get faster, the relative amount of work remains
constant at 2^59, but the absolute amount of processing time per
operation decreases for both attacker and defender. So the absolute
amount of time required to mount a successful attack also decreases over
the long term.

At some point, the absolute amount of time required to mount an attack
will eventually be comparable to the amount of time an address is in
use, which makes attacks attractive.

Eventually you either have to reduce the time the CGA address remains in
use, or make the algorithm more complex for both attacker and defender
[add sec]. c.f. DES -> triple DES.

_______________________________________________
saag mailing list
saag< at >ietf.org
https://www.ietf.org/mailman/listinfo/saag

Re: security consideration of CGA and SSAS - I-D action :draft-rafiee-6man-ssas

Christian Huitema — 2013-03-25T04:33:40

2^59 is a rather large number. Everything else being equal, another 1 second of computation at the user translates into another 18 billion years at the attacker.

Re: security consideration of CGA and SSAS - Ii-D action :draft-rafiee-6man-ssas

Francis Dupont — 2013-03-23T12:26:25

I have a simpler solution (assuming to-be-matched bits are high order,
if they are not 2 must be replaced by 2**k)
 - pick one prime number
 - divide the modulus to get the second prime number range
 - for all odd numbers in the range (fast) check it is prime
Note the standard RSA generation is:
 - pick a bunch of random bits of the wanted size
 - fast checks it is prime, if it is not retry, if it is got a prime
Apply this twice to get the 2 primes, compute the modulus, private
exponent and CRT coefficients with a (given too) public exponent.

So I argue it is not significantly more expensive to break a SSAS (*)
than to generate a new RSA key pair.

Regards

Francis.Dupont< at >fdupont.fr

PS (*): the solved problem is to find a valid RSA key pair which
shares N contiguous bits of the modulus, N << size(modulus)
(verified for any SSAS like as 64 << 1024.
PPS: Christian's argument applies for ECDSA (I expect ECDSA will
replace by RSA in the SSAS proposal if it is not simply
withdrawn) so if nobody has a quicker wa

Re: IETF-86 draft saag minutes

Stephen Farrell — 2013-03-23T00:59:11

Oops. Thanks.
S

On 03/23/2013 12:38 AM, Yoav Nir wrote:

Re: IETF-86 draft saag minutes

Yoav Nir — 2013-03-23T00:38:01

[1] http://www.ietf.org/proceedings/86/minutes/minutes-86-saag

On Mar 22, 2013, at 2:23 PM, Stephen Farrell <stephen.farrell< at >cs.tcd.ie> wrote:

IETF-86 draft saag minutes

Stephen Farrell — 2013-03-22T18:23:18

Hi All,

Thanks to Tero for taking notes. Draft minutes are at [1]
Please send any corrections needed,

Cheers,
Stephen.

Re: security consideration of CGA and SSAS - Ii-D action :draft-rafiee-6man-ssas

Hosnieh Rafiee — 2013-03-22T17:23:42

I want to table this discussion until I have the opportunity to code and
implement software that will prove what it is that I am trying justify. I
have just arrived home from the USA and Sunday I leave for another weeks'
conference. Once I return from that conference I will have the opportunity
to prove my case. 
I want to thank everyone for their contributions on this topic and I hope
that you will bear with me and we can resume after I know something
definite. 
Thanks again,
Hosnieh

Re: security consideration of CGA and SSAS - I-D action :draft-rafiee-6man-ssas

Hosnieh Rafiee — 2013-03-22T12:45:44

Francis, 

=> I strongly disagree: the use of those SHAx steps is the way to extend the
search space and until SHAx pre-images are broken for the worst case (i.e.,
no attack better than brute force).


Be patient please. It takes time to prepare a response because I will need
to work on code to break RSA and also SHAx (CGA) and currently I have no
opportunity to work on this.


=> this seems to be replay attacks. RFC 3972 (CGAs) doesn't protect against
replay but provides message (aka connectionless) integrity so any use of
CGAs can add an anti-replay device (RFC 3971 (SEND) uses nonces and
timestamps for anti-replay). BTW CGAs and SSASs are the same for this point.

Nonce and timestamp both cannot be much helpful for relay attacks. I
mentioned a fast replay attack. You need to consider the clock skew for
timestamp (two seconds or so). The other nodes do not know the nonce is for
an attacker or for your node. I, as an attacker, can easily copy and paste
the whole packet content in my message with my own link

Re: security consideration of CGA and SSAS - I-D action :draft-rafiee-6man-ssas

Francis Dupont — 2013-03-22T09:26:54


=> this is IMHO a bad idea because it limits the search space in the
best case (i.e., not when the structure of the public key allows
trivial attacks as in the RSA case) to 2**64.


=> I strongly disagree: the use of those SHAx steps is the way to extend
the search space and until SHAx pre-images are broken for the worst case
(i.e., no attack better than brute force).


=> this seems to be replay attacks. RFC 3972 (CGAs) doesn't protect against
replay but provides message (aka connectionless) integrity so any use
of CGAs can add an anti-replay device (RFC 3971 (SEND) uses nonces and
timestamps for anti-replay). BTW CGAs and SSASs are the same for this
point.

Regards

Francis.Dupont< at >fdupont.fr

PS: I don't say to put the public key in the address is intrinsically
broken but it cannot be done this way. I suggest to look at Identity
Based Cryptography (the SAAG could provide guidance).

Re: security consideration of CGA and SSAS - I-D action:draft-rafiee-6man-ssas

Hosnieh Rafiee — 2013-03-21T23:08:02

Jari,


The difference between my draft and that of RFC 3972 is that I make use of
the public key in the IP address directly. Doing it the way I have explained
in my draft eliminates the need for the use of those SHAx steps  because I
believe the use of those steps does not lend itself to improved security. My
reason for this opinion is that RFC 3972 can only prevent DAD attacks and
not the other types of attacks. This attack can also be prevented by using
CGA if we add this extra verification step (that of the node checking the
public key of the sender to his own), otherwise RPKI would be used. This is
the same procedure as outlined in my draft. So the security of both depends
on the security of the public/ private keys. After a successful verification
(which could have resulted from a fast relay attack) the attacker's
link-layer address is included in a cache as a legitimate address, and if
routing is based on the link-layer address,  then the node has no way of
knowing that it was just a replay attack. Ot

Re: security consideration of CGA and SSAS - Ii-D action:draft-rafiee-6man-ssas

Jari Arkko — 2013-03-21T20:19:20

Is there a conclusion of this thread? My read of it is that no amount of tweaking how you calculate the IID help the fact that in 59/62 bits you have a limited space to search. The Sec scheme does help, but increases costs equally for both attackers and defenders. 

FWIW, I'm struggling to understand the draft. But I couldn't make it to the meeting.

Jari