From enis01amor at yahoo.fr Fri Mar 3 20:28:08 2006 From: enis01amor at yahoo.fr (chikh omar) Date: Tue May 2 17:43:48 2006 Subject: [Avispa-users] documentation Message-ID: <20060303192808.40159.qmail@web26002.mail.ukl.yahoo.com> hello can you give me documentation . How to specify a protocol in HLPSL I readed the tutorial and user-manual but it's not clear . Especially what i put in the environnement role(): in some exemple we make three session P,S and I,S and P,I P:peer S:server I:intruder and in some exemple we put only two session that are identical P,S and P,S thanks for help --------------------------------- Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international.T?l?chargez la version beta. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://carroll.ai.dist.unige.it/pipermail/avispa-users/attachments/20060303/23e1def5/attachment-0002.htm From paul.drielsma at inf.ethz.ch Mon Mar 6 11:59:40 2006 From: paul.drielsma at inf.ethz.ch (Paul Hankes Drielsma) Date: Tue May 2 17:43:49 2006 Subject: [Avispa-users] documentation In-Reply-To: <20060303192808.40159.qmail@web26002.mail.ukl.yahoo.com> References: <20060303192808.40159.qmail@web26002.mail.ukl.yahoo.com> Message-ID: Hello, What sorts of sessions you want depends on the protocol and what sorts of attacks you think the protocol might be vulnerable to. And also what sorts of assumptions you have on your protocol. For instance, in the example you list, the session P,I has the intruder playing the role of the server. Many protocols assume that the server is trusted and not compromised, so if we are working with this assumption then there is no need to analyze a session where the intruder plays the role of the server. (If you do, you may of course find attacks, but they may be trivial.) So if you have an authentication protocol between A and B which you want to analyze for vulnerability to Man-in-the-middle attacks, sessions between (A,B) (A,I) and (I,B) are good bets. Two identical sessions between (A,B) and (A,B) are useful to look for replay-style attacks. I realize this is a bit of a heuristic, but it can be useful to experiment with different analysis scenarios in order to give yourself greater confidence in your protocol. I hope this helps, Paul. On Mar 3, 2006, at 8:28 PM, chikh omar wrote: > hello > can you give me documentation . > How to specify a protocol in HLPSL > I readed the tutorial and user-manual but it's not clear . > Especially what i put in the environnement role(): in some exemple > we make three session P,S and I,S and P,I > P:peer > S:server > I:intruder > > and in some exemple we put only two session that are identical P,S > and P,S > > thanks for help > > > > Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez > les tarifs exceptionnels pour appeler la France et l'international. > T?l?chargez la version beta. > _______________________________________________ > Avispa-users mailing list > Avispa-users@avispa-project.org > http://www.avispa-project.org/mailman/listinfo/avispa-users From kremer at lsv.ens-cachan.fr Wed Mar 15 16:45:19 2006 From: kremer at lsv.ens-cachan.fr (Steve Kremer) Date: Tue May 2 17:43:49 2006 Subject: [Avispa-users] ARTIST2 Workshop on Security Specification and Verification of Embedded Systems Message-ID: <4418368F.3090706@lsv.ens-cachan.fr> *** Apologies for multiple copies *** Dear colleague, We wish to invite you to participate to the ARTIST-2 informal workshop on security of embedded systems. ARTIST-2 is a European Network of Excellence on Embedded Systems Design (http://www.artist-embedded.org/FP6/). The workshop will focus on the formal specification and verification of security properties, and in particular on the specification and formal verification of security protocols. Topics include, but are not limited to: * formal definition and verification of security properties * formal analysis and design of cryptographic protocols * modeling information flow * formal techniques for (mobile) code security; * security in real-time/probabilistic systems; * language-based security; * theory and application of policy languages and trust management One of the goals of the workshop is to bring together the part of the Artist2 community working on security, nevertheless, the workshop is open to anyone. The program of the workshop will include invited talks, regular talks and plenty of time for discussion. We expect to include both short (~10-20 minutes) and long (~40-50 minutes) talks. The workshop will take place at Pisa, Tuscany, Italy on May 18th and will be co-located with iTrust2006 (http://www.iit.cnr.it/iTrust2006/). If you are interested in giving a talk, please send an email before April 7 to artist2-sw@iit.cnr.it indicating a title, a short abstract (one or two paragraphs) and whether you intend to give a long or a short talk. The participation to the workshop is free but registration is mandatory. Updated information will be accessible at the workshop website: http://www.artist-embedded.org/FP6/ARTIST2Events/Events/Security-Pisa/ The organizing committee Bruno Bouyssounouse Sandro Etalle Steve Kremer Yassine Lakhnech Fabio Martinelli Marinella Petrocchi From mmannan at gmail.com Thu Mar 16 20:18:56 2006 From: mmannan at gmail.com (Mohammad Mannan) Date: Tue May 2 17:43:49 2006 Subject: [Avispa-users] password protocol and parameter passing Message-ID: <96f6d49f0603161118qb88c90fmf11ae580b387cef0@mail.gmail.com> Hi List -- 1. Could someone point to more AVISPA examples on password-based protocols (in addition to SRP, EKE, SPEKE available in the current distribution)? 2. What are the differences between a parameter declared in a "role" and inside a role as a "local" variable? Thanks for your time. -- Mohammad Mannan http://www.scs.carleton.ca/~mmannan From Laurent.Vigneron at Loria.Fr Tue Mar 21 09:24:24 2006 From: Laurent.Vigneron at Loria.Fr (Laurent Vigneron) Date: Tue May 2 17:43:49 2006 Subject: [Avispa-users] password protocol and parameter passing Message-ID: <17439.47160.116092.925462@valhey.loria.fr> Hi Mohammad, > 2. What are the differences between a parameter declared in a "role" > and inside a role as a "local" variable? This is exactly the same difference as between a parameter and a local variable in the declaration of a function: a parameter is an information comming from the outside; it is instantiated when the role is called; a local variable belongs only to the role where it is defined, and it may not have an initial value. Laurent. From enis01amor at yahoo.fr Thu Mar 30 10:39:17 2006 From: enis01amor at yahoo.fr (chikh omar) Date: Tue May 2 17:43:49 2006 Subject: [Avispa-users] arguments pour choisir AVISPA Message-ID: <20060330083917.8557.qmail@web26002.mail.ukl.yahoo.com> Bonjour, Quelles sont les arguments qui peut convaincre les validateurs de choisir AVISPA comme outils de validation formelle et non pas un autre outils comme CASPER ou EVA ...? y a t-il de documentation qui explique les arguments de choisir AVISPA. ? Cordialement Omar --------------------------------- Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international.T?l?chargez la version beta. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://carroll.ai.dist.unige.it/pipermail/avispa-users/attachments/20060330/27ea3664/attachment-0002.htm From zrelli at jaist.ac.jp Thu Mar 30 10:44:06 2006 From: zrelli at jaist.ac.jp (Saber Zrelli) Date: Tue May 2 17:43:49 2006 Subject: [Avispa-users] about 'secrecy' statement and Kerberos Message-ID: <20060330084406.GA10101@mlserv.jaist.ac.jp> Hi, In the user-manual (p.26 guidelines about secrecy goal specification) , it is said that "If a value T that should be kept secret is determined by a single role (in particular, if it is an atomic value like a nonce produced by new()), then the secrecy statement should be given in -- and only in -- the role introducing the value". In case of Kerberos, the TGS session key (the key that will be shared between a client and the TGS) is generated by the AS, hence the secrecy statement related to TGS sessoin should be present only on the AS role. However, in the example "Kerbers-basic" provided in the "The AVISPA Library of protocols" the secrecy statement of TGS session key is present in the AS, TGS and the client. So, I guess that one of the following is true : - I did not understood what is said in the HLPSL guidelines - There is a mistake in the HLPSL specification of Kerberos-basic I would appreciate any clarifications, Regards, Saber. From ug85bas at cs.bham.ac.uk Thu Mar 30 10:57:19 2006 From: ug85bas at cs.bham.ac.uk (Ben Smyth) Date: Tue May 2 17:43:49 2006 Subject: [Avispa-users] arguments pour choisir AVISPA In-Reply-To: <20060330083917.8557.qmail@web26002.mail.ukl.yahoo.com> References: <20060330083917.8557.qmail@web26002.mail.ukl.yahoo.com> Message-ID: <442B9D6F.2010309@cs.bham.ac.uk> Bonjour, My french is no good, so I will try to write in basic English. You need to use the best tool (program) for the job (task). I could not find anything about CASPER or EVA, do you have the web address? Here is my argument for using ProVerif in favour of AVISPA and CAPSL. My goals are: prove that a state is unreachable (secrecy) and demonstrate privacy using observational equivalence. I need to be able to define equations. (this is taken straight from my dissertation, so probably isn't basic english. Its in LaTeX format) CAPSL is unsuitable since it can only model authentication and key-exchange. Similarly AVISPA supports only authentication and secrecy. Although in theory it is possible to define one's own rules using AVISPA's Intermediate Format (IF) language~\cite{AVISPA03} - which would permit the modeling of further requirements - in reality such usage is unsupported\footnotemark. ProVerif permits the verification of privacy using observational equivalence. However, its ability is not complete and thus it is commonly necessary to complete a proof by hand. Although not perfect ProVerif is the only tool which meets the demands of the analysis. \footnotetext{Sebastian M\"{o}dersheim has since made claims that AVISPA's \emph{On-the-Fly Model-Checker} (OFMC) back-end is now capable (February, 2006) of handling user defined algebraic expressions. At the time of analysis support was classified as beta and it was therefore decided to utilise a tool which is known to provide the necessary functionality.} au revior, Ben chikh omar wrote: > Bonjour, > > Quelles sont les arguments qui peut convaincre les validateurs de choisir AVISPA comme outils de validation formelle et non pas un autre outils comme CASPER ou EVA ...? > > y a t-il de documentation qui explique les arguments de choisir AVISPA. ? > > Cordialement > Omar > > > --------------------------------- > Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international.T?l?chargez la version beta. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Avispa-users mailing list > Avispa-users@avispa-project.org > http://www.avispa-project.org/mailman/listinfo/avispa-users