draft-ietf-csi-hash-threat-03.txt   draft-ietf-csi-hash-threat-04.txt 
Network Working Group A. Kukec Network Working Group A. Kukec
Internet-Draft University of Zagreb Internet-Draft University of Zagreb
Intended status: Informational S. Krishnan Intended status: Informational S. Krishnan
Expires: September 10, 2009 Ericsson Expires: April 19, 2010 Ericsson
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
March 9, 2009 October 16, 2009
SeND Hash Threat Analysis SeND Hash Threat Analysis
draft-ietf-csi-hash-threat-03 draft-ietf-csi-hash-threat-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on April 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 17 skipping to change at page 2, line 17
This document analysis the use of hashes in SeND, possible threats This document analysis the use of hashes in SeND, possible threats
and the impact of recent attacks on hash functions used by SeND. and the impact of recent attacks on hash functions used by SeND.
Current SeND specification [rfc3971] uses the SHA-1 [sha-1] hash Current SeND specification [rfc3971] uses the SHA-1 [sha-1] hash
algorithm and PKIX certificates [rfc5280] and does not provide algorithm and PKIX certificates [rfc5280] and does not provide
support for the hash algorithm agility. The purpose of the document support for the hash algorithm agility. The purpose of the document
is to provide analysis of possible hash threats and to decide how to is to provide analysis of possible hash threats and to decide how to
encode the hash agility support in SeND. encode the hash agility support in SeND.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Impact of collision attacks on SeND . . . . . . . . . . . . . 6 3. Impact of collision attacks on SeND . . . . . . . . . . . . . 5
3.1. Attacks against CGAs in stateless autoconfiguration . . . 6 3.1. Attacks against CGAs in stateless autoconfiguration . . . 5
3.2. Attacks against PKIX certificates in ADD process . . . . . 7 3.2. Attacks against PKIX certificates in ADD process . . . . . 6
3.3. Attacks against the Digital Signature in the SEND 3.3. Attacks against the Digital Signature in the RSA
Universal Signature option . . . . . . . . . . . . . . . . 8 Signature option . . . . . . . . . . . . . . . . . . . . . 7
3.4. Attacks against the Key Hash in the SEND Universal 3.4. Attacks against the Key Hash field in the RSA
Signature option . . . . . . . . . . . . . . . . . . . . . 8 Signature option . . . . . . . . . . . . . . . . . . . . . 7
4. Support for the hash agility in SeND . . . . . . . . . . . . . 9 4. Support for the hash agility in SeND . . . . . . . . . . . . . 8
4.1. The negotiation approach for the SEND hash agility . . . . 9 4.1. The negotiation approach for the SEND hash agility . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
SEND [rfc3971] uses the SHA-1 hash algorithm to generate the contents SEND [rfc3971] uses the SHA-1 hash algorithm to generate the contents
of the Key Hash field and the Digital Signature field of the RSA of the Key Hash field and the Digital Signature field of the RSA
Signature option. It also uses a hash algorithm (SHA-1, MD5, etc.) Signature option. It also uses a hash algorithm (SHA-1, MD5, etc.)
in the PKIX certificates [rfc5280] used for the router authorization in the PKIX certificates [rfc5280] used for the router authorization
in the ADD process. Recently there have been demonstrated attacks in the ADD process. Recently there have been demonstrated attacks
against the collision free property of such hash functions against the collision free property of such hash functions
[sha1-coll], and attacks on the PKIX X.509 certificates that use the [sha1-coll], and attacks against the PKIX X.509 certificates that use
MD5 hash algorithm [x509-coll] This document analyzes the effects of the MD5 hash algorithm [x509-coll] This document analyzes the effects
those attacks and other possible hash attacks on the SEND protocol. of those attacks and other possible hash attacks on the SEND
The document proposes changes to make it resistant to such attacks. protocol. The document proposes changes to make it resistant to such
attacks.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [rfc2119]. document are to be interpreted as described in RFC 2119 [rfc2119].
3. Impact of collision attacks on SeND 3. Impact of collision attacks on SeND
Due to the hash attacks demonstrated on the aforesaid hash algorithms Due to the hash attacks demonstrated on the aforesaid hash algorithms
a study was performed to assess the threat of these attacks on the a study was performed to assess the threat of these attacks on the
cryptographic hash usage in internet protocols [RFC4270]. This cryptographic hash usage in internet protocols [rfc4270]. This
document analyzes the hash usage in SEND following the approach document analyzes the hash usage in SEND following the approach
recommended by [rfc4270] and [new-hashes]. recommended by [rfc4270] and [new-hashes].
The basic cryptographic properties of a hash function are that it is The basic cryptographic properties of a hash function are that it is
both one-way and collision free. There are two attacks against the both one-way and collision free. There are two attacks against the
one-way property, the first-preimage attack and the second-preimage one-way property, the first-preimage attack and the second-preimage
attack. In the first-preimage attack, given a knowledge of a attack. In the first-preimage attack, given a knowledge of a
particular value hash(m), an attacker finds an input message m' such particular value hash(m), an attacker finds an input message m' such
that hash(m') yields hash(m). The second-preimage attack deals with that hash(m') yields hash(m). The second-preimage attack deals with
the fixed messages. Given a knowledge of a fixed value m used as the the fixed messages. Given a knowledge of a fixed value m used as the
input message to the hash function, an attacker finds a different input message to the hash function, an attacker finds a different
value m' that yields hash(m)=hash(m'). Supposing that the hash value m' that yields hash(m)=hash(m'). Supposing that the hash
function produces an n-bit long output, since each output is equally function produces an n-bit long output, since each output is equally
likely, an attack takes an order of 2^n operations to be successful. likely, an attack takes an order of 2^n operations to be successful.
Due to the birthday attack, if the hash function is supplied with a Due to the birthday attack, if the hash function is supplied with a
random input, it returns one of the k equally-likely values, and the random input, it returns one of the k equally-likely values, and the
number of operations can be reduced to the number of 1.2*2^(n/2) number of operations can be reduced to the number of 1.2*2^(n/2)
operations. However, attacks against the one-way property are not operations. However, attacks against the one-way property are not
yet feasible [rfc4270]. Up to date, all demonstrated attacks are feasible yet [rfc4270]. Up to date, all demonstrated attacks are
attacks against a collision-free property, in which an attacker attacks against a collision-free property, in which an attacker
produces two different messages m and m' such that hash(m)=hash(m'). produces two different messages m and m' such that hash(m)=hash(m').
The rest of the document deals with the collision attacks.
We will analyze the impact of hash attacks on SeND case by case in We will analyze the impact of hash attacks on SeND case by case in
this section. Through our analysis, we also discuss whether we this section. Through our analysis, we also discuss whether we
should support the hash agility in SeND. should support the hash agility in SeND.
3.1. Attacks against CGAs in stateless autoconfiguration 3.1. Attacks against CGAs in stateless autoconfiguration
Hash functions are used in the stateless autoconfiguration process Hash functions are used in the stateless autoconfiguration process
that is based on CGAs. Impacts of collision attacks on current uses that is based on CGAs. Impacts of collision attacks on current uses
of CGAs are analyzed in the update of the CGA specification of CGAs are analyzed in the update of the CGA specification
skipping to change at page 7, line 16 skipping to change at page 6, line 17
CGA, the pre-image attack is potentially dangerous, but it is not yet CGA, the pre-image attack is potentially dangerous, but it is not yet
feasible. feasible.
3.2. Attacks against PKIX certificates in ADD process 3.2. Attacks against PKIX certificates in ADD process
The second use of hash functions is for the router authorization in The second use of hash functions is for the router authorization in
the ADD process. Router sends to a host a certification path, which the ADD process. Router sends to a host a certification path, which
is a path between a router and the hosts's trust anchor, consisting is a path between a router and the hosts's trust anchor, consisting
of PKIX certificates. Researchers demonstrated attacks against PKIX of PKIX certificates. Researchers demonstrated attacks against PKIX
certificates with MD5 signature, in 2005 [new-hashes] and in 2007 certificates with MD5 signature, in 2005 [new-hashes] and in 2007
[X509-COLL]. In 2005 were constructed the original and the false [x509-coll]. In 2005 were constructed the original and the false
certificate that had the same identity data and the same digital certificate that had the same identity data and the same digital
signature, but different public keys [new-hashes]. The problem for signature, but different public keys [new-hashes]. The problem for
the attacker is that two certificates with the same identity are not the attacker is that two certificates with the same identity are not
actually useful in real-world scenarios, because the Certification actually useful in real-world scenarios, because the Certification
Authority is not allowed to provide such two certificates. In Authority is not allowed to provide such two certificates. In
addition, attacks against the human-readable fields demand much more addition, attacks against the human-readable fields demand much more
effort than the attacks against non human-readable fields, such as a effort than the attacks against non human-readable fields, such as a
public key field. In case of the identity field, an attacker is public key field. In case of the identity field, an attacker is
faced with the problem of the prediction and the generation of the faced with the problem of the prediction and the generation of the
false but meaningful identity data, which at the end might be false but meaningful identity data, which at the end might be
skipping to change at page 8, line 10 skipping to change at page 7, line 11
only with certificates, attacks against certificates are even more only with certificates, attacks against certificates are even more
dangerous. Generally, the most dangerous are attacks against middle- dangerous. Generally, the most dangerous are attacks against middle-
certificates in the certification path, where for the cost of the one certificates in the certification path, where for the cost of the one
false certificate, an attacker launches an attack on multiple false certificate, an attacker launches an attack on multiple
routers. Regarding the attacks against certificates in SEND, the routers. Regarding the attacks against certificates in SEND, the
only attack that SEND is not suspectable to, is an attack against the only attack that SEND is not suspectable to, is an attack against the
Trust Anchor's certificate because it is not exchanged in SeND Trust Anchor's certificate because it is not exchanged in SeND
messages, i.e. it is not the part of the certification path in the messages, i.e. it is not the part of the certification path in the
ADD process. ADD process.
3.3. Attacks against the Digital Signature in the SEND Universal 3.3. Attacks against the Digital Signature in the RSA Signature option
Signature option
The SEND Universal Signature option is an updated version of the RSA The computation of the Digital Signature field is described in
Signature option, defined in [sig-agility]. In combination with the [rfc3971]. The digital signature in the RSA Signature option is
public key agility support described in [pk-agility], it allows the produced as the SHA-1 hash over the IPv6 addresses, the ICMPv6
node to use the public key signing algorithm different then the RSA- header, the ND message and other fields, e.g. the Message Type Tag
based signing algorithm. No matter of the type of the SEND Universal and ND options [rfc3971], that is signed with the sender's private
Signature option, the Digital Signature field is computed in the same key. The sender's private key corresponds to the public key in the
way as the Digital Signature field of the RSA Signature option CGA parameters structure. It is usually authorized through CGAs.
descibed in [rfc3971]. The digital signature in the RSA Signature Possible attack on such explicit digital signature is a typical non-
option is produced as the SHA-1 hash over the IPv6 addresses, the repudiation attack, i.e. the Digital Signature field is vulnerable to
ICMPv6 header, the ND message and other fields, e.g. the Message Type the collision attack. An attacker produces two different messages, m
Tag and ND options [rfc3971], that is signed with the sender's and m', where hash(m) = hash(m'). He underlays one of the messages
private key. The sender's private key corresponds to the public key to be signed with the key authorized through CGAs, but uses another
in the CGA parameters structure. It is usually authorized through message afterwards. If a SEND attacker would manage to find the
CGAs. The possible attack on such explicit digital signature is a collision in the message made of the ICMPv6 and ND fields mentioned
typical non-repudiation attack, i.e. the Digital Signature field is in the beginning of the paragraph, he could underlay the false
vulnerable to the collision attack. An attacker produces two message. The fields that make sense to be changed are ND fields, as
different messages, m and m', where hash(m) = hash(m'). He underlays opposite to the ICMPv6 fields which would be easy to reveal.
one of the messages to be signed with the key authorized through However, as denoted in [rfc4270], the structure of at least one of
CGAs, but uses another message afterwards. However, as denoted in two messages (m, m') in a collision attack is strictly predefined.
[rfc4270], the structure of at least one of two messages in a The previous requirement complicates the collision attack, but we
collision attack is strictly predefined. The previous requirement have to take into account that a variant of SHA-1 was already
complicates the collision attack, but we have to take into account affected by recent collision attacks and we have to prepare for
that a variant of SHA-1 was already affected by recent collision future improved attacks.
attacks and we have to prepare for future improved attacks.
3.4. Attacks against the Key Hash in the SEND Universal Signature 3.4. Attacks against the Key Hash field in the RSA Signature option
option
The Key Hash field in the SEND Universal signature option is a SHA-1 The Key Hash field is a SHA-1 hash of the public key from the CGA
hash of the public key from the CGA Parameters structure in the CGA Parameters structure in the CGA option. The pre-image attack against
option. The pre-image attack against the Key Hash field is the Key Hash field is potentially dangerous, as in the case of all
potentially dangerous, as in the case of all other hashes in SEND, other hashes in SEND, because the Key Hash field contains a non
because the Key Hash field contains a non human-readable data. human-readable data. However the Key Hash field is not suspectable
However the Key Hash field is not suspectable to the collision to the collision attack, since in the collision attack an attacker
attack, since in the collision attack an attacker itself chooses both itself chooses both keys, k and k', where hash(k) = hash(k'). The
keys, k and k', where hash(k) = hash(k'). The reason for the former reason for the former is that the associated public key is already
is that the associated public key is already authorized through the authorized through the use of CGAs, and possibly the certification
use of CGAs, and possibly the certification path in the ADD process. path in the ADD process.
4. Support for the hash agility in SeND 4. Support for the hash agility in SeND
While all of analyzed hash functions in SeND are theoretically While all of analyzed hash functions in SeND are theoretically
affected by hash attacks, these attacks indicate the possibility of affected by hash attacks, these attacks indicate the possibility of
future real-world attacks. In order to increase the future security future real-world attacks. In order to increase the future security
of SeND, we suggest the support for the hash and algorithm agility in of SeND, we suggest the support for the hash and algorithm agility in
SeND. SeND.
o The most effective and secure would be to bind the hash function o The most effective and secure would be to bind the hash function
skipping to change at page 9, line 44 skipping to change at page 8, line 44
vulnerable to brute force attacks. vulnerable to brute force attacks.
o One of the possible solutions is also the hybrid solution, i.e. to o One of the possible solutions is also the hybrid solution, i.e. to
require the hash algorithm to be the same as CGA, if CGA option is require the hash algorithm to be the same as CGA, if CGA option is
present, and to use the Hash agility option if the CGA option is present, and to use the Hash agility option if the CGA option is
not present. not present.
4.1. The negotiation approach for the SEND hash agility 4.1. The negotiation approach for the SEND hash agility
None of the previous solutions supports the negotiation of the hash None of the previous solutions supports the negotiation of the hash
function. Therefore we propose the negotiation approach for the SEND function. We suggest the negotiation approach for the SEND hash
hash agility based on the Supported Signature Algorithm option agility based on the Supported Signature Algorithm option described
described in [sig-agility]. Based on the processing rules described in [sig-agility]. Based on the processing rules described in
in [sig-agility] nodes find the intersection between the sender's and [sig-agility] nodes find the intersection between the sender's and
the receiver's supported signature algorithms set, as well as the the receiver's supported signature algorithms set, as well as the
preferred signature algorithm. When producing and validating hashes preferred signature algorithm. When producing and validating hashes
in SEND, nodes MUST observe the following rules: in SEND, nodes MUST observe the following rules:
o In the ADD process, if any of the certificates in the o In the ADD process, if any of the certificates in the
certification path uses the signature algorithm which is not one certification path uses the signature algorithm which is not one
of the signature algorithms negotiated in the signature agility of the signature algorithms negotiated in the signature agility
process through the use of the Supported Signature Algorithms process through the use of the Supported Signature Algorithms
option, nodes MUST reject the Router Authorization certificate. option, nodes MUST reject the Router Authorization certificate.
skipping to change at page 12, line 5 skipping to change at page 11, line 5
This document analyzes the impact of hash attacks in SeND and offeres This document analyzes the impact of hash attacks in SeND and offeres
a higher security level for SeND by providing solution for the hash a higher security level for SeND by providing solution for the hash
agility support. agility support.
The negotiation approach for the hash agility in SeND based on the The negotiation approach for the hash agility in SeND based on the
Supported Signature Algorithms option is vulnerable to bidding-down Supported Signature Algorithms option is vulnerable to bidding-down
attacks, which is usual in the case of any negotiation approach. attacks, which is usual in the case of any negotiation approach.
This issue can be mitigated with the appropriate local policies. This issue can be mitigated with the appropriate local policies.
6. References 6. IANA Considerations
6.1. Normative References There have been no IANA considerations so far in this document.
[new-hashes] 7. References
Bellovin, S. and E. Rescorla, "Deploying a New Hash
Algorithm", November 2005.
[pk-agility] 7.1. Normative References
Cheneau, T., Maknavicius, M., Sean, S., and M. Vanderveen,
"Support for Multiple Signature Algorithms in [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate
Cryptographically generated Addresses (CGAs)", Requirement Levels", RFC 2119, March 1997.
draft-cheneau-cga-pk-agility-00 (work in progress),
February 2009.
[rfc3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [rfc3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[rfc4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic [rfc4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashed in Internet Protocols", RFC 4270, November 2005. Hashed in Internet Protocols", RFC 4270, November 2005.
[rfc4982] Bagnulo, M. and J. Arrko, "Support for Multiple Hash [rfc4982] Bagnulo, M. and J. Arrko, "Support for Multiple Hash
Algorithms in Cryptographically Generated Addresses Algorithms in Cryptographically Generated Addresses
(CGAs)", RFC 4982, July 2007. (CGAs)", RFC 4982, July 2007.
[sig-agility]
Cheneau, T. and M. Maknavicius, "Signature Algorithm
Agility in the Secure Neighbor Discovery (SEND) Protocol",
draft-cheneau-send-sig-agility-00 (work in progress),
February 2009.
6.2. Informative References
[rfc2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[rfc5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [rfc5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC rfc5280, May 2008. (CRL) Profile", RFC rfc5280, May 2008.
7.2. Informative References
[new-hashes]
Bellovin, S. and E. Rescorla, "Deploying a New Hash
Algorithm", November 2005.
[sha-1] NIST, FIBS PUB 180-1, "Secure Hash Standard", April 1995. [sha-1] NIST, FIBS PUB 180-1, "Secure Hash Standard", April 1995.
[sha1-coll] [sha1-coll]
Wang, X., Yin, L., and H. Yu, "Finding Collisions in the Wang, X., Yin, L., and H. Yu, "Finding Collisions in the
Full SHA-1. CRYPTO 2005: 17-36", 2005. Full SHA-1. CRYPTO 2005: 17-36", 2005.
[sig-agility]
Cheneau, T. and M. Maknavicius, "Signature Algorithm
Agility in the Secure Neighbor Discovery (SEND) Protocol",
draft-cheneau-send-sig-agility-00 (work in progress),
February 2009.
[x509-coll] [x509-coll]
Stevens, M., Lenstra, A., and B. Weger, "Chosen-Prefix Stevens, M., Lenstra, A., and B. Weger, "Chosen-Prefix
Collisions for MD5 and Colliding X.509 Certificates for Collisions for MD5 and Colliding X.509 Certificates for
Different Identitites. EUROCRYPT 2007: 1-22", 2005. Different Identitites. EUROCRYPT 2007: 1-22", 2005.
Authors' Addresses Authors' Addresses
Ana Kukec Ana Kukec
University of Zagreb University of Zagreb
Unska 3 Unska 3
 End of changes. 23 change blocks. 
102 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/